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.
Isn't this just like having a home directory where others aren't allowed write access to your files?
I can't help but wonder why it took Windows 2 decades to correct the default umask on user files.
The society for a thought-free internet welcomes you.
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.
This is nothing like a home folder on a *nix system, but donâ(TM)t let that stop you from fishing for mod points. Iâ(TM)ll leave it as an exercise for you to actually research the feature.
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?
This is more like SELinux, it's about controlling what programs can get access to something rather than what users.
It isn't all that different.
Linux filesystems support much finer granularity than even Windows.
It is just that most people may not use them.
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.
permanently disable filesystem encryption
Just because the Windows libraries are a convenient way to encrypt, they're just the low-hanging fruit. If this became difficult to use, they'd just use another library to encrypt the file contents. Malware can easily include this if needed.
Nope. By the sound of things, this is more akin to the sandboxing feature present in apps sold via the Mac App Store. The apps are running under your permissions, just as they always have, but they now need to request and be granted permission to access new folders. Basically, just as mobile OSes require that an app request and receive permission before it can use the camera, the mic, or your location, Windows is, from what the summary sounds like, now requiring that apps request permission to access specific folders.
ummm the malware out there isn't using OS crypto to do it's thing. Forcing filesystem encryption to require an added permission won't change anything. Likewise these malware executables can easily bring along their own crypto libraries, in fact I think many already do. Denying crypto libraries will also not change anything! You may want to do some research...
So how does this work?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Ransomware only goes after your personal data. Documents, pictures. There are not many outside your home directory.
I mean command line tools. Do you have to give permission to everything, like copy.exe?
My opinion would have been a heck of a lot more useful for Microsoft to roll out a versioning file system. That would have provided more value to customers and end up being way more useful in every way vs piling on new access control regimes and expecting people to use it for real this time.
Would be interesting to hear what if anything prevents an attacker from modifying search path environment variables or user registry or CLI parameters to convince software to load custom add-on haxor.dll's and then launch a trusted program. Unlike DLL injection this does not require any elevated privileges. Does the system keep track of all of an applications possible dependencies? If a software program dynamically loads a new DLL in response to user action such as enabling a new feature within the software does Windows flash an alert and ask the user if it's ok? If so what percentage of users are likely to be qualified to even begin to provide a coherent response?
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.
Non-vintage Unix don't rely exclusively on xxx field bitmap neither.
Modern unix filesystems do support ACL for more complex access control.
Modern features like SELinux and AppArmor also help having application-level control.
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
And how would that prevent a ransomware from implementing its own encryption ? .ZIP file ?)
(e.g.: moving all data it can manage to get access to into a huge password-encrypted
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Seriously, most of that kind of malware runs as *YOU*. If you have full access to it, it will be able to encrypt the files. Am I missing something?
--fatboy
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 ]
Why should apps have access to all folders by default and then (only now) there is a feature to restrict certain folders? Why should most apps access anything except their own data? Android/iOS/OSX/Web have been like this forever, what is taking so long for Windows?
You can bet that if Microsoft tries to actually seriously implement a log-structured (e.g.: actually decided to use UDF beyond optical and portable flash media) or copy-on-write filesystem (e.g.: ZFS and BTRFS on NT kernels) that supports version control, they'll botch it and there will be an exploit found making the older copies also editable by a non-admin user (the ransomware could purge the older copies and only leave the encrypted version).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
>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.
This is ridiculous in the extreme. Anyone fearful of losing their files for any reason should be backing them up on a regular basis! So perhaps this new feature prevents files being encrypted in a ransomware attack, but what if the disk fails? Or any number of other issues?
Come on people, get a clue!
Blocked from access by all programs by default? So I go to photoshop and hit open and the open file dialog box is blocked from accessing any folder anywhere in my user directory? That's helpful. Is that really how this works or is this more like "nothing can get past the UAC" type of BS?
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
Its just a way to have you mark your interesting files to steal from you. Just like deleting a comment
Except that's not how it work. Defender blocks writes, it doesn't prompt. You can add white listed apps but not during a ransomware attack.
Linux is (of course) subject to that attack as well, the thing is 1) Linux users are usually more system aware and don't run anything attached in a mail 2) attacks target Windows because it's still 90+% of the running OSes (desktop wise).
Slashdot, fix the reply notifications... You won't get away with it...
This is funny only from a single-user PC perspective, but remember UNIX is a multi-user server system. Yep, if it's your files you _are_ a king. Nothing wrong here. No fool proof behaviour cause users are not considered for fools.
Yes... but those important bits have offline backups.
If there are no backups, those bits aren't important.
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.
No, I didn't read the article, but why should I when this sounds really dumb? Why not protect the entire drive instead of protecting parts of it!? If you have a method for the former, why not do it for the latter and leave it at that? Also how is this fundamentally different than the access/security settings for files and subdirectories that have existed in NTFS for decades?
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?
In Windows, everything runs under your users' account and almost everything else runs as root. This is similar to setting the noexec flag on the users' home partition, something that has also existed a long time.
Custom electronics and digital signage for your business: www.evcircuits.com
Is it really finer graned? To me Windows MACLs and DACLs look pretty much equivalent to SeLinux's ACLs and type labels.
"offline" being the operative word here. Backing up to a spare disk or an NFS mount still puts you at risk.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
We had a ransomware infection on our network, and it basically tested every network share it could find, and started encrypting on network shares the user had read/write access to. Of course, we keep very thorough backups so data loss was minimal, but ransomware infections certainly go beyond local profile folders. It would be nice to see this logic more thoroughly extended to cover access to network resources.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Often it's not a case of "there are no backups", but "the ransomware gets the backups too because they're read-write accessible".
IMHO, the best solution is a versioning filesystem, where deleting old versioning data requires administrator access. So ransomware "wrote over" all of your files? Big deal - rollback. So long as it can't delete old versions, the worst it can do is temporarily run you out of disk space.
I'll BUILD someone to replace you. Some kind of gamma-powered monster, with a heart as black as coal!
Thank you I am sick of these dyslexic pamphlet garglers inability to recognize between execution and storage memory. For all you extraverts still reading the intangible user man should never be able to touch the level of realness that is your folder of data so you put his ass in a jail mmmkay.
windows already has this. this feature is about protecting those files that programs running under your accounts would normally have access to.
news flash:
Windows 10 now has some features that unix has had since the 1970's
coming soon a better shell command ?
save you nickels and download a better operating system...
if is spelled right and has uppercase letters, you could save keystrokes & bits by running unix ;)
Either I don't understand how it works or it can be circumvented by gaining the SYSTEM level privileges (and most Windows users say "yes" to all UAC warnings so getting the said privileges is not that difficult).
Why was this rated up when it’s not even remotely close to how the feature works?
and how well does it protect when a dumb user (i.e. most of them) is stupid enough to blindly give admin rights to the bad program which can then change windows settings and turn this shit off on its own?
For a lot of people, it is the opposite. Being able to encrypt or destroy someone's files is far more lucrative than getting root or Administrator rights.
What is new is the per user/per process granularity (although it really isn't new, as it has been in SELinux for years). This is important, although attacks via IAP mechanisms like Microsoft DDE can jump this... however it is a step in the right direction.
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.
Nothing protects against stupid users. This feature is just for the rest of us.
Maybe stick to microdosing next time.
All that means is that the potential attack vector is through another piece of software that already has permissions.
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.
Probably shouldn't autistically run random exe's?
What about learning to backup your shit?
It's called SELinux.
Relevant xkcd: https://xkcd.com/1200/
R.Mo
Because "humans" will end up saying "yes" to about everything.
Free game.
Free browser.
Similar named application.
There is no way to aid "idiots" who do not keep at least one backup of their relevant data.
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
Linux has had this for a long time. You just change permission of folder and any application that's not sudo doesn't get to change anything. It's like trying to save a file change for settings in /etc/ and needing to be sudo but not for /tmp/.
... instead of filesystem locations (or in addition to)
A ransomware needs to read and write tons files rapidly to be "effective".That's usually how people get first signals:"my pc get very slow"
it is still not an issue. Windows sucks STILL.
Yeah, SELinux does this. It is too bad that 99% of the fixes for common Linux issues I see on the internet is "Disable SELinux"...
Truly, they are an industry pioneer.
The new feature is not permission by users but permission by an application running.
A number of Linux distros have their webbrowser run as a separate user for quite a few years.
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.
That 'beauty' became obsolete when personal data became more valuable than the effort it takes to rebuild a computer. The 'home directory' structure was built around timesharing mainframes, when a computer would be shared by hundreds or thousands of users and have hundreds or thousands of home directories, and non-supervisor users had no business futzing with the system or application directories or even other home directories. If one user's account got wiped, restore it from nightly backup. If the system got whacked, OTOH, that's downtime for hundreds or thousands of users while sysops spent days bootstrapping the system from tape.
Sure, the 'home directory' is a step-up from the complete non-security do-whatever that was the personal microcomputer of the 80's and 90's, but today one's personal data is much more valuable than the trouble of rebuilding a computer's OS. A person's financial existence might be stored in the 'home directory' of his PC or smartphone today. Crash the OS, a smartguy/genius can likely rescue the user data and just copy it to a fresh new device, and you're back in business. Corrupt the user data, OTOH, and you might lose your credentials to log in to the bank, pay your electric, work remotely for your employer, etc., cost you weeks trying to rebuild your life.
Corrupt the user data, OTOH, and you might lose your credentials to log in to the bank, pay your electric, work remotely for your employer, etc., cost you weeks trying to rebuild your life.
What you say is completely correct, and yet anyone whose life is so dependent on their computer really needs to have layered backups that are not on the computer in question, with a very high preference for some sort of off-site location.
I realize that most people don't do this, but they may one day come to regret it. Secure multi-generation backups are really the best defense. While it's good to see MS step up their game here, there has to be a significant degree of user responsibility.
that solution works but your devouring storage space. For a little while high capacity hard drives were making that moot, but lately Users are getting low capacity SSDs now meaning we're back to square one and space is at a premium again. I have a working folder that's managed to grow to 4 gigs over the years full of text files, database backups, documents and the like. And my dev VMs start at 4 gigs and go up.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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.
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.
You must be new here (on earth). That's precisely what happened when early viruses spread via email and attempted to use administrator access by autorun components of the email. Users were so used to seeing those prompts, that they either turned them off entirely (allow all of these in the future type of setting), or just hit OK every time without thinking/reading it fully.
IE. your argument has one problem: facts!
Not true... All ransomware has to do is check /proc/mounts for any mounted filesystem and then scan any nfs/smb/cifs mount point for things it can descend into and write. It can even be set with a nice setting to make it so that it doesn't impact system performance.
See subject: This works (or could) via that mechanism - it's how they "hid" the shitty snooper patches KB2952664/2976978/2977759/3170735 https://www.computerworld.com/article/3091875/microsoft-windows/four-new-windows-patches-to-avoid-kb-2952664-2976978-2977759-and-windows-journal-3170735.html/ via using "Trusted Installer" as its owner for folders for it under %WinDir% - there were 100's of megabytes of content there even when you uninstalled it - how I got it out? I changed the folder owner to myself & burned it.
* IN OTHER WORDS YOU CAN DO THE SAME PRETTY MUCH & I'D WAGER THIS IS HOW THEY ARE DOING IT @ MS FOR WIN10.
APK
P.S.=> My guess is that to access said folders they built an interface for it, much like is done for UAC, to ALLOW you access as a sufficiently priveleged user... apk
Windows/system32/drivers/etc/hosts it's hit or miss each time I go looking for it. The ETC directory doesn't show half of the time.
When working with the GE timesharing system in the 1970s, I found that one could set file permissions by application. Only that application (or an application group) could work with the files when permissions were properly set. One could, of course, work with full permissions while developing, and forget to properly set them when placing into production ...
(3) Bypass the whole thing via obscure twists in the giant and massively huge clusterfuck that is called WINAPI.
CLI paste? paste.pr0.tips!
Way to force a +5. Hacker.
CLI paste? paste.pr0.tips!
that's not sudo [...] to be sudo [...]
Troll harder. Or learn your fucking unix, even if it's only the Losers' Unix.
CLI paste? paste.pr0.tips!
I run my web browser and any *media stuff setuid someoneelse, you insensitive clod.
CLI paste? paste.pr0.tips!
Which is the only thing anyone can do.
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.
Err why? No really think about that. What usage scenario would Flash or Chrome have that requires writing to e.g. Documents directory?
It seems like they haven't fixed the fundamental, underlying problem of users running untrusted code
No one has. It's kind of fundamental to the operation of the computer that the user has the ability to a) run code, and b) have that code access files with their permissions.
Windows has taught them to think there's something "wrong" with their computer if JavaScript is disabled.
And there would be. One should not disable the scripting languages that render webpages, but rather sandbox them into places they become harmless. We want to do more with our computers, not less.
The irony of this is that the NTFS filesystem has had fine-grained permissions for 2 decades, but Windows never exploited it until now
Windows has exploited all the permissions since they first came out, the user defaults were just sensible enough that users never changed them. They are not unlike the Linux default permissions. Furthermore what is happening here has nothing at all to do with the filesystem or NTFS permissions. And speaking of Linux....
Why does Microsoft always get the usage model wrong?
How so? What they effectively have now is a copy of Unix permissions with SELinux bolted on top.
why not let the user choose the default browser at first setup/install... o wait its MonoplySoft we are talking about.
This is one reason why backing up your data is important no matter what OS you use. The OS can be re-installed, and hardware can be replaced, but your pictures, documents etc... are not easily replaced unless you have them backed up on storage media that is only connected while doing backups. There should be several backups, and they should be rotated. Backups can also be useful in case of accidental erasures, hardware failures etc... Of-site backups are a good thing in case of fires, floods, tornadoes etc...I would NEVER rely on backups on any internet or "cloud" service...data stored with these services is too easily stolen! Look at all of the recent data breaches!!
What are you on about? Bash will execute anything that has execute permissions regardless of the path variable, as long as you provide the full path to the executable (./runthis.sh). In most graphical environments, double clicking on an executable will also run the program. Windows acts exactly the same.
NTFS also has the execute permissions for executable files.
git is for versioning
Then what is for versioning of large non-textual files, such as large GIMP, Photoshop, or Audacity projects? Git isn't really built to handle big binaries. And what is for protecting your private Git repositories from unauthorized modification by ransomware?
Now with the new Windows structure, it won't be able to touch your personal data but it can completely replace and manipulate everything in Windows directory.
It can wipe the whole Windows directory and replace it with it's own binaries. So after rebooting, you'll finally be able to get borderless ransomware at boot instead of being windowed inside Windows.
It is sort of a fraction of how Qubes OS works; security by compartmentalization. Unfortunately, Qubes is way, way too complicated for most users (even those with technical knowledge) and it is unlikely to ever go mainstream unless that totally changes. The major problem with Windows security is its entire ecosystem.
Of course everyone should use Linux instead of Windows, but that alone would not solve the problem. Linux + good OpSec, however, is a very strong defense.
OSX has had this feature for over a decade. It's not used a lot but you can use it. it's fairly simple to use too if you are computer savy.
It's called the sandbox. and it allows you to run an app such that there's a list of files, folders, network address, CPU levels, and all sorts of things it can or can't access.
you create a file in the sandbox direcory that might look like this
(allow file-write* file-read-data file-read-metadata
(regex "^/Users/user_name/[Directories it requires to write and read from]")
(regex "^/Applications/MyApp.app")
(regex "^(/private)?/tmp/"))
name that file something like ""myapp-sandbox-conf "
then launch any app with that wrapper like this:
sandbox-exec -f myapp-sandbox-conf /Applications/MyApp.app/Contents/MacOS/MyApp-bin
Some drink at the fountain of knowledge. Others just gargle.
Windows has had the Software Restriction Policies feature for a while now that let you control what executables can run.
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.
Users can’t just create and load new selinux policy on the fly, GUI or not, without privilege escalation. What setuid? system would dynamically create new policy per user, and is there even a way to hook into selinux to prompt the user on policy denials? There’s a good reason nobody had this idea, it’s not remotely feasible with selinux. That’s not what it was designed for.
Users ? That's not a problem any more.
Just automate users.
aaaaaaa
You're officially almost half a century behind UNIX on basic filesystem security features. For your next update, why not consider implementing RUNLEVELS?!?
God Microsoft sucks. It's all the more embarrassing because they've been hoovering up MILLIONS (billions?) of dollars to churn out garbage, incapable of being secured, crippleware, and people have been paying them to do it. What a joke.
From the man page for chmod:
A chmod command appeared in Version 1 AT&T UNIX.
The chmod command changes FILE PERMISSIONS, including for files that are FOLDERS, as they like to call them, (or directories/subdirectories, as they're really known).
Our reign has gone on long enough. Indeed. Summon the meteors.
App Armor has a GUI and ncurses environment on OpenSuSE.
Cheap storage VM.
What a great idea.
You're talking about Discretionary Access Controls (file/folder) permissions, which have been available in every OS for a long time. I suspect this is more of a Mandatory Access Control scheme, which works on a kernel level. Basically, if the action is unauthorized, even root can't do it. The Linux equivalents are SELinux and AppArmor.