My friend wants to learn how to use sandboxie.

The Drop Rights option seems to imply it's effective only for Power users and Administrators. Does it provide additional security for limited/standard users?

BTW, I created a second sandbox, and now when I log in I get two SB control icons showing in Task manager. Is this normal?

 

Considering that all would start with an exploit, either against the browser or a plugin (flash, pdf reader and Java - These would be the main ones to be concerned about.), one would need to mitigate the exploit to the most possible.

Right from start, and as user Hungry Man mentioned, one should use a browser that is secure, by design. By secure, I mean a browser that will try to render the exploits useless. In Windows Vista and 7, that would be Internet Explorer and Google Chrome. I got no intentions of causing any browser wars, at all. It's just that, by design, these two are relatively more secure than all others. Under Windows XP, I'd go for Google Chrome, due to its sandbox going further than IE's.

On top of it, I'd use Microsoft EMET. Add the browser process under its protection. Except for Firefox, plugins initiated by IE, Chrome (I believe with Opera as well?) are automatically protected by EMET as well.

If you search the forum for EMET, you'll find some useful threads about it, showing which processes should be protected, like processes belonging to Java, browsers, etc.

Sandboxie supports EMET. At least, judging by the compatibility options.

I'd also allow plugins (flash, java, pdf reader) on a per-site basis, only. You can allow flash on a per-site basis with IE8, without any issues. IE9 allows you for any plugins, activexs, if my memory isn't failing. There's been quite sometime since I last looked at IE9.

Google Chrome also allows you to disable plugins and then enabled them on a per-site basis.

This approach will decrease the attack surface.

If you really want to be paranoid, then you could install something like AVG LinkScanner, which protects against exploits.

But, as I previously mentioned, one should separate tasks. One sandbox for general web browsing. Another one for sensitive tasks. You could try to restrict access to your banks IP(s), etc in your firewall (for the browser).

There are a few ways one could mitigate what I mentioned. Others for sure have their ways. I find these easy to implement and deal with. Most of all, except for Microsoft EMET (and Sandboxie), everything is already provided by the browsers.

 

DRs option wouldn't be effective against what I'm talking about - something exploiting the browser/plugins and hijack the browser's process, which is allowed to run and access the Internet.

The only protection, besides using different sandboxies, would be to prevent/mitigate the exploit(s). DRs has no effect on it.

I also would not run my sandbox for sensitive tasks at the same time as another sandbox with Internet access allowed.

I don't think that Sandboxie prevents one sandbox from reading another? If nothing has changed, I don't think it does.

So, consider the exploit in question, where it hijacks the browser's process from the general web browsing sandbox. The malicious code in this sandbox (inside the browser's process) can read from another sandbox where we are performing sensitive tasks. The same applies to running sensitive tasks while doing other online stuff, even outside Sandboxie. Bottom line is: whatever may hijack a browser inside a sandbox will be able to read and send.

This is why I like to separate tasks between different standard user accounts, as well.

 

Alright, thanks! I only intend to run one sb at a time - one for web browsers and the other as just an occasional file test environment.

I think I've answered my second question, that it's not normal to see two SB control icons in task manager. I logged off then on again, and now only one icon displays there.

 

I have quite a few sandboxes, and only one Sandboxie Control process. I'm using the last available beta.

-edit-

Never mind... situation is normal now..

 

DropRights treats the actions within the sandbox as if it were in the real OS. Because there are no restrictions to c:\sandboxie\box\drive\programfiles, it acts as if it were admin and can install etc there. DropRights makes the sandbox behave like the real OS, so that the "program files" directory in the sandbox is treated just like the real "program files" directory - meaning you need certain rights to install there etc.

I haven't checked in vista/7, but in XP if you were a user, and you ran an installer in the sandbox, it would allow you to install. Once you ticked the DropRights, the installer would run but not install, just as would happen to a user in the real OS. I cannot recall now if there is a way to RunAs/UAC when using DropRights or not, if you wanted to allow an install in the sandbox when using the DR option.

I have never seen more than one icon in my tray, but it is usually hidden anyway.

Sul.

 

Thanks Sully!

I seem to remember quite a while back, either in these forums or Sandboxie's, SB developer tzuk almost brushing off DR as if it were a minimal security enhancement, although I really can't remember his wording, only that he basically said "enable it if you want". However, if it works as you describe, and I've no reason to doubt you , then it seems it will provide some enhancement to security.

 

Yes, Sully is right.

You could easily try it yourself, by sandboxing Explorer in a sandbox without DropRights enabled. Delete a folder in Program Files. Free pass.

 

