Some issues about symbolic link folders/junctions

[gexgd0419]

I have a program that relies on a folder at a specific location, D:\User\Documents\Data for example. However, I decided to move the folder Data into D:\User, so I moved it and created a symbolic link D:\User\Documents\Data which points to D:\User\Data so that the program can still use that folder using the old paths. Also, I want that program to have direct access to that folder, so I added an OpenPipePath=D:\User\Data rule as well. (The program was installed in the sandbox)

This worked fine, until I installed the v1.0 version and the program started complaining that D:\User\Documents\Data cannot be accessed.

After some simple tests, I found that if I try to create a file in D:\User\Documents\Data inside the sandbox environment, I will get a "file not found" error and the file will not be created. If I try to create the file in D:\User\Data then it will be fine. After I reinstalled the older v0.9.8d version, this issue disappeared. Also if D:\User\Data is not an OpenPipePath or OpenFilePath this will work correctly, putting the created file in the target folder (or, the sandbox location for the target folder).

Then I did some more tests. Results showed that the older version, v0.9.8d, also processes some symbolic links incorrectly. I wrote a batch file(.bat) to test it.

Batch file

@echo off

pushd %~dp0

:choice
echo.
choice /m "Make directory structure (M), create files in Full paths (F), create files in paths relative to level 0/1/2 folder (0/1/2), create files in links (L), Delete files (D), Quit (Q)?" /c MF012LDQ

if errorlevel 8 goto :end
if errorlevel 7 del /s /q *.txt & goto :choice
if errorlevel 6 goto :createfiles-inlink
if errorlevel 5 goto :createfiles-relpath2
if errorlevel 4 goto :createfiles-relpath1
if errorlevel 3 goto :createfiles-relpath0
if errorlevel 2 goto :createfiles-fullpath
if errorlevel 1 goto :makestruct
if errorlevel 0 goto :end
goto :choice

:end
popd
exit /b

:makestruct
md Folder
cd Folder
md Target
mklink /j Link Target
md Folder
cd Folder
mklink /j Link ..\Target
cd ..\..
mklink /j Link Folder\Target
echo Created.
goto :choice

:createfiles-fullpath
:: Create text files specifying full (absolute) paths
echo on
echo test > %cd%\Link\FullPath-In0.txt
echo test > %cd%\Folder\Link\FullPath-In1.txt
echo test > %cd%\Folder\Folder\Link\FullPath-In2.txt
@echo off
goto :choice

:createfiles-relpath0
:: Create text files specifying paths relative to the "root" folder of this hierarchy
echo on
echo test > Link\RelPath-To0-In0.txt
echo test > Folder\Link\RelPath-To0-In1.txt
echo test > Folder\Folder\Link\RelPath-To0-In2.txt
@echo off
goto :choice

:createfiles-relpath1
:: Create text files specifying paths relative to "Folder"
pushd Folder
echo on
echo test > ..\Link\RelPath-To1-In0.txt
echo test > Link\RelPath-To1-In1.txt
echo test > Folder\Link\RelPath-To1-In2.txt
@echo off
popd
goto :choice

:createfiles-relpath2
:: Create text files specifying paths relative to "Folder\Folder"
pushd Folder\Folder
echo on
echo test > ..\..\Link\RelPath-To2-In0.txt
echo test > ..\Link\RelPath-To2-In1.txt
echo test > Link\RelPath-To2-In2.txt
@echo off
popd
goto :choice

:createfiles-inlink
:: Create text files when current working dir is the link itself
pushd Link
echo on
echo test > RelPath-ToLink0.txt
@cd ..\Folder\Link
echo test > RelPath-ToLink1.txt
@cd ..\Folder\Link
echo test > RelPath-ToLink2.txt
@echo off
popd
goto :choice

First put this batch script inside an empty folder, run it outside the sandbox, then press 'M' to build the directory structure where there's one target folder and several symbolic links (these are junctions actually) pointing to the same folder but are in different folder levels. After that, press 'Q' to quit, and relaunch it inside a sandbox. This time press 'F', '0', '1', '2', or 'L' to let it create test files in different ways.

I noticed that if the file is created with a full path to a symbolic link folder, it will be put correctly in the target folder. But if the file is created with a relative path, Sandboxie will sometimes think that the symbolic link folder is an actual folder, then create a corresponding sandbox folder for the symbolic link and put the created file in that folder.

