SBIE_Temp privacy concerns [SOLVED]

[Scoox]

Sandboxie v5.10 on Windows 10 Pro x64, I've just noticed every time I copy a file from a sandboxed Explorer window, Sandboxie will create a copy of the file in:

C:\Users\<user_name>\AppData\Local\Temp\SBIE_Temp\<random_alphanumeric_chars>\<file_name>

For example, after copying a file from my desktop (my desktop directory is also on an ecrypted drive), the following two files were created:
C:\Users\Manuel\AppData\Local\Temp\SBIE_Temp\1d1b9cd1c47b9c0\2015-11-03-103229 Edison offset.png
C:\Users\Manuel\AppData\Local\Temp\SBIE_Temp\1d1b9cd1ed88cd2\2015-11-03-103229 Edison offset.png

I run my web browsers in Sandboxie so I can delete all the data quickly without having to worry about privacy. Furthermore, I my sandbox folder is on an encrypted drive, but my C: drive is not encrypited. This means Sandboxie has been leaving "traces" of files that should be encrypted in the above SBIE_Temp folder.

The SBIE_Temp folder is also > 6GB in size, which wastes drive space, far bigger than any other folder in the Temp directory (the next one down is just 19.3 MB).

Question 1: Is there a way to completely stop this?
Question 2: Did older versions of Sandboxie also work like this?
Question 3: Why does sandboxie work like this?

I never noticed this with older versions (I jumped from v3.76 straight to v5.10 so I am not aware of anything tha happened in between).

Thanks a lot!

[Craig@Invincea]

as for 3.76...that's deprecated and old code. Basically, we have not idea what it may or may not have done.

Invincea started coding SBIE starting w/ v4.

Don't know if the encryption has something to do with it as a possible swap space or not.

Sandboxie has been leaving "traces" of files that should be encrypted in the above SBIE_Temp folder.

Um, it's probably the encryption leaving a swap of sorts, much like when you use Bitlocker on Windows to encrypt the drive.

[Scoox]

Thanks for your reply. Firstly, it's anything to do with my drives are encrypted: I use TrueCrypt which uses on-the-fly encryption, which means everything happens on RAM. Encrypted volumes are mounted as regular partitions and, as far as applications are concerned, look no different from real non-encrypted partitions. I only mentioned ecryption to highlight the fact that security is important to me and Sandboxie is causing a vulnerability.

This problem only happens when I copy items (Ctrl+C, Ctrl+X, or otherwise) in Explorer windows running in a sandbox. When I copy files in any other third-party file browser (e.g. Voidtools Everything), also sandboxed, no files are created in SBIE_Temp. It doesn't happen with folders though, only files. Could this be a bug?

Doing Ctrl+C on a file in Windows only copies the path, no files are physically copied until the paste command is issued. This doesn't happen outside Sandboxie, as one would expect.

I thought you might know what "SBIE_Temp" folder is for, and under what circumstances Sandboxie uses it.

ALSO, please note that the fact that the folder name is SBIE_Temp means it's got to have been created by Sandboxie.

[Scoox]

Sorry, that was supposed to read "It's not anything to do with..."

[Guest10]

I can see the Copy file operation that happens when copying a .txt file in sandboxed Explorer.
If I run Explorer sandboxed, and then right-click > Copy a .txt file in my Downloads folder, I find that a copy of that file has been created (not a link to the file, but an actual copy of the file).

Reading the original post in this thread, it looks like it's reporting that the file copy was created outside of the sandbox.
In my case, it's not.
The actual path to the file that is created is inside of the sandbox, for me.

Original file:
C:\Users\Paul\Downloads\OpenLibrary URL address.txt

Path to the Copy that was created:
C:\Sandbox\Paul\TestBox\user\current\AppData\Local\Temp\SBIE_Temp\1d1ba5bfd704880\OpenLibrary URL address.txt

Another copy operation of the same file creates:
C:\Sandbox\Paul\TestBox\user\current\AppData\Local\Temp\SBIE_Temp\1d1ba5d32db6d72\OpenLibrary URL address.txt

In each case the file copy is a duplicate of the original file, and is created inside of the sandbox.
Files that are copied into the sandbox are typically those that have been opened for "update", so I assume that's what's happening here.

