Virtualization software and integrity levels-your expert opinions...

-edit-

Just to clarify any doubts, I did test whether or not extracting zipped files using an unsandboxed 7-Zip kept the low integrity level, and it did.

 

I assume start/run restrictions don't work-I assume blocking this with high-integrity level in virtualized zone of Sandboxie would not work either.

 

I'm not really sure I understood your doubts. But, once you take something out of the sandbox, there's nothing Sandboxie can do.

Just to clarify, if anyone was having doubts, and I didn't explain better before, my downloads folder is not forced to a sandbox. My downloads folder is in my real system. The downloads folder has an explicit low integrity level, which forces anything within it to also have a low integrity level. A low integrity level object cannot execute to medium/high integrity level areas.

Because I was running 7-Zip in Sandboxie, Sandboxie broke the integrity levels security model the O.S applies to objects and containers. In this case, I made the O.S apply an explicit low integrity level to the Downloads folder. Sandboxie broke, and breaks, this security model. It shouldn't, IMHO.

 

Than I guess Hungry Man was right. If you run high integrity level of any program/process/execution (you can block it by start/run restrictions, if we're talking about malwares) inside the virtualized zone inside the Sandboxie, than there is no harm at all, you're safe.

 

@m00nbl00d

Maybe to try..

If you allow direct access to downloads directory, unzip with sbie, to downloads directory, does IL still not propagate?

Reverse, go into sbie directory, set downloads directory to low IL. Unzip, recover or whatever you have been doing to real downloads directory. Is IL still low?

I wonder, if direct access is not allowed, perhaps it is the IL of the downloads directory within the sandbox that is the culprit. I haven't looked, but if sandboxie copies files from sandbox to real system, a copy inherits medium by default. Only moving will carry the inherited IL. If sbie is not moving files when it recovers etc, it might be that it is extracting to sbie directory, getting a medium IL because nothing has told it to do otherwise, then it copies the file to real system, and the medium stays.

Sul.

 

I didn't need to test it, because I know that the low IL would be inherited.

But, that wasn't my point. My point is that I shouldn't have to weaken Sandboxie's protection. Does the fact that giving direct access to a folder in a sandbox excuses Sandboxie when it breaks the ILs when not giving direct acess?

The purpose of not giving direct access, is that I can choose what to retrieve from the extracted zip files, etc. Any other security implementation I may have in my system to cover direct access has really nothing to do with this. No one can expect me to have any other security.

Maybe Sandboxie could be coded to work different; maybe it can't. It doesn't and that's a big bummer.

You cannot do that. You cannot apply ILs to containers and objects within the Sandbox folder. You can, they just won't be applied. Sandboxie doesn't support them.

Yes, it's because that. When Sandboxie isolates the downloads folder, when extracting the files, it won't respect the low integrity level of the folder. That's precisely the reason I previously mentioned that Sandboxie breaks the O.S security model.

If Sandboxie respected the O.S security model, then moving/copying files from a folder in a sandbox wouldn't be any different than copying a low integrity level object from the downloads folder into a medium integrity level container, which would inherit then a medium integrity level; and then, copying it back to the downloads folder, then inherit the low integrity level back.

In the real file system that's what happens. But, not when Sandboxies comes into play.

As I said, maybe Sandboxie could work different, maybe it can't. That's a big bummer.

 

I just saw your post here:
Is it secure to run the browser for home banking inside Sandboxie? It depends. If we're talking about a system that we know, without any doubts, that it's clean, then yes. Just restrict Start/Run Access and Internet Access to the browser's own process.
xttp://ssj100.fullsubject.com/t427-windows-vista-windows-7-sandboxie-integrity-levels

 

I'm not really sure if that was suppose to be a joke? Why are you confusing two different topics?

One topic is about ONE TEST I did. If others wanted to follow that approach, is their concern and their own problem. And, I only introduced Sandboxie, for two reasons: Keep files within it and then easily and securely erase them using, say, Eraser. Another reason, for those wanting to restrict Start/Run Access.

But, if you actually bothered reading the rest of that thread - that I created - then, you'll see that user ssj100 also comes to the conclusion that Sandboxie isn't needed, at all... in my "test"... except, IMO, for those wanting to easily and securely erase the temporary browser files with something like Eraser; something that Sandboxie allows to automate. So, why not have it all in one "box", right?

But, don't make of that an important thread about Sandboxie as it has nothing to do about Sandboxie, at all. I introduced it only in the Sandboxie's sub-forum, for the sake of what I already explained above.

Also, you failed to see that in that thread, I had purposefully APPLIED a HIGH integrity level. But, this browser would be used for a very special purpose only - connecting to the bank's server. Nothing else.

So, to resume - despite I started that thread over Sandboxie sub-forum, over ssj100's forum, it was only for the sake of keeping all temp files within a single directory in an easy way and easily and securely delete it. Sure, one can also restrict access. Not really needed. I just did a test.

What I introduce here - Wilders Security Forum - has to do with one thing only - Sandboxie breaks the ILs. It also breaks in the test I've done with the HIGH IL browser. Anything recovered from the sandbox will get the High IL, even if placed in a low integrity level folder. So, be careful with that approach, if you do decide to use it along side Sandoxie, and for any other scenario other than home banking. lol

There's no Start/Run Access in what I'm talking about. You'd be RECOVERING, not KEEP in the sandbox. And, if one were to follow Sully's suggestion (as a test he suggested), then there would be nothing to recover, as everything would be automatically recovered.

 

-edit-

Just to clarify a bit more. That thread over ssj100's forum had to do with a test where I've run a browser with a high integrity level against keylogger and other forms of loggers running with an inferior integrity level. That approach blocks it 100%.

That's what that test was all about; not Sandboxie.

 

Ok, I understand now, but I still struggle to understand your approach. I feel you're trying to say that these changing integrity levels caused by Sandboxie itself would compromise security even though an malware/malwares are sandboxed and restricted to start/run and restricted to access the internet.
I'm wrong?

 

I think all m00nbl00d's saying is that the security is potentially compromised by Sandboxie's tampering of a file's IL, so it could become a problem when it's moved outside the sandbox and onto the real system. As he describes earlier, the file's expected low IL was broken when the file was extracted inside the sandbox and placed in the real system's low IL folder, as it instead was at a medium IL.

 

No hard feelings, OK?
Do these integrity levels change (from low to high) when you recover from (untrusted to trusted) with DefenseWall, Bufferzone or something else?

 

Thanks, wat0114.
I realized that file's integrity level is only compromised when you recover it outside virtualized zone, since it now has medium or high integrity level, but I realized that too late. I only hope I didn't make you or m00nbl00d too angry since my understanding of these integrity levels is very low. This is why I read yours and m00nbl00d's posts about this more often than usual.
Cheers.

 

Heck no, I don't think you made anyone angry, CoolWeb We're just trying to help, that' all. I don't understand this integrity levels stuff that great, only the bare basics, so I explain things the best I can

 

I wasn't angry. lol But, I just thought that by now you'd have a bit more understanding of how integrity levels work. Sorry if I sounded rude. But, when you pointed to a whole different thread, I just thought it had to be a joke.

No hard feelings.

 

No hard feelings. I've never used any of those other applications, but user Kees1958 did/does play with DefenseWall, and he says that they don't break the integrity levels and I got no reasons to doubt it. I don't recall anything about BufferZone, sorry. Maybe someone who uses it could verify it. It would be great to know.

I simply believe that a security application shouldn't break the O.S security model.

I made the mistake of believing Sandboxie wasn't breaking the integrity levels, and I happened to click an installer of an application I was going to test in an isolated environment. I'm just glad I had AppLocker loaded and running.

I hope no one thinks I'm saying Sandboxie is awful or anything like that. I simply wish it could work in a different way, by complying with the operating system security model. That's all. Maybe it's possible, maybe it isn't.

 

Sandboxie does not break the OS implementation of Integrity Levels. Sandboxie virtualizes the environment, and how it does that gives a false view that it does not implement Integrity Levels.

An integrity level is stored in the SACL (System Access Control List) of an object or container, the same as a DACL is. DACL (Discretionary Access Control List) houses the rights and permissions for the object/container in reference to different users/groups - allowing or denying certain things. The SACL is traditionally used for auditing type purposes, and is rarely used in a home pc, and even many business pcs. Corporate environments are usually the only ones utilizing SACLs.

Anyway, since Vista, objects and containers have had a default SACL entry for Integrity Levels, which is medium (technically, if one doesn't exist, it is assigned a default value of medium). Implicit values in the SACL, ones put there on purpose, are visible - default ones are just default because of a lack of an implicit value.

Regardless of whether the SACL has an implicit value or not, an Integrity Level exists for everything. Once you execute a file, the Integrity Level follows it, which is why you can see an IL on a process.

An SACL or DACL, when applied to an object or container with the likes of icacls or other tool, adheres to that object or container. If you move that object or container, that ACL goes with it. As ACLs are inheritable, where you move it might mean that another/different ACL is applied to it. However, if no other "higher level" ACL rule is in place, then when moving an object/container with an implicit ACL does nothing to the ACL -- the ACL moves with it.

If you were to COPY the object/container, then any ACL (SACL or DACL) that was set implicitly, does not follow the copy. I don't know why, but can only assume that the create of a new file (the copy) will inherit nothing but the defaults of the container it is created in.

All of this is business as usual. As a recap then, before getting into how this effect Sandboxie:

Every object (file) and container (folder) has a DACL (Discretionary Access Control List) and an SACL (Security Access Control List). The list is made up of individual values, called an ACE (Access Control Entry), and technically you have DACE and SACE values for thier respective list.

ACLs can be set to inherit, or pass on thier setting to objects and containers within themselves.

When you modify the ACL of an object or container, this is called an "implicit" value.

An implicit value follows the object/container if you MOVE it. It is (in my findings) going to stay with that object/container, although there may be other other ACL changes to the object/container depending on where you move it to - if the container you move it into has some ACL set to inherit, then the object/container you moved might inherit them!

An implicit value does NOT follow the object/container if you COPY it. The ACL it recieves is dependent upon where it is copied to and what ACLs it inherits.

---------------------------

Now, how does all of this fit into Sandboxie you ask? It isn't really that complicated, at least not any more complicated than ACLs already are.

Sandboxie creates a virtual environment, although it isn't truly virtual, only partially virtual. I say that because you can see the directory c:\sandbox, and all of the contents of this virtual environment are easily seen.

However, what Sandboxie does do is to keep this virtual environment segregated from the real system.

If you were to navigate, non-sandboxed, to c:\sandbox\box-name\user\current\downloads, you would find that directory has a standard set of ACLs. This includes the lack of an IL in the SACL, thus it is the default Medium IL.

When you do something within the sandbox (like extract a file or execute a file or copy a file), Sandboxie ALWAYS creates a copy. When a copy is created, whatever ACLs that were on the original are no longer found on the copy. You CANNOT tamper with the sandbox directory while sandboxed, at all.

For example, if you open explorer sandboxed, then navigate to somewhere within it, and then highlight an object (like an .exe), then try to drag that object to something on the real system (like a .bat file), you cannot do it. Ever. You can only drop the object to a process that is sandboxed. You can however open explorer non-sandboxed, navigate to that same directory, and then drag/drop the object to file on the real system (like a .bat file), and the result will be (as long as the file being dropped does not execute) that the real system uses that file, for real. If however, you were to drop that file, from the sandbox directory, to anywhere that it executes, then the execution opens in the sandbox. Marvelous how it works really.

So, what is happening, while somewhat confusing at first, is really not at all. Sandboxie does not allow contact with the real system. It NEVER , EVER, MOVES an object/container from the real system to the sandbox, UNLESS you make an EXCLUSION, like direct access. In its DEFAULT STATE, it ALWAYS makes copies.

Since it always makes copies, any ACL value, whether implicit or inherited, will be wiped clean, to be replaced by whatever ACL exists where the copy is made - which happens to be the typical allow execute, allow read/write and medium IL.

I could go on and on about the different ways you could test this. Create this folder, apply a deny execute or Low IL to it. Do it to the real directory, see the results or lack thereof in the sandbox. Modify the sandbox directory through explorer, then see the results.

But none of that matters really. What does matter is that everything is working as it should be working. Sandboxie is not breaking any OS implementation. Far from it. Rather, because of how Sandboxie keeps things segregated, and how it copies things rather than moves them, and how ACLs work in respect to copying vs. moving, things don't work exactly as you expect them to. But, I can tell you, if you truly desire to have the sandbox function just as the real system does, it is easy to do, you just have to understand how and where the "normal" behaviour is being modified by sandboxie.

Now, some might say this is unfortunate, that your customized (or default) security implementations are not duplicated by Sandboxie.. but after playing with this for awhile, I don't really see how or why Sandboxie should do this. It follows the default protocol the OS does when creating objects/directories. It just isn't, by default, examining the real OS customized ACLs and duplicating them in the sandbox. You can do that manually if you like, and get the results you want. In fact, through some testing myself, I can actually achieve (in my OWN opinion) better security than I have ever had.. at the cost of a very complicated setup. Not really what I am going to go further with ATM, but nice to know none-the-less.

Sul.

EDIT: this has no bearing on whether a browser opens an installer with High IL and such. This is strictly related to why it appears SBIE changes things like ILs.

 

I have seen code on this. I was going to mess with it, but honestly it was a little involved for what I was working on. I will see if I have my notes on it still, as I seem to remember copying that for future use.

Sul.

 

When I mentioned that it breaks, I didn't mean that it doesn't work with them. I meant that it doesn't comply with them - with what we set. Maybe that's OK with you or anyone else. Maybe that excuses it not complying with what's defined in the real file system.

I'd very much like to see it comply with what's defined in the operating system. Sorry, but when I set a container as a low integrity level, then I'm setting it in the real file system. Sandboxie shouldn't break this - and when I mentioned that it breaks, this is what I'm talking about.

Actually, that's only 50% accurate.

If you copy a an explicit low integrity level object, that object will inherit what ever integrity level object the container where it's going to be copied on has. The object will inherit whichever integrity level the container has, whether an explicit one or not.

So, if I were to copy a file with a Low IL to another folder, and if this folder had a Low IL, then the file will also inherit a Low IL. So, what you mentioned it's only half true. It depends where the file will be copied too.

If Sandboxie respected the O.S security model, then the downloads folder/any other folder with an explicit integrity level would be applied the same integrity level inside the sandbox. It doesn't, because Sandboxie doesn't support ILs. Not in the way you think it does. Sorry, but it doesn't.

And like it or not, the O.S does allow the user to modify ILs, so it's still part of the security model, isn't it? Sandboxie breaks it.

Again, this is only 50% true. An object will only retain its integrity level IF moved into a container that has NO explicit integrity level.
If you were to move, say, a low integrity level object to a container with an explicit medium/high integrity level, then the object will inherit that IL and lose the low IL.

Yes, that is true. But, I truly don't get where you're trying to get?

I mean, I'm saying that Sandboxie doesn't mirror the integrity levels. It does not, and it doesn't, because it doesn't support them.

I remember security researcher Didier Stevens asking Tzuk to support integrity levels, quite some time ago, and the guy got was practically insulted. Didier Stevens were suppose to create a DLL to do it; never came out, though. Not sure what happened.

Anyway, I do understand how integrity levels work.

Sandboxie should mirror that security model. That's the reason why it breaks IE, Google Chrome and Adobe Reader's sandboxes. It doesn't mirror.

 

On my real system I have file A at low integrity.

In Sandboxie I have program X

Program X tries to write to program A so it is copied to the sandbox.

Program A is now medium integrity.

I'm assuming this is correct?

Whether it follows the OS protocol or not is not important - the OS is not assuming that there's some 3rd party virtual environment changing things. Not that I care one way or another.

 

You and I know each other well enough not to take offense, so I will say for others, this isn't personal

It does not break, in any fashion. It works exactly as it is designed to, from what I can tell anyway. It is true that it does not comply with what you set in the real OS, but that is not a fault, but more like the laws of how it works.

It does not break it.

I believe it to be 100% accurate.

lol, I was using the term "implicit" before, my mistake, it is explicit I believe
Yes, a copy is void of an SACL. The parent directory (or grand-parent etc) where the copy is created in will determine what ACLs the new object has. I thought I had stated that already, but maybe not clearly enough.

I thought I said that in more than one place, like this one

There is no need to be sorry. I am objective. However, you are incorrect. Sandboxie does indeed support ILs. Really, it isn't that Sandboxie really does anything to ILs, it does not. For all intents and purposes that I can tell, it is neutral in that respect. Rather, what you are seeing, is that the directory c:\Sandbox is created with a defined set of ACLs, and I think these are the default set that any custom made directory would get - meaning Generic read/write, generic execute and no IL, thus a medium default.

What happens then is that when SBIE creates its COPY of your downloads directory (or an object within), the one which you have set an EXPLICIT Low IL to, is that it creates a copy just like normal, but because the parent directory (the c:\sandbox\xyz\123 directory) has nothing to tell it otherwise, it just gives it the default set of ACLs, thus a medium IL.

Yes of course we know the OS allows explicit ACLs to be set. But Sandboxie does not break it. It does exactly what it is supposed to do when it creates a file in a directory - it allows the OS to apply the correct ACLs to the new object according to the inheritance settings of parent directories.

Again, I will say I am 100% correct, but with the inclusion that it will depend entirely upon whether the IL of an object being MOVED is explicit or not.

If the object has no explicit IL, meaning its IL comes from inheritance of its parent, then moving it to a directory will cause the object to inherit its new parents ACLs. Example is your downloads directory has an explicit Low IL, set with OI CI for inheritance. If you move an object with no IL to the downloads directory, it will inherit the Low IL, but it is not explicit. If you were then to move this object to a directory with an explicit High IL, the object would inherit the High IL, not keep the Low IL, because it was always inherited, never explicit.

Now, if you have an object with an explicit Medium IL, and you MOVE that object to a directory, like the downloads directory, which has an explicit Low IL and set with OI CI to inherit, the object will KEEP its Medium IL and pay no attention to the Low IL. This is because explicit ACEs take precedence over inherited ACEs.

So, what I said is 100% true, in my tests, 100% of the time. Easy test - create directory with explicit Low IL with OI CI set (I used chml). Apply an explicit Medium IL to a file, in another directory. Now MOVE the file with explicit Medium IL to the directory with explicit Low IL. Use chml to examine the file. You will find the file still has the Medium IL even though it now lives in a directory with Low IL set with OI CI to inherit. The nature of the explicit IL on the file says to ignore the attempted inheritance, because explicit has precedence over inheritance (normally, but there are some work arounds I think).

I am pointing out that the percieved lack of support for Integrity Levels (or any ACL for that matter) my Sandboxie is directly affected by not only the ACLs of directories both in the sandbox and outside the sandbox, but that the way Sandboxie creates the data within the sandbox is always by copying.. and copying does not carry over any ACLs - all ACLs the copy gets are determined by the directory in which they are created.

I think that is a good term, MIRROR. It does not mirror them, but not because it doesn't support them, only becaus Sandboxie does not first examine the objects and containers which it is going to recreate in the virtual environment. It fully supports ACLs, or should I say, does nothing one way or another to them. The thing that is missing is that Sandboxie, to fully keep the explicit ACLs, should be first examining the ACL of a directory, and then recreate within the c:\sandbox directory those same ACLs. Then, when it copies and object, the directory the copy is put into will be the same as the real live OS directory. It might get sticky though when creating the virtual files, as if a file in the real OS had and explicit IL of Low, Sandboxie would also have to set that explicit Low IL within the virtual file system as well. Oh, it can be done, I have done it. It is not that Sandboxie breaks anything, only that it doesn't create it itself, but rather uses a more generic ACL for everything.

I would assume that he was going to create a dll with an API that Sandboxie could call, perhaps as a plugin, that would examine live objects/containers ACLs, and recreate those within the virtual environment. That would be very nice IMO.

Of this I have no doubt! And I think you fully understand ACLs as well. They are tricky though to follow sometimes.

Agreed.

Also, it may be that we are saying the same thing, only our definitions of "break" are different. I don't see it as what Sandboxie does to break anything, because I don't think Sandboxie is doing anything in terms of ACLs really. But you see it as Sandboxie is not fully recreating within the virtual environment what existed in the real OS, thus to you it breaks it.

To me, it is strictly a matter of what ACLs exist, at what level, and whether objects are being copied or moved. From what I see, everything is normal in the technical nature.

Sul.

 

It doesn't break the system, it just kinda... ignores it and the OS handles the rest.

 

Yes, that's what happens. But, from my point of view, that's like breaking it, because like Sully mentioned (and which is what I've been trying to say), regarding the fact I introduced Didier Stevens:

YES! And, from my point of view, Sandboxie failing to do that, which is something that it should natively, IMHO, it breaks it... doesn't mirror it... whatever word we like to use. *edit* I actually don't think he wanted to go that far; he simply wanted to explicitly apply integrity levels from within the sandbox. What we're talking about here is a bit different, I suppose. Doable, but different. *end of edit*

I suppose that's what's happening.

Also, regarding the copying/moving of an object, when I say you're only 50% accurate, I'm not saying you're 50% wrong. lol I only tried to explain - for anyone who doesn't understand much of what we're talking about - that when moving/copying such an object, that same object doesn't either have to keep or loose the previously applied IL. We can kind of keep it, provided the folder where we're going to place it, will force it to have the same IL. lol

The day it gets personal, I'll head over the U.S and slap you with a dead sardine. (For anyone, this is just a joke... I mean... poor sardine. )

 

I am with you on this one. Ignoring the system is effectually breaking it.

 

High Integrity Level = Green
Medium Integrity Level = Orange
Low Integrity Level is Red

Sandboxie to the OS Police (policy that is): "I am not driving through red, I am just ignoring the traffic light"