I'm trying to isolate as many non-windows applications as possible, and so far it's working great, but I've come across a scenario where I need one of my apps to have write access to an area of disk that I have closed off in my general settings, and I think it's because the resource access prioritsation isn't working correctly. For sake of example, create a Security Hardened Sandbox (so Resource Rule Prioritisation is enabled) and set notepad.exe as a Forced Program, and create two Resource Access rules to the same path: OpenFilePath=notepad.exe,D:\downloads ClosedFilePath=D:\downloads When I open notepad it's forced into the sandbox but it can't navigate or save anything to D:\downloads\. In the rules it states that process level matching has a higher priority than rule specificity so I'd expect the OpenFilePath to overide the ClosedFilePath, unless I've misinterpreted it. My real example has the OpenFilePath deeper than the ClosedFilePath so I might not expect to be able to traverse the folders but I would expect to be able to access the file - although adding a ReadFilePath or WriteFilePath for notepad.exe should allow me to perform the traversal too, I believe. Hope that makes sense. Really appreciate all the hard work that is going into the development at the moment, it is so good to see the product have the time spent on it that it's always deserved!
It could be a bug but this should work as expected: Code: OpenFilePath=notepad.exe,D:\downloads\* ClosedFilePath=D:\downloads or try the following: (! means NOT, so it will block the path if it is not notepad.exe) Code: ClosedFilePath=!notepad.exe,D:\downloads
This works because the path is now longer on the OpenFilePath than the ClosedFilePath and so is a more complete match, I assume (ignoring the process level match which should take precendence). That's cunning, but my actual path is the root of the drive and that doesn't appear to work: Code: OpenFilePath=notepad.exe,D:\* ClosedFilePath=D: The actual ClosedFilePath is in my Global Settings, so whilst I'd rather not hard code the app into that setting, it looks to be the only valid workaround for now! Thanks @busy EDIT: Actually just "ClosedFilePath=D" does work, although a messy "solution" EDIT2: Scrub that, "ClosedFilePath=[just the first drive letter]" seems to cause mayhem, e.g. "I" seems to block internet access.
I did some testing: @simbun This is not working. (bug?) @DavidXanatos Code: OpenFilePath=notepad.exe,D:\ ClosedFilePath=D:\ This works except root access (You manually need to type subfolders e.g. D:\downloads to browse). Code: OpenFilePath=notepad.exe,D:\*\* ClosedFilePath=D:\ This works but it is not what you want. Code: ClosedFilePath=!notepad.exe,D:\ Also you can try 'Security Hardened Sandbox with Data Protection' box type. Code: OpenFilePath=notepad.exe,D:\
Hi @DavidXanatos Have you had a chance to look at this? If it's not a misinterpretation of the rules from my side shall I raise a defect for it?
I had a look on that and unfortunately it is working as implemented, although this may not be what the user would expect based on the description. You see the test=prog.exe,bla trumps test=blup but for that mechanism to work booth properties (here test) must be the same, in your case you have 2 different properties, hence the match level based on having a program or having no program has no effect, OpenFilePath and ClosedFilePath are 2 different properties. I could look into changing this behavioure but that would be a very specific special case for path type config properties