I have it set as auto for deleting at the moment when exiting the sandbox browser and the windows update yellow shield has not appeared. Does this mean that maybe sandboxie deleted my windows update stuff since the yellow shield isn't coming up on the tray and maybe it got deleted just like the Firefox auto updates? If I have it set as automatic, would the windows updates get deleted too?

 

Maybe I'm doing this wrong, but whether DR is enabled or not, I can delete a folder in Program Files in a sandboxed explorer environment. The account is an XP limited one. Of course the real folder still remains; good thing I guess

 

I can't test it with XP, as I don't have it installed and no machine (vm) where to install it.

But, I'm wondering if it could be a bug with Sandboxie? Or XP behaves differently?

 

Well, maybe, and I did check the test directories (real system) I created under the admin account and the permissions were standard "Read & execute" "List folder contents" and "Read" for users, before I started the test. BTW, please see this...

Again as with the previous test m00nbl00d suggested, even with DR enabled, I was able to install - not only run - a small program (ntregopt-setup.exe) in the sandboxed Program Files directory.

Hopefully someone else can try this. If this is normal behaviour, then I suppose this underscores the importance of applying Start/Run Access restrictions in most sandboxes, at least Internet facing ones?

*EDIT* Darn! I almost forgot to mention, with SRP enabled, it blocks attempted launching of executables even in the sandboxed explorer environment when under the limited XP account. Very impressive

 

I don't distrust Sumatra, as much as I just don't completely trust PDF readers as a whole. I see it as an attack vector and feel better having it isolated and in it's own sandbox.

I've heard many times now that you should use 2 different browsers: 1 for regular browsing, and 1 for sensitive stuff (online banking, purchasing). I don't do banking online, but do purchase things. I'm not sure I've ever really heard exactly why you should do this though? It wouldn't be enough to use the same browser with 2 different sandboxes?... one of them not allowing anything but firefox.exe internet access or start/run? And clearing the boxes after every session?

And the problem is I can't think of what alternate browser to use. I love Firefox. I feel I can make it the most private browser with tweaks/add-on's, so I'd feel inclined to use it for my sensitive browsing. But... 97% of the time I'm just browsing normally, so naturally I want to use my favorite browser in that facet instead.

IE8 is the only other browser I know my way around. I have it set up to autostart in private browsing mode & with Inprivate filtering turned on (count set to 3). 3'rd party cookies disabled. Ixquick search, WOT, and some GP edits to harden it. And a sandbox custom tailored for it. Think this would be safe to use for the sensitive browsing? I really don't want to go through a learning curve for a new browser (Chrome).

 

@wat0114

I had a conversation with Tzuk over at sbie forums about DR. He was not excited about it because it did not do much, only made the security token that of a user, much like DMR does.

What I have always experienced with SBIE was that it did not matter if you were a user or an admin in the real OS. This was because the directories that make up the sandbox did not have any ACLs tied to them. Since there were no restrictions via ACLs, they were treated as a directory with free access, thus I could always modify areas in the sandbox I could not on the real OS as a user.

The DR option modifies the security token in the sandbox so that it mirrors the real OS. If a user had no rights to the real directory "windows", then in the sandbox that directory would be off limits as well. It has worked every time I tested it on XP.

When I used SRP on XP to run Kmeleon as a Basic User, I truly fell in love with SBIE. I thought it was the neatest thing that I could log on as an Admin, use SRP to make Kmeleon start as a User. Now my browser could not install to anywhere but my user profile, yet my normal activity still were admin.

Next when I forced Kmeleon into a sandbox, because the directory c:\sandbox was not restricted, my now restricted browser was suddenly not restricted! I used that to my advantage all the time, knowing that my browser was restricted in the real OS, but not within the sandbox. I went about business as usual then, not fearing much of anything because if sandboxie failed, the actual process was restricted anyway, and any child processes would be as well.

When I first started messing around with the DR option, I started questioning it. I did not understand really what it was doing. I thought it was doing more than it was, and I was testing it with the wrong methods. Eventually I stopped over-thinking it and discovered what Tzuk was trying to say. It is really simple, and not that interesting from a technical standpoint.

I have not really used DR because I actually want most of my sandboxes to remain the way they are. In XP was, to me, sort of counter productive for what I was seeking. I mean, I would log in as Admin, start browser as User, force into a sandbox, and force browser to be a User in the virtual environment.

Anyhow, I tested it from User account and Admin account in XP many times, and it always exhibited the same behaviour. Perhaps the new versions apply an ACL to the sandbox directory? Back then, there did not seem to be any ACL other than what was inherited. Also, the owner was normally the user, so perhaps that was why it was doing that then, or for you now. All I know for sure is that under normal circumstances, the c:\sandbox directory is not going to be off limits to a user because the OS knows nothing about it since it was installed after the OS was installed, and the c: drive does not propagate any ACLs that are restrictive.