For example, the target folder is D:\Folder\Target and the link is D:\Folder\Link, and the sandbox folder is D:\Sandbox\TestSymLink. When I try to create a file in D:\Folder\Link with a relative path, sometimes the file will be created in D:\Sandbox\TestSymLink\drive\D\Folder\Link.

I also noticed that if the path is a relative path, but it contains .., then the file will be put in the correct location.

That behavior reminds me of the OBJECT_ATTRIBUTES structure. When I'm opening a file with a relative path, most likely I will get an OBJECT_ATTRIBUTES structure with RootDirectory set to a handle to the current working directory and ObjectName set to the relative path. But if the path is absolute or if the relative path begins with .., then RootDirectory will be NULL and ObjectName will contain the full path. Not sure if this is related to the behavior though.

[DavidXanatos]

i think the issue is releated to #1409 and I'll take a look into it soon

[DavidXanatos]

I suspect this may be a specific issue introduced in 1.0.0 not generally related to symlinks,

please test if adding UseRuleSpecificity=y to your sandbox resolved the issue you have with the latest build

[DavidXanatos]

I can reproduce the general issue with the batch file.
but i fail to reproduce specific the issue with version 1.0.0 vs. 0.9.8d
when i create
C:\user\documents
and
c:\user\data
and
use mklink eider with J or D to create a link from C:\user\documents\data to c:\user\data
and have
with booth versions and have OpenPipePath=C:\User\Data configured
i can echo bla > C:\user\documents\data\test.txt successfully
in 0.9.8d and 1.0.0 as well.

What Am i doing wrong?

Also there were a coupel related fixes in teh recent build 1.0.8 could you please test if 1.0.8 works for you usecase, the batch file still fails but I'm working on it.
And tell me again in more detail how to replicate the specific regression from 0.9.8d to 1.0.0

[DavidXanatos]

I think i found the issue, the batch file wil work correctly with the 1.0.9 build, also it will be possible to create junktions also from within sandboxie

[plofhaan]

@DavidXanatos
Could this be re-opened? The issue persists in Sandboxie-Plus v1.0.9. I have tested with Firefox Portable 96.0.3 running on Windows 11 Home official build 469, full updates, and drivers, using no 3rd party security softwares─no other issues are present on the system. As a temporary workaround currently I am copying the FirefoxPortable folder directly into my "C:\FirefoxPortable - sandboxed" instead of putting the junction in there.

Many thanks for all the hard work!

[DavidXanatos]

the test batch file now works as it should.

can you craft a step by step guide for me how to reproduce the issue?

[plofhaan]

can you craft a step by step guide for me how to reproduce the issue?

➜ #1345
Just extract Firefox Portable to a folder "C:\FirefoxPortable", and, in another folder "C:\FirefoxPortable - sandboxed", put a junction named FirefoxPortable that points to it. Add "C:\FirefoxPortable - sandboxed" to the list of Forced Folders in Sandboxie Control (or add a line ForceFolder=C:\FirefoxPortable - sandboxed under [DefaultBox] in Sandboxie.ini).

When the sandbox is empty and Firefox Portable is launched like this, it runs sandboxed like expected, but addons do not load in Firefox Portable upon the 1st launch. Close-restart Firefox Portable fixes it, temporarily until after the sandbox is emptied. (I use only addons that appear on Mozilla's list of Recommended addons like uBlock Origin, Dark Reader, Tabliss, all of which are known to be reliable so you know the issue is not caused by them.)

Where this gets interesting is that, next, launching Firefox Portable UNSANDBOXED (i.e. directly from "C:\FirefoxPortable\FirefoxPortable.exe" instead of "C:\FirefoxPortable - sandboxed\FirefoxPortable\FirefoxPortable.exe") now causes a similar issue, of having to close-restart Firefox Portable UNSANDBOXED.

Clearly, this behavior is undeniable evidence that launching Firefox Portable SANDBOXED has caused a file to get modified OUTSIDE the sandbox. So, this must be a security bug in Sandboxie-Plus, and, I first discovered this bug at least 5 months ago (and have spent at least 2 months to verify that the bug is real, not caused by some other chain of possible events and that could have been unrelated to Sandboxie-Plus...).

[DavidXanatos]

mmh... and if you don't use a junction everything works fine?

[plofhaan]

mmh... and if you don't use a junction everything works fine?

Yeah.

[DavidXanatos]

I cant reproduce the issue right now, also it has an own thread so I'll close this and mark as fixed as the test bat provided for this issue wi now workign properly. and we contile looking into this the otehr issue in its own issue