Slashdot Mirror
Windows 10's 'Controlled Folder Access' Anti-Ransomware Feature Is Now Live (bleepingcomputer.com)
A reader shares a BleepingComputer report: With the release of Windows 10 Fall Creators Update last week, the "Controlled Folder Access" that Microsoft touted in June is now live for millions of users. As the name hints, the Controlled Folder Access feature allows users to control who can access certain folders. The feature works on a "block everything by default" philosophy, which means that on a theoretical level, it would be able to prevent ransomware when it tries to access and encrypt files stored in those folders. The benefits of using Controlled Folder Access for your home and work computers are tangible for anyone that's fearful of losing crucial files to a ransomware infection.
First exploit will take that feature, lock out USER from doing anything, and pop up a ransomware screen.
-=This sig has nothing to do with my comment. Move along now=-
The new feature is not permission by users but permission by an application running. The virus, most of the time, run under your own credentials.
On VMS you could never overwrite a file. File system would by default always keep all the previous versions of it. Ransomware action like that would just result in having additional, encrypted, versions of your files.
The beauty of the 'home directory' structure design of a UNIX system is that if malware, or a faulty application you are coding, attempts to wipe out your filesystem, the only thing it will be able to touch is your personal data, the things you actually use the computer to create and manipulate.
Your /home directory can be wiped, and any databases, etc. that you have permission to manipulate can be corrupted. But the binaries that can be re-installed from a CD-ROM or an NFS share in a matter of minutes with a reinstall of the OS are both vigorously protected and easily replaced.
Only the important bits on the computer are vulnerable. Isn't that how it's supposed to work?
No, it's not the same. Windows already has proper permissions for user directories since Windows NT. The issue is that ransomware runs under the same uid as yourself, so if you can access your own file, then the ransomware program can access those same files. This new feature makes it so that even if the uid has access, you can specify ADDITIONAL restrictions, like which exe is permitted to do so. So some ransomware.exe, even with your uid, will be unable to make changes.
There is no such ability in Linux or *nix, since ACLs are solely based on uid and not the name of the executable with your uid. The closest might be a sudoers file with specific commands for which you're allowed to escalate to root privilege. A *nix ransomware program running with your uid has the exact same privileges as bash or kde or gnome running with your uid and access to all your files.
All that said, there are still ways to circumvent privileges restricting which execs are allowed to access the folder/directory. For instance, if chrome.exe is given access, then any ransomware running as a chrome app will appear to be chrome.exe from Windows' perspective and be given access. This problem exists for any exec that allows running scripts or remote code, like bash or the Windows-equivalent powershell. You either have to deny all powershell execs from access, or grant all powershell execs access. The safest approach would be to not get infected with rogue code with your uid privilege. And if you get infected with rogue code that has Administrator (root) privileges, you're hosed because it can bypass or remove these restrictions altogether.
It's very useful if it's paired with a sensible default policy and a sensible UI. You can implement the same thing with the TrustedBSD MAC framework or SELinux, and macOS / iOS implement their sandboxing policies in exactly this way. macOS, in particular, provides a 'powerbox' model, where the standard open and save dialogs are owned by the system and implicitly grant the application permissions to the files / directories that the user selects as part of a dynamic policy. This means that well-behaved applications never need to ask for explicit privilege elevation. The problem is, well-behaved applications are generally not the ones that you most want to sandbox...
I am TheRaven on Soylent News
There is no such ability in Linux or *nix, since ACLs are solely based on uid and not the name of the executable with your uid.
Yes there is. There are even two in Linux, SELinux and AppArmor.
However, there is no easy-to-use GUI to administer it per-user, which means that you rely on the way-too-permissive default policy for most programs. This could have been done years ago technically, since SELinux and AppArmor are both quite old, but no one had the right idea apparently.
Finally! A year of moderation! Ready for 2019?
So the user will be asked a number of times (probably once per appli / folder) if they agree to allow that appli to access that folder, then when they see the fake "Adobe something wants to access your folder" they will be used to automatically Yes it.
You know Windows 10 did away with pretty much all of that, which is why Chrome can't even set itself as a default browser anymore and instead serves up instructions for the user to change it via control panel.
There is no more "simple yes".