It isn't just badly made ransomware; in some cases people have stolen the master key or the responsible party has released it. In other cases C&C servers have been seized and keys recovered that way.
Ransomware exists thanks to a fundamental mistake in the Unix (+Windows, +others) model that a process' rights to the filesystem automatically inherit from the user's rights. Imagine if all processes running under the same user shared the same address space!
There is absolutely no reason some random piece of code downloaded from the internet should have access to my home directory, let alone the rest of the filesystem, without my explicit authorization.
The future is macOS sandbox / linux cgroup by default for all processes.
The macOS solution of presenting the user a system-controlled open dialog that then grants access to the selected path outside the container is elegant and not too intrusive.
Taken a step further, it is obvious that CoW filesystems need to be standard and all activity taken by a process should be recorded in snapshots that get coalesced over time. If a rogue process does cause damage it should be possible to roll back just that process' most recent changes to the filesystem.
I'm really quite surprised that there are no big and used by default user facing sandboxing solutions for the major OSes out there.
With dynamic prompts akin to the firewall prompts familiar from Windows/Mac.
'The program "Chrome" wants to create the file "/home/username/.config/chrome/config". Allow "Chrome" to access [just this file / the diretory ~/.config/chrome / the diretory /home/username]'
'WARNING: The program "totally_legit_for_reals" wants to overwrite the file ~/.xinitrc. This is potentially dangerous. Allow access? -> Are you sure?'
'ALERT: the unknown program "xxx" has gained superuser privileges and wants to overwrite a critical system file System32/whatever.dll. This is very dangerous....'
Then again, non techie users usually ignore all those prompts and just click accept.
Just look at the mess that is Android permissions. Almost no one actually checks them or rejects apps that ask for way too much.
I'd still really like a kernel level protection mechanism that requires granting each executable the capabilities it requests, with dynamic pin the Linux world there are SELinux, AppArmor grsecurity, which are often cumbersome to use).
A more robust idea might be a versioned filesystem. Somebody hacks your browser, it overrides your files - no matter, you just rollback to yesterday's version. Of course, that'd require more diskspace, but diskspace is getting cheaper and most of it is used for content that is completely static (like games or photos or videos - not edited much unless you're a professional working with it). Also probably would be a bit slower but I think it can be solved.
I think there are a number of implementations of such things, but none mainstream enough.
Hell, I'm a technical user and after a couple of days running Comodo firewall (which does prompt in a similar way to your examples) I turned it off because I was sick of the prompts and just wanted to use my machine.
What you say is true, however I am afraid permissions are not the solution either. Look at android ecosystem - they have tons of permissions, but who actually looks at them? People just click "accept" 99.9% of the time. Same will be on desktop OSes. Granted, more granular permissions make Android somewhat safer - but it also makes many things harder to do. If you did this on desktop, users would scream and demand to make it "convenient" - which would lead to them clicking "accept" where they shouldn't.
The problem is it's very hard to distinguish legit from non-legit without asking the user. Users do a lot of stuff and malware can mimick any of it. And if you do ask the user, the malware can make the user answer yes - usually by means as simple as "The OS will be displaying a confirmation dialog, please click YES for this program to work". Yes, it won't work with 100% of people, but it's a game of numbers - it will work for significant number of them.
Nope, 95/98 and IIRC 3.11 are true multi-tasking systems, the processes do not share the RAM address space.
However, everything up to, but not including, Windows 2000 (and its predecessor Windows NT) suffers from ALL local users having effectively admin rights on the machines. Not only that the OS doesn't support user permissions, also the underlying file system FAT32 does not store UID/GID or anything, except the file flags "read only"/"system"/"hidden".
Only Windows NT and above (2000, XP, Vista, 7, 8, 10) are secured in this way. Caveat: NT, 2k and XP allowed installations on FAT32, which nullified many protections.
Ransomware exists thanks to a fundamental mistake in the Unix (+Windows, +others) model that a process' rights to the filesystem automatically inherit from the user's rights. Imagine if all processes running under the same user shared the same address space!
There is absolutely no reason some random piece of code downloaded from the internet should have access to my home directory, let alone the rest of the filesystem, without my explicit authorization.
The future is macOS sandbox / linux cgroup by default for all processes.
The macOS solution of presenting the user a system-controlled open dialog that then grants access to the selected path outside the container is elegant and not too intrusive.
Taken a step further, it is obvious that CoW filesystems need to be standard and all activity taken by a process should be recorded in snapshots that get coalesced over time. If a rogue process does cause damage it should be possible to roll back just that process' most recent changes to the filesystem.