Chrome sandboxing method, for other applications?

From what I've read on the subject, the Google Chrome sandboxing method (as implemented on Windows XP) can theoretically be used for applications other than Chrome or Chromium.

Could it be used for arbitrary applications in practice though? If so, what would be required for that? Could the "token" method be e.g. used to sandbox a web server, along the lines of a properly managed chroot, or a FreeBSD jail?

 

Well, Chroot/FreeBSD jail create an entirely separate filesystem for Chrome tabs. Windows assigns low integrity and alternate desktop tokens. Are we talking about Linux or Windows?

Either way, it can be applied to any program (see Adobe Reader) but those programs have to be built to use it. They need to create a broker and limited process.

So you can't just slap it on a program and get it working, but developers can make use of it if they're willing to rewire their programs.

 

Ah, okay. I was wondering if one could write a program that assigned such tokens to itself, and then started whatever other program as a child process. I guess the answer is that that wouldn't work, as the "sandboxed" program needs to be written such that it can take advantage of the sandbox?

BTW, are these "alternate desktop tokens" related to the desktop objects used by the Sysinternals Desktops program?

 

Also, have to ask: am I the only one who thinks Windows is looking really awful from a security features standpoint? Default security setup may be better than most Linux distros, but Windows has got
- No equivalent of chroot, let alone jails/containers
- Nothing along the lines of OpenVZ, VServer, User Mode Linux, etc.
- No MAC system profile generator for applications (see AppArmor or Tomoyo)
- A licensing system that makes full virtualization an absolute pain, especially for desktop users!

I can't help but feel that Microsoft is shooting itself in the foot in some way.

 

I don't know anything about the Sysinternals Desktops program but the alternate desktop token basically separates Chrome into a separate security context.

You could write a program that assigns itself these tokens, it just wouldn't be the Chrome sandbox. It would be stuck in low rights areas and if you used the desktop token on all processes it wouldn't show up. Chrome works because it has a broker process that handles all of these things and separates the renderer and tabs etc into other projects.

Nope. You are definitely not the only one.

Chroot's are really cool. They're mini filesystems within your own filesystem, beyond anything Windows has. They weren't designed for security but you can easily harden them through the kernel or even apparmor (because you need root to break out a chroot.)

There's also seccomp filters, which directly reduce visible kernel attack surface, which makes gaining root incredibily difficult.

There's Apparmor, SELinux, and Tomoyo, which can restrict incredibly well, far beyond what Windwos does. For example, even if your Windows application fits perfectly within a low integrity sandbox it can still access other programs in that sandbox and their files - so if they both have access to low integrity folder X they can share read/write access. Linux allows you to separate files/folders via PID owner to avoid crossover.


I mean... just compare Chrome on Windows and Linux. Chrome on Windows makes use of the windows ACL system better than any program I know of. It's got absolute least privilege in terms of what Windows will allow. Linux Chrome basically craps all over that Sandbox. The sandbox is insanely strong. I can understand a Windows bypass but I will be shocked if a Linux Chrome bypass ever shows up in the wild - the time it would take is ridiculous.

One FTP software dev implemented Seccomp filters and basically said "If I were trying to hack this program, I don't think I could." It is insane how locked down some programs are.

And if you're using pax/grsec you can
1) Deter bruteforce exploits by driving up the time it takes to fork processes after a crash (and deter in 3 other ways)
2) Restrict root
3) A thousand other things lol

There's just no comparison between Linux and Windows security.

 

This sounds rather similar to the RunAs "Protect My Computer" option on Windows 2000 and XP, which is so overly restrictive that very few programs work with it. Overly aggressive security mechanisms discourage secure use, etc.

Kind of sad to hear that, because there are some aspects of Linux that are a royal pain.

