|
This workaround driver only allows to access files and folders on local partitions with disregard of ACL's.
So it won't allow the user to access remote resources he is not permitted to access.
The driver does not mess with ACL's it just makes them ineffective. So nothing to be restored and it should not break anything eider.
Adding some sort of white-list to not fully compromise the security is a good idea, although I would probably try to go for checking if a process having admin privileges instead of a static list.
IMHO when we start i.e. cmd.exe "as administrator" we deserve to be able to access anything everywhere, so this would be a reasonable approach.
For me the main motivation behind this driver is that even as SYSTEM/TrustedInstaller I couldn't modify files under C:\Program Files\WindowsApps, the most strange thing was that even after taking ownership and removing all ACL entries except my user having all permission I still couldn't modify those files.
Even when the partition in question was not the running windows but one that was offline. Trying to access it from windows 10 was enough to make it inaccessible.
Doing the same with a windows 7 as host allowed me full access.
Duno what MSFT exactly set on this directories but actually it seams pretty clear that its something different than ACL's
Even taking ownership under windows 7 removing all ACL entries, adding new once to grant full access to the administrators and everyone group, does not allow me to access this files when using a windows 10 host.
Anyone have any idea what they may have did here?
|