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=-
How does this work? If "you" somehow allow access to the ransom-ware by clicking something you shouldn't, and the folder is owned by "you" - does this help? And if you are being asked for access to something "you" own on a regular basis, does this actually work?
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 file permissions on Windows filesystems are far more granular and not just based on an xxx field of bitmaps like on vintage OSes like Unix.
What I would like to see for the defanging of ransomware is a way to permanently disable filesystem encryption unless it is re-enabled by a very-restricted-access tool, i.e. filesystem encryption can be permanently disabled on a system and re-enabling it requires a local admin account running in Safe Mode to re-enable plus answer a prompt at reboot.
Encryption and similar password-restricted functions hard-coded into a system, i.e. BIOS passwords, are a catch-22. If you don't enable them, you have to leave them sitting there 'open' for some other entity to enable. Why not just leave the encryption libraries not-installed on a system that doesn't want or need them?
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.
This is more similar to something like SELinux and AppArmor.
e.g.: some attachments that you clicked on in your e-mail client, even if run as your credentials, should NOT have a valid reason to write anywhere on your folders (and attachements should not be run to begin with).
e.g.: any sub-process launched by the browser should only exclusively have the rights to write into the cache and download folder, and not anything else, even if they still inherit your session (even if the sub processes aren't changing their user id to "nobody").
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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
Users will be used to automatically say "yes" when they're trying to accomplish something (open a PDF that they just downloaded) and the prompt makes sense ("do you want to grant PDFreader access to folder Downloads?). It doesn't follow that users will therefore say "yes" to a request not related to what they're trying to accomplish.
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.
No. RTFA. They will see an error dialog that says "Access is denied. Use File>SaveAs to save under a different location or name." The only way to enable it is (1) opt in via the control panel, (2) chose apps via the control panel.
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?
Why was this rated up when it’s not even remotely close to how the feature works?
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".
So the issue now becomes a question of how ransomware authors write ransomware in something like Flash or Chrome, which the average user would always enable. It seems like they haven't fixed the fundamental, underlying problem of users running untrusted code, but only moved the goalposts.
The underlying issue here is that security holes of this type are enabled by Windows:
The irony of this is that the NTFS filesystem has had fine-grained permissions for 2 decades, but Windows never exploited it until now, and even this move - while better than nothing - is questionable. Why does Microsoft always get the usage model wrong?
The society for a thought-free internet welcomes you.
Install the File server resource manager role on a windows server and you can basically do just that. There are tons of instructions on the internet on how to use FSRM to block ransomware pretty much outright on network shares.
Why was this rated up when it’s not even remotely close to how the feature works?
Because on /. we mod up or down based on our own personal versions of what we thing reality is, not actual reality.
I browse on +1 so AC's need not respond, I won't see it.
Microsoft has a versioning tool: Shadow copy. It can keep previous versions of files. The problem is that malware authors know this, so they will open/write/close the file over and over to flush the clean copies out of the previous versions cache.
I browse on +1 so AC's need not respond, I won't see it.