To all Sandboxie fans, please explain

wow - having read the last few posts I can see why Sandboxie has fans - no end of things you can play with, tweak, disagree about. Great fun. I think, though I will just stick with Shadow Defender.

 

nobody can blame you for that LV. Both are great products and you cant go wrong with either.

 

Wow, I will have to read this thread once or twice more, very carefully. I stopped using SBIE for less than 2 months and am now completely lost with the DropMyRights feature... time to install SBIE again and see I've been missing....

 

This is interesting. A kind one over at SB forums showed me what the DropRights does exactly, well, in one case anyway.

The example was to give direct access (OpenFilePath) to a restricted directory for a basic user. I chose to open Program Files. I checked the DropRights box. Opened an installer for a tool in a ForcedFolder, and promptly got the reply that there was insufficient rights.

I repeated the same process from a ForcedFolder with SRP enabled, and same thing (expected).

I like this. This means that a little more freedom can be given to SB, in regards to allowing it direct access to areas that were previously kept locked down, such as the entire Program Files directory. With DropRights, one can still have direct access to the real filesystem with no worries of modification, well, unless there develops an exploit or something.

No matter, because since I use an SRP rule on that forced folder anyway, even if there was an exploit to SandboxIE's DropRights, it would still inherit the basic user restrictions. But what this does mean is that while I am taking extra precaustions on my folder where I downlaod installers to with the SRP, other areas that I may not be quite so concerned about, but that still are forced, can be sort of dynamically assigned the same restrictions based upon SandboxIE's DropRights.

MitchE323, you are very correct in it's ability. I am not going to lighten the restrictions of SRP on that particular folder I put questionable stuff in, but I can see I would not really need such stringent protection in other places.

Thanks very much for the dialogue that brought this about !!!

This is very cool now that I undestand what it is doing.

Cheers.

Sul.

 

Hi Sully,

I saw that thread at the SB forum but can't figure out what is meant by OpenfilePath and how it's restricted by DropRights Could you please give a bit of a step-by-step example of this? Sorry, this is baffling me atm.

 

I read the thread over there. It looks like a win-win for everyone. Lots of flexibility. I appreciate the dialogue also. Cheers! Here is a test for you also - leave SRP Basic User on a certain folder and do not check the Sandboxie DropRights feature - openfilepath to that folder and see what Sandboxie will allow. Will it honor the SRP?

Yeah, see you are talking exe and I am talking doc.

 

Yeah, I had already tried that. It works a charm too. SRP is indeed honored.

Thanks tho.

Sul.

 

That is ...... incredible. Seems Tzuk has it co-joined with Windows to be totally seamless.

 

It's okay, I figured it out after finally realizing the configuration needed editing.

 

NP. OpenFilePath is a 'hole' in SB, so that rather than cache the files in a specific directory to the c:\Sandbox\.. directory, and then have to recover, you can just 'direct access' the directory you create a 'hole' for.

In one of your SB boxes, right click and choose "Sandbox Settings". Now, navigate to the Resource Access\File Access\Direct Access listview item. On the right hand portion of the screen you should see it says, at top "Direct File Access (OpenFilePath)". Here, you can browse and choose a directory/file that you want to tell SB has full direct access to the REAL item.

The thoughts we are talking over, is that normally you want to be careful in wht you allow SB full access to, as some malware etc inside the SB environment, would have full access to the real file/directory you have granted full access. Potentially a bad thing. This DropRights feature is such, that if enabled, applies to all your full access items, a reduced rights assignement, so that if a malware in the SB were to try to access one of your full access items, it could be restricted to a 'basic user'. A basic user can only modify/write to certain areas. So as example, if Program Files had full access, and DropRights was enabled, a potential malware inside the SB could TRY to access and change something in Program Files, but because of DropRights, could only read/execute. Meaning your "OS" files are safe.

I use a hole to create full direct access such as this to a special 'downloads' folder, so that all my browsers download directly to a real folder, and there is no recovery needed. I also happen to ForceFolders that same 'downloads' folder, just in case something get's in there I don't want, or I am brain dead and start executing whatever is there because I forgot what it was.

I have been using SRP restrictions on that folder to ensure that IF there were a bad buy in there, he would be neutered IF he ever escaped SB or SB failed to Force him into a sandbox.

What MitchE323 is stating is that now SB does this on it's own.

Umm, does that explain it?

Sul.

 

Ah! A few seconds too late. Oh well, maybe someone else can gain too.

