SBIE and the Drop Rights option - does it work?

Yes, the lack of users rights is surely why the access denied is thrown. But why does SBIE honor this when it strips a token? In other directories, where files are denied modification by users, SBIE cares not, the stripped token does not effect inside the sandbox.


I went to post this over at SBIE forums, and someone already had linked it. It was also mentioned over at ssj100's forum (I didn't even know he had one).

It is not strange as to what is being denied and why, but why the difference in how SBIE handles them.

Personally it makes me want to break out an .inf file and modify crap everywhere again... but I digress

Sul.

EDIT: personally, this is of great importance to me because I liked the idea that in certain sandboxes, things would be treated as a user, and in others things would be treated as an admin. It is something I hope works. A comment on the SBIE forum made me believe perhaps I am not losing the memory, the comment was it used to work.. go figure.

 

This is how I see it,
From a non-admin account if you try to open for example boot.ini without the User:R you'll get access denied.
But for the other files don't think of it as modifying the files imagine you open the file change the contents then "Save As" to a different directory you have access to.

You'll be allowed, that's basically how I see sandboxie doing it, You'll even get the <OI><CI> rights like I mentioned earlier.
The only difference I really noticed was the attributes were changed,
Where as sandboxie made it more of an exact copy by keeping the attributes.

You just can't start a discussion without it being posted all over the place these days, lol.
And I didn't know he had one either...

Go for it, I'll wait for the results.

Well the way you explained it in the original thread sounded good and it would be nice if it worked that way.
I saw that post, maybe it did used to work differently...

 

Will have to see what tzuk says over at his place, but I think it is figured out.

@gizzy and doktornotor were correct it seems so far, that the Drop Rights feature of SBIE works with the live system and has no real bearing in the virtual environment of the sandbox.

I stand corrected then and now will eat some crow (or humble pie if I can fine some)

This does make sense, as I usually use files at the root that I know are protected to test whether something has reduced rights. Unknowingly I was testing against objects that had no users rights, so SBIE was throwing an error exactly like it should.

And now in retrospect, thinking of how the token is reduced via the method, I don't know that SBIE could easily be made to do what I hoped it did. It will take some manipulation of the sandbox parent directory.... actually sounds like fun to me, but...

So, you brave souls who pushed through the rhetoric in this thread, nothing amazingly new to state, only that others were right and I was wrong. Live and learn I guess

Sul.

EDIT: maybe I spoke too soon. It seems that if I restore an image that has version 3.40 on it, I get the results I was stating the whole time. For now, I will still eat crow, but I just did a quick test, and with the setup.exe for a utility called "advanced run", located on a storage hdd, if I start it with the DR option enabled, it says "administrator is required", and if I start it with the DR option disabled, it installs into the sandbox. Nothing special about the sandbox that I can see. Don't know what to make of it honestly.

And it goes on.. Installing TeamSpeak3 into the sandbox succeeds with DR enabled, even though it is supposed to write to program files. Running setup for Opera10.10 gives a message that the MSIServer service could not be started due to dropped rights. Are services virtualized? I never thought to look. GoogleEarth failed with no admin rights. MagicISO setup succeeds. SuDown2.2 fails. TugZip35 fails to install. TeraCopy fails to install.

I don't know if, with version 3.40, if it the manifests for use with UAC or just the fact that some programs install to user space and are allowed and some to denied space and are not. Either way, I am certain that in this version, at least on my machine, the Drop Rights feature works as I always thought it did -- it denies installation into restricted directories within the sandbox, just as would happen outside the sandbox.

Oh, and those program I tested (all setup.exe's) were just some I had sitting around on a hdd.

 

I have concluded that the only thing the stripped token of SBIE will effect within the sandbox will be to disallow access to a file without users rights to read, such as c:\ntdetect.com and if a program has the manifest needed for UAC compliancy that requires admin rights.

These two situations apparently examine the token level from the process, which has already been stripped by Sandboxie, and therefore throws the error properly.

Moderators, you may close this thread. The topic is dead and will most likely not be productive anymore.

Thanks.

Sul.