@luciddream

I use 2 browsers because I want to know, without a doubt, which one I am using. QTWeb has only one purpose in life for me. There is no confusing it. There will be no accidents. I could do it a few different ways, no reason not to I suppose. My wife is probably why I did it, as she kept using both browsers on her machine, even though I tried to segregate them. It got me thinking, how can I make it almost fool-proof? My answer was to create a very wide separation for distinction.

I don't know just how "dangerous" it is to use credit cards and account numbers online. I would much rather be doing some coding or something than looking at stuff like that. It might be overkill. What I do know is that my wife has had 2 attempts made on her identity, without the internet being involved. In fact, the card was never used nor signed, yet somehow the bills were being sent to a different town about 120 mi. away. Quite strange. So now, I simply don't take a chance if I don't have to. That is why I use a box just for online actions of the sensitive nature.

Sul.

 

Sully,

thank you so much for your efforts and the time you took to seek answers

Maybe this is why I'm able to install to and delete the sandboxed directories, even though in the real system they afford only the normal limited rights to users.

I will try some other tests that are starting to come to mind, tomorrow. I've dusted off the XP vm, updated it with MS patches and installed Sandboxie on it. I'd rather play in it than on the real system.

I'm getting reacquainted with SandBoxie and really want to understand it better than I currently do

EDIT

Couldn't wait 'til tomorrow. You are right Sully; under the Security tab of the sandboxed explorer in the Standard XP pro account, the rights for User are the expected Read & execute, List folder contents, and Read, yet I can delete the folders even with DR enabled, so even though the rights are the same as un-sandboxed, Sandboxie seems to allow the Standard user the same rights as an Administrator. Most importantly, of course, the real, un-sandboxed off-limits-to-Users directories are untouched.

 

Actually, I can delete even with DR enabled, as well. I don't know what I previously did...

-edit-

I suppose this makes sense. C:\Sandbox isn't offlimits.

 

Yeah, it all has to do with understanding how the rights are actually applied.

In XP anyway, there is a .inf file that is used at OS install. You can see what it is pretty much if you look at deftwks.inf or something very close to that.

What that file contains is every object and container (file and folder) that the OS knows about during install, as well as registry keys and services. For each item listed, there is listed the DACL and SACL values that will be applied.

What you end up with is that every object/container that is created at install time is set to things like:

Admin group: allow all
User group: allow generic read/execute

So, all of the objects/containers are mapped out, some in fine detail, some in bulk. Also included are the inheritance settings. Some directories will pass on thier rights/restrictions, others not so much.

What you see happening with Sandboxie is that the directory it creates, c:\sandbox, has no real restrictions applied to it from its parent, which is the c: root. Since there are no restrictions, it is fair game. If you stop and think about it for a moment, it makes pefect sense. The OS cannot possibly know what directories you will create on the root of c: . You might need to make a custom directory, or not. Since it has no way of knowing you will be installing Sandboxie, it is best then to leave it alone. But things are different when you start messing with %windir% or %programfiles%, because the OS expects things to change in there, and the philosophy is to make sure only Admins are able to modify/create. So when you install a program and a directory is made in those directories, they should inherit the same restrictions, which makes sense.

What your mind expects when you are a user is that since the real "windows" directory is only read and execute for a user, you would expect the same thing within the sandbox. But, because the directory is not "c:\windows", but rather "c:\sandboxie\box\drive\c\windows", those restrictions are not in place.

You could put them in place with a command line tool, and then you would not know the difference. But Tzuk made it easy, all you have to do is enable the DR feature, and those areas within the sandbox that would be restricted in the real OS behave as such. I don't know what he did exactly, if SBIE examines the actual DACL of the real "windows" directory, and then applies that same thing to the sandbox "windows" directory. I never dug that deep into it. But, it works exactly the way it should.

Understanding this aspect can give you more flexibility in how you manage your sandboxes. The nice part is each sandbox can have different settings, so you might find one use for DR in one sandbox, and not in another.

And further, as you now understand, there is an added benefit knowing that the true process in the underlying OS is running at a USER level, so that theoretically if the sandbox driver were ever exploited and a process managed to get into the real system, it "should" revert back to its real state, which would be that of a USER. I think I tested this by allowing direct access from a sandbox with a process, and while within the sandbox (without DR) the process could act like an Admin, when it was given direct access to a restricted area, it was restricted, as expected.

Sul.

 

That's the thing... Even with DropRights enabled, I'm still able to modify Program Files and Windows directories.

As a test, I have opened 7-zip, which I force it to run in its own sandbox. This sandbox has DropRights enabled. DropRights is similar to DropMyRights. So, once applying DropRights to a process, then this process should be given the User token. This would make it impossible for users to modify Program Files and Windows directories.