[Syrinx]

I saw something similar in my tests while trying to reproduce but the folder was only inside the sandbox (actual directory) and started off at temp_001 with no "SBIE_" before it. It seemed to be a result of making use of Quick/Immediate Recovery but only when long file names/paths were involved.

Guest10's likely hit the nail on the head already.

[Scoox]

First and foremost thanks for your replies.

I inspected my sandboxie.ini file which contains the following command:

Code: Select all

...
OpenPipePath=C:\Users\%UserName%\AppData\Local\Temp
...

I originally used that in some sandboxes that are "non-disposable", meaning that program installers were run in the sandbox so the sandbox contains the program and all configuration data, thus turning such programs into portable apps.

If I delete the above command from sandboxie.ini, the temporary files will still be created, however, inside the sandbox. Here is the thing: Sandboxie can copy entire folders and their contents without creating any temp copies, so I don't understand why for single files it needs to create a copy This is a problem particularly when copying large files, such as ISO or video files, and it causes unnecessary write cycles which reduce the life of SSDs.

[Scoox]

Bump.

This is proving to be quite a problem for me. I just downloaded a large software installer package (~500 MB) using my web browser, then clicked "Open containing folder". Since the browser is running sandboxed, the Exploer window spawned by my web browser is also sandboxed. As soon as I hit Ctrl+C on the file, Sandboxie proceeds to copy the file to the SBIE_Temp folder. I repeat, this only happens when copying files: copying folders does NOT result in any copies being made, proving the fact that there is no real need to make a copy. If I hit Ctrl+C again, a second copy is made, even though one copy had already been made the first time. This doesn't make sense.

While the file is being copied, the Explorer window freezes giving the impression of a crash. The copying goes on in the background so there is no indication of what's going on. Please can someone test this with a large file?

The following animated screen capture illustrates this issue:



Thanks!!

[Craig@Invincea]

What version of SBIE are you using?

And please don't bump. That's a quick way to get banned... [ I deleted it. ]

I believe that is expected behavior. But I'll let Curt confirm when he can.

[Scoox]

Sorry about the bump.

I'm using 5.12, it also happened in 5.10 though.

At the moment everything else is working smooth. All the problems I had with Sandboxie under Win7 are gone since I upgraded to Wīn10.

[Scoox]

I believe that is expected behavior. But I'll let Curt confirm when he can.

Sorry I forgot to add that, even if it's expected behaviour (and I can't really see how), you surely you can see why I find it disadvantageous:

● Each time I hit ctrl+c on a file, a new copy is made (if I ctrl+c 5 times then 5 copies are made).
● The temp copies are not removed automatically, so the sandbox keeps growing.
● Ctrl+c on a folder containing files doesn't make any copies, yet I'm still able to copy the entire folder and its contents.

Thanks a lot

[Scoox]

Hi again, I just updated to v5.14 hoping this would have been fixed, but it hasn't yet. I wonder if you've made any findings? It's literally the only problem I'm having with SB, everything else is working silky-smooth.

I would suggest you try yourself hitting Ctrl+C on a large file (e.g. an ISO image) in a sandboxed Explorer window, and see how this is a problem. Every time you hit Ctrl+C Sandboxie will create a whole new copy of the file in the SBIE_TEMP folder. It really seems unreasonable.

As I said, it only happens with sandboxed Explorer, if I use a third-party file browser, also sandboxed, no files are created in SBIE_TEMP.

[Scoox]

Hi again, it's been a while since my last post, just wondering if Curt had a chance to look into this issue? I just tested this on a Win 7 machine and it doesn't happen, but using the same sandboxie.ini on both systems, the problem still happens on Windows 10. If possible could you have a quick go and test at your end on a Win 10 64-bit machine?

Please remember that Sandboxie is creating a temporary folder named "SBIE_Temp". The string "SBIE_Temp" must be hard-coded somewhere in the source code of Sandboxie, and it shouldn't be too hard to at least determine what code is causing this problem. Thanks again!

[Barb@Invincea]

Hello Scoox,

I was able to see this behavior on a win 10 machine.
I will do some digging and get back to you.

Regards.

[Scoox]

Thank you so much!!