(For instance, managing a Ruby on Rails install on a Linux system! This is where Microsoft's GUIfied software management really comes in handy.)

I do wonder if anyone's working on MAC solutions for Windows, or sandboxing solutions on the level of OpenVZ/VServer/FreeBSD jails/Solaris containers. The only ones I know of are:
- Sandboxie (more secure technically than Linux chroot, I think, but seems less flexible; e.g. can you make a Sandboxie sandbox that excludes Windows system DLLs?)
- GesWall (limited, hard to use, seems to be rather inflexible)
- BufferZone Pro (end-user oriented, not sure it's still alive)
- Comodo Sandbox (end-user oriented, and the way Comodo describes it is not encouraging)
- WinJail (Don't know anything about it)

Of these, it looks like only Sandboxie and WinJail would be remotely adequate for protecting a home server... Assuming the server process didn't start as a system service before $SANDBOX could put a straightjacket on it.

 

Yes. If the program doesn't fit within the sandbox it can't use it at all. This isn't the case with Linux, where you can sandbox any program no matter what rights it needs (including programs that run as root.)

Windows 8 may help. They're creating AppContainer sandbox, which may or may not be up to par with Apparmor.

I don't think Sandboxie is more secure than chroot. Both are weak to the same thing - root users. Sandboxie needs the "Experimental protection" to protect you against a program running as admin, and it's still not built into the kernel so it's limited. Chroot creates an entirely separate filesystem, you can create a new OS in a chroot. I think it's more powerful. You can also harden chroots by compiling your own kernel so that it can restrict even root.

Chroots are also built entirely in the kernel. Sandboxie is not.

Sandboxie is still powerful and probably the best tool for Windows if you want that type of function but it's not as powerful imo. And can Sandboxie sandbox services like th eprinter service? IDK.

If appcontainer is as good as apparmor it still won't even out the playing field entirely but at least it'll put Windows back in the running.

 

Chrome really is taking the lead here, now I see Untrusted Level appearing, even lower than LOW

I have a friend who uses Spyshelter Free with all security turned off, he only uses the experimental Restricted Mode for some threat gate applications.

 

Interesting. What are the restrictions on Untrusted? Would that be the same as "Protect My Computer," i.e. no writes to the registry or any folders? What about read access?

BTW Kees I took a look at the link in your signature...

This is an interesting strategy, but in the case of everything other than Chrome, isn't it relying on a compromised application dumping an executable payload in one of the usual areas, instead of e.g. in C:\Program Files? Or are you relying on UAC to prevent that? Just wondering.

 

Untrusted? I think it only has access to the tmp folder. Can't remember. I'm surprised Chrome is running at untrusted. That's interesting.

Read access isn't restricted at any integrity level that I know.

 

That's kind of surprising. As I understand it, ACLs should make doing that (by default) fairly trivial.

 

Chrome does restrict reads with ACLs. I just don't think that any integrity level does by default. For example, if I manually set a program to Low Integrity it can still read the entire system, it just can't write to it. But there are still ways to prevent reading up.

I'm wondering what those processes that are running untrusted are. I would think the renderer but it looks like tabs.

I think process explorer may not be reporting properly.

 

How exactly would an untrusted process be able to access (I suppose you mean writing?) to the temp folder? The temp folder runs with medium integrity level, and only a subfolder in it, appropriately named "Low" runs at low integrity level. And, again Low is higher than Untrusted. By definition a lower integrity level object cannot write to a higher integrity level object, which is why there's the broker process, which runs at medium integrity level.

There are no Untrusted integrity level areas in the system, only a very few Low, to where Untrusted cannot write on their own. In Chromium's case, it will need the broker, running either at medium/high (depending on the user account, and if without or without UAC). In my case, the broker runs at Low.

 

You'd be thinking wrong. If you do bother to run Chromium in Windows (not sure about Google Chrome stable version, but Canary/Developer/Beta should be there already), and then open PE, you'll see it says --type=renderer.

 

If it's the renderer that makes much more sense as it needs virtually no rights. I would have found it hard to believe if it were per-tab.

Like I said, can't really remember which folders have specific integrities.

I'm surprised there hasn't been a Chromium Blog or some statement about this new level of security - I would think they'd be bragging as much as possible.

 

UAC + AppLocker rules

 

See Picture, Your assumption is right, renderer tabs have no access, the 'reduce GPU sandbox', problably acts a second broker for the renderer tabs.

 

BTW Hungry Man - I set up Sandboxie on a Windows 2000 VM, and it looks to me like it offers more features than a chroot jail - not as many as LXC by a long shot though. It looks pretty secure.

(That said, it seems to be designed for dealing with malware. I'm not sure how it would stand up to a human intruder.)

 

Chroot isn't very flexible at all but you can do more with it by virtue of it being built into the kernel.

For example, on my 64bit Ubuntu I can create a Chroot environment and install a 32bit chroot'ed Ubuntu environment inside of it - I would be installing an entire operating system into it. When you create a Chroot you create an entirely new root file system. With Sandboxie you create a layer above your file system. It's just very different.

Of course, with Sandboxie you can poke a hole here or there. It's like AppArmor with copy-on-write ie: LXC.

So while you have finer access control with Sandboxie (compared to chroot) the things you can do with a chroot are incredible.

 

It will probably be the same thing. The guy who created AppArmor (Crispin Cowan) took a job with Microsoft about 4 or 5 years ago, so I assume he is working on a similar MAC system over there.

 

I hope it works well. It'll really bring Windows much more up to speed.

 

When you implement the KB2532445 fix for AppGuard, Windows 7 will show AppContainer in stead of untrusted, see pic

 

I don't think they would be quite the same. AppArmor has its protection based on path names, to the best of my knowledge. Integrity levels do not.

The only thing missing in Windows 7 MIC is forbidding a lower IL object from reading all other higher ILs. AppContainer solves that.

 

Very interesting thread with some very interesting points of view. But first I need to say that I'm not a programmer and don't have much technical knowledge about either OS, in this case Windows and Linux. So my comment could be read as how an average computer user might see it.

What about if you bring software like Shadow Defender or returnil, deep freeze in the mix on windows systems ?
Assuming that SD, returnil, deep freeze are working as they theoretically should work of course.

Why won't the people at microsoft create their own virtualization technique and offer the user a choice when you boot up windows 7/8 ?
Something similar to the choice when you press F8 to be able to get into safe mode of windows.

Virtualization isn't the entire ultimate answer, as malware might still be able to steal personal information. So it still needs to be quarantined or deleted as soon as possible, but at least at next boot up, everything you did wrong or infected is gone.

To me, as a average user with limited technical knowledge/skills, it is still baffling that Windows doesn't have some kind Sandboxie, Shadowdefender or other virtualization techniques built inside its kernel.

Microsofts own 64-bit kernel protection seems to hold off some bad software but at the same time "preventing" good software like sandboxie or full blown av products to do their job well. Hence the "64-bit experimental mode" inside sandboxie to somehow work with 64bit kernel of windows.

Anyway, I'm going on a limb here, please forgive me for saying this but:
It almost seems if Microsoft doesn't want software like shadow defender or returnil or deep freeze to work, so that AV/anti-malware companies stay in business !
Ok, its a bit harsh from me, but you would almost be thinking this at some point if you get very frustrated at times when the system is compromised/infected for x-th amount of time.

Anyway, it would be awesome if Windows has something like Linux Chroot or jails. But I'm afraid that such things won't work well with the current NTFS filesystem with its permissions and such, as far as I know of course.

anyway, cheers !

-------------------------
edit here:

Ehmm seems like AppContainer inside windows 8 as shown by comments of Kees1958 would be very promising.
I don't have windows 8 running and haven't used it at all, so my knowledge about windows 8 is very very limited, please excuse me if get things wrong of mixed up.

 

great to see chrome's sandbox is further being improved. do you have any article reg. the same?
quick googling did not return any?