Sandboxie drop rights function

Interesting thread here:http://www.wilderssecurity.com/showthread.php?t=271723


Any ideas?

noor

My goodness, I just spent about 20 minutes writing up a reply to this, and it all got deleted (internet must have died and when I clicked "Send", everything got wiped and I was logged out somehow...either that or someone hacked me haha).

So what to do? Well, I'll just summarise:

-Sully has set out to do some tests on how Sandboxie's "Drop Rights" function works
-This is what we'd be expecting: running programs in LUA = running programs as Basic User (via SRP) = running programs in sandbox with Sandboxie "Drop Rights" enabled. That is, in each case, nothing with those respective restrictions can modify C:\, C:\Program Files, or C:\Windows.
-Here's my appraisal of his tests:

1. As Admin - no SBIE - all files are modified
2. As User - no SBIE - denies boot.ini opening, eula.txt is read only, cannot create file in prog files
3. As Admin, using SRP - no SBIE - same as above

4. As Admin - in SBIE - no DR - all files are modified
5. As User - in SBIE - no DR - all files are modified
6. As SRP - in SBIE - no DR - same as above

7. As Admin - in SBIE - yes DR - boot.ini denied - prog files allowed - eula.txt allowed
8. As User - in SBIE - yes DR - same as above
9. As SRP - in SBIE - yes DR - same as above

1. Expected - you can do everything as Admin. That's why don't run as Admin by default! Haha, sorry, can't help promoting LUA.
2. Expected - this is why running as a limited user is so much more secure.
3. Expected - presumably Sully means running as "Basic user" with SRP enabled in your Admin account. Running any program as a "Basic user" essentially strips down that program as if it were running in a limited account.
4-6. Expected - remember here that files are only modified in the sandbox. The REAL system is untouched.
7-9. Interesting observations, and perhaps why I don't put much faith in the Sandboxie "Drop Rights" function. You would expect that with the "Drop Rights" function enabled, anything running in the sandbox would be unable to modify (the virtualised versions of) C:\, C:\Program Files, and C:\Windows. But somehow, they are able to modify content within C:\Program Files and C:\Windows (but not C:\). And by the way, this is nothing new - many people, including myself, have reported this behaviour on the Sandboxie forums. Sully just happens to be another one now haha.

Anyway, if you really don't want your sandboxes to be able to modify the above directories, simply apply step 4 under Sandboxie here to not just C:\Windows, but also to C:\ and C:\Program Files:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16

In my opinion, it's not a required step at all. I really only implemented step 4 for fun (perhaps to show off the versatility and configurability of Sandboxie). Remember that Sandboxie keeps everything on your REAL system untouched by default (unless you specifically configure it otherwise).

As for the rest of the thread, I must admit I don't have much knowledge with regards to Windows ownership and file/folder rules (although I know enough to ensure my LUA + SRP setup is water tight). However, I don't think it matters at all to what Sully was trying to ask/test.

Oh, and by the way, I stopped using "Drop Rights" in each of my sandboxes a long time ago (when I switched to LUA). It's just not required, particularly if you run as a native limited user. Even if you don't, Sandboxie does its job very well - keeping your malware threat-gates isolated from your REAL system.

Thanks for the reply ssj100.

Well I do implement step 4,with C:\Windows,and also and C:\Program Files.

Pretty nutritive dense reading,that thread. thanks for sorting it out to where I and 80% of other users can understand it.

noor