Problem with Sandboxie and EFS.

[SomeUser]

First of all, excuse me for first posting in the wrong forum.

The problem I found in version 4.02 (64 bit) is: I am unable to read encrypted files with EFS inside the sandboxes, my guess is this happens because now the sandboxed processes are opened using the ANONYMOUS LOGON account which doesn't contain the needed certificate to decrypt the files. Is there any workaround to this? I would like to keep using this version since now it has full protection for 64 bit Windows .

My system:

Windows 7 SP1 64 bit
Sandboxie 4.02

Thank you in advance.

[tzuk]

Thanks for posting in the right place! Can you tell me what steps I need to take to reproduce the problem? That should include setting up the EFS, which I don't know how to do. Thanks.

[DR_LaRRY_PEpPeR]

That should include setting up the EFS, which I don't know how to do.

Properties > Advanced... > Encrypt contents to secure data? I guess that's what this is about? EFS isn't available on Home versions of Windows (well, it sounds like they can decrypt, with key, but don't have the interface for applying).

I just tried on XP (never used encryption before), and get "Access denied" when trying to apply encryption, and when trying to open a file that was previously encrypted. Drop Rights didn't make a difference...

[sphinx8911]

Hello,
I am a paid customer, and I have the same issue.

Here's a 100% reproduce case (tested on Windows 8 Pro 32-bit).
1. Go in windows explorer, make a folder to store .torrent files, right-click on this folder > Properties > General tab > Advanced > Encrypt contents to secure data, then OK. Windows will create EFS cert if not exists and set folder to auto-encrypt any files created inside it.
2. Add this folder to Direct Access Folders (OpenFilePath) in Sandbox settings.
3. Setup uTorrent, open it sandboxed.
4. Options > Preferences > Directories > Store .torrents in: <Set to folder created in step 1>
5. Close / reopen uTorrent (so settings can take effect).
6. Now download any .torrent file to desktop.
7. Go in uTorrent > File > Add Torrent... > Browse to Desktop > choose downloaded torrent file.
8. You will get error: Unable to save file ".torrent" (because uTorrent wants to copy the file to the .torrent storage folder and this folder is EFS encrypted).

- Here's an interesting thing:
If uTorrent is set to force open sandboxed, and you double-click on the encrypted file to open it in explorer, and it already exists in the encrypted folder, uTorrent can read it successfully.

But if within the uTorrent UI > File > Add Torrent... you browse to the torrent file, you will get access denied (or unable to read).

Maybe uTorrent should intercept perhaps the OpenFile Win32 API call and open it through the Sandbox Control UI process (which runs with the local user who has the EFS cert) then pass the handle via IPC in case OpenFile fails due to EFS. Otherwise, maybe uTorrent should somehow get the user consent and marshal the EFS key to the sandboxed process. Especially if it is a direct access folder. (Maybe for normal sandboxed path it doesn't matter because recovery is handled by the sandbox control process, so no problem here).

[SomeUser]

To add to what sphinx8911 and DR_LaRRY_PEpPeR said this is other example to reproduce the issue:

- Find any executable (let's say cmd.exe) and copy to any folder.
- Right click in that folder and go to Properties.
- In the "General" tab click in "Advanced" button and then check the option "Encrypt contents to secure data"
- Now try to run said executable inside a sandbox, you will get this error due to the encryption: System Error Code: %1 is not a valid Win32 application. (193)

Now, following the steps mentioned I found some cases in which cmd.exe was able to run successfully, but I'm not sure why.

What I said before about the account used was because the EFS certificates are associated with the user account as stated in the MSDN article: http://technet.microsoft.com/en-us/libr ... 00811.aspx

"File encryption uses a symmetric key, which is then itself encrypted with the public key of a public key encryption pair. The related private key must be available in order for the file to be decrypted. This key pair is bound to a user identity and made available to the user who has possession of the user ID and password. If the private key is damaged or missing, even the user that encrypted the file cannot decrypt it. If a recovery agent exists, then the file may be recoverable. If key archival has been implemented, then the key may be recovered, and the file decrypted. If not, the file may be lost. EFS is an excellent file encryption system—there is no "back door."

[tzuk]

I looked into it and I can reproduce the problem. I agree that it probably has to do with the different user account associated with the process in the sandbox (ANONYMOUS LOGON) vs the user account that created the encrypted folder.

The workaround suggested by sphinx8911 may or may not work. It is the filesystem layer that is blocking the "open" request, and we don't know for sure that it won't block a "read" request even if the problem with the "open" requested was somehow worked around.

I am sorry but I am not going to research this further at this time. Perhaps consider TrueCrypt as a replacement to built in encrypted folders.

[SomeUser]

I see tzuk, it's a shame though but I understand you must be busy with other things in this new version. However isn't there any chance you can give us (the users) the option to run the sandboxed programs in the local user account instead of ANONYMOUS LOGON? I wonder if this could be a security hole, but it used to be like that in previous versions.

About the suggestion of using TrueCrypt, well I don't think it would be a handy alternative, the good thing about EFS is its transparency to the users and the applications, if I would use TrueCrypt, I would have to mount the container everytime I have to use the sandbox, not to mention I would have to symlink the sandbox to the mount letter (this wouldn't be a big problem if you don't delete the contents of the sandbox eveytime you exit, but since I do use this feature, it would delete the symlink everytime as well)

Anyway, I hope you can add the option I suggested and/or look after this in a future.

Regards.

[tzuk]

Looks like TrueCrypt has some kind of auto-mount system, and you can put the sandbox directly on the TrueCrypt drive with a FileRootPath setting (you can search for example in the forum). I don't know if I can fix this incompatibility so if this is really important to you, consider looking into TrueCrypt more seriously, or use an alternative to Sandboxie v4.

[BUCKAROO]

Have no doubt that your encrypted data is strewn about your drives, unencrypted, unless you use whole System Drive and/or Partition encryption.