Sul.

 

Sul, you mentioned earlier that you had openfilepath both ways between two ForceFolders. Originally I thought one of the directions was not needed, but now I am beginning to see maybe there are more possibilities. Innovative you are indeed.

 

Sully, your explanation is excellent, and it demonstrates an easier way than how I went about it (editing the config file). Yes, I believe others, too, will benefit from your explanation. Thanks!

 

Yes, mainly for convenience. I wish to not have to recover always. Most common scenario is downloading .pdf or new tool or somthing. So my browser sandbox is set to have direct access to 'downloads' folder. I also tell the browsers to not ask me where to download to but to always save to that 'downloads' folder.

Since I may download tools etc that I don't know much about, rather than start up vmWare or just to be safe, my downloads sandbox also forces that folder as well has has direct access to it.

This is why I use the SRP on it. Of course that was before SB included DropRights. But still, it is an easy way to know where your downloads are going, and that I can easily open that 'downloads' folder, and test stuff out with a fairly high degree of security.

Sul.

 

Before anyone says "Hey, ForceFolder all of your drive folders and cross-openfilepath them all to each other", I'll just recco Returnil.

 

lol, that is funny. You would essentially be in LUA then.

You could achieve the same effect by creating an SRP that says to start explorer.exe as a 'Basic User'. This is intersting to do let me tell you.

SB is amazing for a good number of purposes for sure, more than it was probably ever intened for.

Sul.

 

That is directly from the interaction between Tzuk and his members. Some of the ideas over there that are explored (and some discarded), along with the FeatureRequest ability are really first rate. But they call us FanBoys lol

 

How does the new DropMyRights feature work on a XP home system? (No SRP)

 

That IS a good question. I usually install the GP to home, so I can use SRP. I have not tried to put a home user into a user group before, so don't know for sure. I would imagine though that home still has restricted groups just like every other NT OS does, so it should, for OpenFilePath objects, apply the restricted rigths. Although I am not 100% sure. Will have to play with that tonight and see just what effects can be had.

Sul.

 

Everything started by explorer is also basic user, so this effectively kills your admin account (can not do any admins things with it)

 

Thanks Kees1958 for starting this thread.

It has led to sharing of some really useful
nuggets of information about how to use
sandboxie more securely and efficiently.

Much appreciated.

soccerfan

 

I agree with Soccerfan. Good discussion is never a wrong thing. So Keys1958, do you have your answer yet? I went back and reread the opening post and the first three lines - are you good yet?

 

Funny that, isn't it?

Make a copy of explorer, called Aexplorer.exe. Add to SRP a path rule, stating explorer.exe runs as basic user. Reboot. Yep, you are now a basic user. Spawn task manager and end process explorer.exe. Now use New Task, and start Aexplorer.exe. Wierd stuff.

Or, set Aexplorer.exe to be a basic user, kill explorer and start Aexplorer.

Fun fun stuff to learn with. Honestly, the more I use SRP with Basic User, the more ways I find to use it and the more I like it. Maybe not so much for a novice, but for seasoned geeks, pretty fun.

Sul.

 

I already use LUA + SRP but I also use Sandboxie on top of it. I suppose the DMR feature in sandboxie is not needed in my situation but I wonder if it does since everything INSIDE the sandbox still assumes they do have admin rights.

 

I would say it would do nothing, but then the author of SB has not yet gave the full scoop in the thread over there.

In LUA, assuming you are a User, your rights are to read/execute everything pretty much, and create/modify only in certain %profile% directories. If you start SB with elevated rights, like with SecondaryLogon or SuRun, then SB would have full rights, and I assume that whatever it runs, example IE, would have the same rights SB would have. It could write to windows folder, providing it has an OpenFilePath to it. Otherwise it would only try to write to the c:\sandbox\windows folder.

If SB starts as normal User, then SB itself cannot write to windows folder, nor anything within it (I presume anyway). The DMR portion of SB allows a process in the SB to be stripped of rights, but this appears to affect nothing within the sandbox, only if the process tries to direct access something in the real filesystem.

So, since normally a process inside SB writes to c:\sandbox\windows or c:\sandbox\program files, there are no restrictions. But when it want to have direct access to c:\windows, that is when SB DMR stuff happens.

It might be of even greater use and easier to config, if SB had the ability to add acl strings to the c:\Sandbox\.. folders, this would give the process, internal to the SB environment, the same kind of restrictions the process would have outside the SB environment.

Sul.