Such is not happening. I can modify just fine.

-edit-

For a brief moment I forgot that DropRights only has effect on Administrators and Advanced Users.

The tests I've done were conducted from a standard user account. DropRights has no effect within it. It should... IMHO. I don't want my sandboxed Program Files folders to disappear... lol

This is why both wat0114 and me were able to modify Program Files directory. DropRights has no effect on standard/limited user accounts. Bummer...

P.S: Anyway, one can still give Program Files and Windows directories Read-Only access permissions in the sandboxes. It does the trick.

 

Hmm. I distinctly remember starting a browser with SRP, as a User, then in SBIE it would be allowed to modify %windir%, yet when I enabled the DR, it could no longer. That is why I don't use it in most sandboxes. That was in XP btw.

Now you have me curious. I will fire up a VM tommorrow and see what happens. Honestly though, that was 2 or 3 years ago now? Memory might need an upgrade too

Sul.

 

That's just it Sully, as m00nbl00d also confirms as I did, that DR seems to have no effect whatsoever, at least not in a User account. I agree with m00nbl00d that nothing should be able to mess with the sandboxed directories if at least DR is enabled.You mention SRP, and if you check at the bottom of my post #62, it directly influences the sandboxed directories, as it prevented me from executing a file. This is why i feel a combination of SandBoxie with either SRP or AppLocker could form a near inpenetrable defense. Of course the Windows version offering one of these would be needed.

 

For every sandbox, if you go to Sandbox Settings > Resource Access > File Access > Read-Only Access

Add Program Files and Windows directories/others, and whenever you try to modify such folders, you'll be presented with an option to elevate your rights. As it would happen in the real Program Files and Windows directories.

Still, DropRights should work for Users as well. Not sure why only for Administrators and Authenticated Users. As you said, nothing should interfere with sandboxed folders (Program Files and Windows, as they are important folders), unless we wish it that way.

-edit-

By the way, I remember some thread at this forum, where someone mentioned that SRP was blind to Sandboxie sandboxes, as SRP operates in user mode, unlike AppLocker, which operates in kernel mode.

I hope I'm not mistaken, but I have a vague memory of reading it... I suppose whoever said that was wrong...

I'll see if I can find where I've read it...

 

Okay, thanks for that info m00nbl00d! I guess there's also restricting what can run in the sandbox, so nothing malicious could mess with the directories and files within them, but it's good to also see the method you've pointed out.

I'll re-test again this evening, just in case I missed something the first time, but I remember having to disable SRP to proceed with testing because of the SRP warning pop-up I got.

 

Confirmed, SRP does have influence on sandboxed directories

As for further testing of DR, it went differently this time Before when testing, I had created new directories under c:\ and named them simply as: test01, test02, test03...Checking the security tab revealed the typical User rights only, but of course as I mentioned previously I had no problems deleting them when they were sandboxed in my User account, whether DR was enabled or not. However, with normal system folders like c:\Program Files, c:\Windows, or even c:\Documents and settings, and all directories residing within these, DR does, indeed, affect things differently. As Sully stated (is he ever wrong?? ) it does seem to apply limited rights to directories sandboxed in an administrator account, and it even makes things more difficult for standard users to delete these directories.

I don't understand all the security implications of XP, NT, Win7 and so forth. it appears to be really complex so I'd rather not even attempt to understand as in depth as someone like Sully and some others do, because XP, at least, seems to place more importance on what can be done to the default system directories - and even to some of the directories that lie within these - such as those I mentioned above, than it does to directories created like the test ones I made under the admin account.

Basically in a nutshell: DR does add some degree of security to a Sandboxed environment, so it's probably not a bad idea to keep it enabled, although I sort of understand tzuk's casual view on its effectiveness, because it is, after all, only the sandboxed environment that could get messed up, and not the real system.

 

It doesn't have any effect on my system, under a standard user account. I can delete from Program Files just fine. For me, it does make sense, because DropRights only affect Administrators and Advanced Users groups.

Apparently, it behaves differently in XP. Are you sure you were on a Limited User Account?

Have you tested it on Windows 7 as well?

-edit-

This appears to back me up? http://www.sandboxie.com/phpbb/viewtopic.php?t=7921

 

My mistake in testing. I'm not sure what happened during testing in the standard account, but there was a scenario where it appeared I had fewer remaining directories after deletion. Maybe I had to delete sandbox contents so that's what I did this time. DR does only work for admins and power users by the looks of things.

*EDIT* there are some "Special permissions" afforded to Users in subfolders under the root directory, not found under the Windows directory. When I created those test folders under root, they of course inherited the special permissions. Not that this made any difference on what the sandboxed directories allowed me to do, only that it's kind of interesting to see this