1. 1

I’ve been hearing a lot about crypto ransomware attacks recently. Someone I know had their boss open a .exe file which held ransom the files on that computer and(!) the remote mounts too. It uses public/private key encryption to lock your files and only give them back/decrypt them when you pay enough.

To me it seems like there’s something very simple and easy we could do to stop a lot of these attacks. There’s always going to be more advanced attacks that get past mitigations, but I feel like the majority can be stopped!

My idea is this: When you run a new program it should not have access to the entire filesystem. It should be limited to only have write access to its own directory. As far as I can tell this is a very simple ‘guard rail’ that you can put around programs to pretty much completely stop these ransomware attacks.

When you install your OS the programs that come with it (or that you install via its package manager or app store) could be configured to have the correct privileges. That means the user doesn’t have to do any work managing complicated security capabilities.

So what are we waiting for? Why isn’t this being implemented?


  2. 5

    For power users sandboxing with fine-grained permissions is obviously the correct thing to do.

    Everyone else will just get used to clicking yes whenever prompted because every legitimate program they install will also ask for filesystem access and the randomware will get in anyway.

    1. 4

      What? You’re going to tell me how to use my computer? How dare you! I’m a power user, not some idiot child, keep your shiny toys in your walled garden where they belong. Serious business only over here.

      And less outrageously, why not ask the user “are you sure you want to run this untrusted program from the internet?” We already do, and users already click yes. So the only way this suggestion works is if the OS really does forbid bypassing the restriction. And then: see typical reaction above.

      1. 1

        I guess you could try to make some functionality accessible only via «log out, log in with another username (hoipefully another password, but let’s be realistic), grant permissions to a specific non-running program, log out, log in back as the initial username, run the program that now has this one permission»… Just complex enough that a cryptolocker cannot explain people how to do it.

        When setting up the computer and needing to run a lot of installers, actual advanced users can batch downloading all the needed installers, granting them permissions and running them to require a single roundtrip.

        1. [Comment removed by author]

          1. 2

            The current problem with pledge and similar sandboxing is that if an application doesn’t pledge to only do a limited set of things, by default it’s pledged to do anything it wants (mostly) and it’s allowed to. Fixing that by requiring every application to be pledged in order to run will need a review process like Apple has or a malicious application will just pledge to do anything it wants.

            Focusing on file system sandboxing, that has a huge impact on how many of us are used to computers working. If applications are isolated to their own file system space, how do I download an mp3 with a web browser, edit it in Audacity, then play it in mpv? iOS and Android are changing this paradigm with explicit private and shared files, and the user “sharing” to get a file from one app into another, so I suspect future generations might not have the same expectation of workflow that I have.

            But then, I also tend to not run random executables and I keep backups of my data.

            1. 1

              But if we assume things are set up just right, users will never see the “run this untrusted program” dialog either. At which point, we can just remove that option and refuse to run any unsigned programs.

          2. 3

            To a great extent this does exist. Sandboxing has helped prevent these types of attacks for many years now. That’s how iOS works on Apple products. A rouge ransomware app couldn’t encrypt the whole phone because it can’t reach the whole phone. The better question is why haven’t desktop operating systems, specifically Windows, caught up yet?

            1. 2

              Windows Store apps are already sandboxed and have been from the start, but that store has not become a broadly appealing distribution platform for lots of different reasons.

              It’s the same situation with macOS and the Mac App Store, but Apple has done a somewhat better job at getting people on board with their store.

              This is one of the many reasons more people are using tablets and phones as their primary computing devices. The compatibility and UX legacy on the desktop is a goddamn mess.

            2. 1

              As has been pointed out, you just get into the current state of dialog boxes that people click “yes” to anyways. Another idea is to make it so these tools cannot get a stranglehold on your data. For example, if all file system’s had snapshotting like in ZFS that was locked down, if some ransomware did steal everything you just revert the snapshot. Maybe you lose some data but better than losing all of it. Of course, the human is still the weak point in there because the program will just try to trick them to deleting the snapshots somehow.