Restricted user accounts and 'User/Shell Folders'

[wraithdu]

I'd like to use Sandboxie here at work. I have administrative account access, but the user level accounts are pretty restricted. I can load Sandboxie OK and run programs. However my launchers for portable apps seem unable to retrieve any values from 'Shell Folders' or 'User Shell Folders'. They come up blank, so anything referencing $APPDATA, for example, is pretty much broken. I don't have this problem on my home computers. Do you have any idea why this would be?

I thought I read somewhere that Sandboxie changes the rights of a program in the sandbox. Could this be part of the problem?

On another note, why can't Sandboxie be launched via 'Run As...'? Would it work with PSEXEC from the PSTools suite, or would it have the same problem?

[tzuk]

I'm not sure I understand. Are you asking me what could be the problem in your code? Or am I not getting what you're saying? I don't mind helping, it just looks like you're asking me why does my code work and yours doesn't, and with no other details, it's a bit difficult to answer. Or maybe I didn't understand.

What do you see when you use RunAs with Sandboxie? And on what part of Sandboxie do you use it?

[wraithdu]

I'm asking why an NSIS launcher running inside Sandboxie would be denied access to the 'User/Shell Folders' keys. I'm sure it has something to do with the security restrictions on regular user level accounts on computers here at work. So, when a program is run inside Sandboxie, how are its security rights changed?

Ok, this is a little hard to explain. In NSIS I can use variables like $APPDATA to extract the current user's 'Application Data' directory. Same goes for any number of NSIS constant variables - $PROGRAMFILES, $WINDIR, etc. Normally my launchers, when sandboxed, have no problems retrieving these variables. However at work it seems that access is for some reason denied, and all varibles like this are returned blank.

I guess I'm just asking how the security rights of a program are changed when it is sandboxed. As I said, I have an administrative account, so Sandboxie itself is not hindered.

On the second point, I launched my portable version of Sandboxie from a user level account via 'Run As...' into an administrative account. When I try to load any program sandboxed the error I get is -

SBIE1223
http://www.sandboxie.com/index.php?SBIE1223

this one I think. It clearly states that using 'Run As...' won't work. I was just curious why, and if PSEXEC from the PSTools suite might work instead.

[tzuk]

I'm asking why an NSIS launcher running inside Sandboxie would be denied access to the 'User/Shell Folders' keys.

If you run the same thing unsandboxed, it works fine?

So, when a program is run inside Sandboxie, how are its security rights changed?

Actually I can't think of anything that should affect querying the registry.

I was just curious why, and if PSEXEC from the PSTools suite might work instead.

Aha, I remember now. It has to do with the way Sandboxie applies some of the protection, and this is incompatible with RunAs. You'll have to try PsExec yourself.

[wraithdu]

I'm asking why an NSIS launcher running inside Sandboxie would be denied access to the 'User/Shell Folders' keys.

If you run the same thing unsandboxed, it works fine?

Yep.

Actually I can't think of anything that should affect querying the registry.

I just checked the NSIS help and it isn't clear if it is getting the values for those variables from the 'User/Shell Folders' keys, or from the PATH environment variables.

I understand that your security shouldn't affect querying the registry. But if Sandboxie 'demotes' a program to some other user class, and security restrictions are in place on the computer for that user class, then wouldn't they apply to any sandboxed program? ie - denied access to certain parts of the registry?

[tzuk]

It just strips a couple of privileges that would enable a program to load drivers and such. Hardly anything that should affect the registry. I think you should try the Windows built-in 'reg' command, sandboxed and unsandboxed, and compare the results of querying the same Shell Folders registry data.

[wraithdu]

I got an interesting result with the old 'reg query' commands. Unsandboxed everything is fine. Sandboxed is a little weird -

reg query "HKCU" - returns all keys
reg query "HKCU\Software" - returns the first 3 keys only, and "Error: More data is available."
reg query "HKCU\Software\Microsoft...." - etc. returns keys/values normally

What does that mean? Weird...

[tzuk]

I also get an error running "reg query HKCU\SOFTWARE" sandboxed! RegEdit works fine, though. It's a bug, obviously, and I'll have to fix it.

[tzuk]

You can re-download Sandboxie 3, which is now version 3.00.02, and you shouldn't get this error message anymore.

[wraithdu]

The bug is fixed, but my original problem remains. This is going to be hard/impossible to troubleshoot since I don't know exactly what security restrictions are in effect for the user accounts.

Are there any permissions changes you can think of that would trigger this sort of problem? My next test is to see if this happens while logged in as a regular user. If not, then it's definitely something sandbox related. I'll post back.

Oh, currently testing with v3.00.03.

[wraithdu]

Well, I solved my own problem by accident. I wrote a simple script to enumerate most of the important NSIS constants/environment variables. It worked fine. Turns out it was some bug in the NSIS compiler. I recently updated to 2.29 from 2.28 and now everything works fine.

Sorry to trouble you with this tzuk, but we squashed that other 'reg query' bug though, right?

[tzuk]

Sorry to trouble you with this tzuk, but we squashed that other 'reg query' bug though, right?

Right! A very positive side effect.