Restrict access to all not whitelisted folders of a drive

[ghost]

Hello,

I would like to give sandboxed apps full access to root of A: drive and A:\abc folder and block access to all other folders on the same drive like A:\xyz etc.

In other words, is it possible to whitelist root of a drive and some folder on the same drive and block access to all other folders?

if((Test-Path A:) -or (Test-Path A:\abc)) {
Write-Host("Full access")
} else {
Write-Host("No access")
}

[bastik-1001]

I could not get access to the root access to function openly, but maybe someone else can find a better way to configure it.

In my test UseRuleSpecificity=y was required to be set. I tried to restrict access to D:* and now programs like notepad (editor) can't access D:\ and D:\random\

I used the following entries for the box (normal box, yellow icon):

UseRuleSpecificity=y
ClosedFilePath=D:*
NormalFilePath=D:\demo*
ClosedFilePath=D:\demo\na.txt
NormalFilePath=D:\test.txt

With notepad I could load D:\demo and see all its files (demo.txt and na.txt), it could load demo.txt located there, but due to the closed path for na.txt, the file could be seen by notepad, but it could not be opened nor was the content shown. Due to D:\test.txt being a normal file path for Sandboxie again (last entry in the ini), I could load test.txt from the root folder, by directly opening it.

It should be possible to repeat this with OpenFilePath so those files can be fully accessed by the program. Edit: With the entries that contain NormalFilePath, being changed to OpenFilePath, it remains the same, those files can be accessed and when they are written to, it happens outside the sandbox. D:\demo\na.txt can't be read, written or deleted.

[ghost]

With the following settings I still can't save on root of a drive

OpenFilePath=A:\
ClosedFilePath=A:\*\*

[bastik-1001]

Maybe this is a limitation or a bug. I can't tell.

[DavidXanatos]

mmh... i would have thought that something like this:

WriteFilePath=E:\*\*
UseRuleSpecificity=y
OpenFilePath=E:\*
OpenFilePath=E:\Test\*

should do the trick, but seams I cant access the files on the root, not sure why, will have to debug this.

[offhub]

I tested it, I guess there is a bug with file renaming. @DavidXanatos

[offhub]

Sandboxed CMD:

echo>CreateFile.txt
ren CreateFile.txt RenameFile.txt

(Double backslash?) -> \Device\ImDisk0\\RenameFile.txt (FD) 00120116.01.00000000

\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\CreateFile.txt (FA) 00120196.05.00000060
\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\
\Device\ImDisk0\ (FA) 00100001.01.00000021
\Device\ImDisk0\
\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\CreateFile.txt (FA) 00110080.01.00200020
\Device\ImDisk0\CreateFile.txt
\Device\ImDisk0\CreateFile.txt (FA) 00130116.01.00000020
\Device\ImDisk0\RenameFile.txt (FA) 00100080.01.00000021
\Device\ImDisk0\
\Device\ImDisk0\ (FA) 00120116.01.00000021
\Device\ImDisk0\RenameFile.txt (FA) 00100002.01.00000000
\Device\ImDisk0\\RenameFile.txt (FD) 00120116.01.00000000
\Device\ImDisk0\

[ghost]

Good to know this double backslash occurs to others as well. There was just one line with it though.

Is there any other way to achieve original request? Any workaround for this workaround?

[ghost]

I tested this with WriteFilePath=A:\*\* in [GlobalSettings]

and

UseRuleSpecificity=y
OpenFilePath=A:\*

in Sandbox settings. Result was the same

|Process|      |Type|     |Status|   |Value|                                        

20:39:58.567   File (K)   Closed     \Device\VolumeA\\OIP.jpg.crdownload   

[ghost]

I have noticed I don't need to Close/WriteFilePath anywhere and can just use OpenFilePath=A:\abc. Access to A:\ is closed completely (by default and for whatever reason) but abc folder.

[ghost]

OpenFilePath=Z:\a
ClosedFilePath=Z:\

I was unable to access Z:\a, however, I was able to save txt file in Z:\ and Z:\ subfolders. Those files have been saved outside of the box

[DavidXanatos]

did the files start with the letter a?

[ghost]

No. There is a glitch inside this glitch. To be honest I have no idea why folder 'a' is so special. I thought it is because it was created by user SID which does not exist on this PC and who was an admin.

icacls

a BUILTIN\Administrators:(I)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\SYSTEM:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
  NT AUTHORITY\Authenticated Users:(I)(M)
  NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
  BUILTIN\Users:(I)(RX)
  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

dir /q
01.02.2023 20:45 <DIR> ... a

For now am not able to create one more glitched folder like this, so I will try something else

[DavidXanatos]

I cant reproduce the saving to Z: with that preset, was specificity on or of? did the files start with an a?

[ghost]

I will test it again as there was some issue with sandman not detecting changes in Sandboxie.ini, not reloading it and eventually I had to restart SBIE service

[ghost]

Experiment with

OpenFilePath=Z:\
ClosedFilePath=Z:\\*\\

21:45:07.644 File (D) Closed \Device\SomeVolumeZ\a
21:45:11.874 File (U) Open \Device\SomeVolumeZ\b
21:45:15.669 File (U) Open \Device\SomeVolumeZ\broken
21:45:16.593 File (U) Open \Device\SomeVolumeZ\broken\4

If I manage to create one more folder like 'a', I may be able to achieve what I want... not exactly the way it was supposed to be I guess

[ghost]

@DavidXanatos Is sbie version with this fix available on Patreon?

[DavidXanatos]

its available on github: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.8.0