Submitted by One of the defining features of Google’s Chrome web browse is its sandboxing feature. You probably won’t realise it’s there, but from a security point of view, sand-boxing is one of the most impotant factors in browser security, as it severely limits the amount of damage a security hole can do: sure, you’ve got a hole in the browser, but thanks to sandboxing, you’re pretty much locked in – until you break out of the sandbox, of course. Sandboxing on the Windows variant of Chrome was a “complicated affair”, says Chromium developer Jeremy Moskovich, but for the Mac version, it’s all a bit easier and more straightforward. On Linux, however, it’s a mess.
If you browse through the Chromium source code, you’ll find the code relating to Windows sandboxing in the /sandbox directory in the source tree, and it consists of about 100 files. For Linux, Moskovich explains, the situation is a mess because there are several different mechanisms available, and each distribution (of course…) ships with a different mechanism – or none at all. “Finding a mechanism that is guaranteed to work on end-user’s machines is a challenge,” Moskovich adds. The wiki page for Chromium sandboxing on Linux details various mechanisms they’re considering – for now, Chrome on Linux does not do sandboxing.
On the Mac OS X side of things, the situation looks a lot brighter. The operating system’s sandboxing APIs are “easy and straightforward”, and makes use of sandbox_init(), “specifying which resources to block for a specific process. In our case we lock down the process pretty tightly. That means no network access, and very limited or no access to files and Mach ports.” After this it gets a bit technical, so to prevent misquoting or errors on my end, I suggest you read the rest of the blog post to get an idea of how it works on Mac OS X.
Again, we see a case where the fragmentation in Linux as a hindrance to companies releasing software for the platform. While Linux’ diversity on all levels is a blessing in that it allows for natural selection and competition, it’s also a curse for developers trying to write an application that can work well on as many distributions as possible.
I personally tested the recent Mac builds of Chromium on my Intel Mac (PPC is not supported because the V8 JavaScript engine isn’t available for PPC), and while it rendered pages just fine, it was still full of bugs and crashed constantly. My guess is that any final release for the Mac is still a way off, with the Linux version taking even longer.
I agree that Linux hasn`t found its one true Security framework yet. Smack and SELinux are in the Kernel but lack desktop distro support. App Armor has more users, but lives only as a patch at the moment.
But I am very confident that once Chrome on Linux gets the market penetration that will make it a viable target that natural selection will have found a winner.
Well, it has on fedora for years now. Novell decided to make the whole thing worse and introduce AppArmor.
It constantly amazes me that distros sit on the fence with Selinux like ‘Oh we’ll wait for something easier to come along’
Things will always be easier or harder on OS to OS. I wouldn’t say on linux it’s a “mess” for the reason I’ve outlined above. Don’t blame “Linux”, blame the distros since the poor kernel has had selinux waiting to be used for years.
Every time I have allowed SE Linux to be enabled, within 5 minutes an application I need to run doesn’t work with it. And I know, your answer is “don’t use that app” or “there is a way to make the app work with SELinux”, but the reality is I give up after several hours of plunging the depths. It is VERY infuriating, and it really stinks when people say “well, it works for me, must be your problem”. That is the Linux way – blame the end user.
My first question would be more along the lines of “what the hell are you doing that SELinux complains that much?” There is no way SELinux should be causing that much issues for you… SELinux hasn’t been an issue for a long time now
I had a Sidux Linux installation, with a separate /home partition. I installed Fedora 10 over Sidux, and tried to re-use my home partition. SELinux wouldn’t let me log in. I created a new home directory for that user. No dice. I struggled with it for two hours. I turned off SELinux. A security solution that takes longer to correctly configure than the OS took to install is highly impractical, to be kind. (Or, rather, that to longer to figure out it was never going to work and turn off than the OS took to install.) It didn’t help that, in true KDE fashion, there was more than one GUI app to control SELinux, and no clear guidance on which to use (the configurer I found first was a set-up wizard: the option to turn SELinux off was somewhere else entirely).
I had a Sidux Linux installation, with a separate /home partition. I installed Fedora 10 over Sidux, and tried to re-use my home partition. SELinux wouldn’t let me log in.
CentOS5/RHEL5 throw various SElinux errors if home directories are on NFS. Not very enterprise-y of them…
Just curious, have you relabeled your home directory first? Also, have you contacted one of SELinux team about the issue? It is good to ask help about the issue.
Edited 2009-06-03 19:51 UTC
No, I didn’t. Basically, I knew (and know now) nothing about what SELinux was and how it worked, and when it became obvious that a non-negligeable amount of work was going to have to go into getting it to work, I decided that it wasn’t worth it and just turned it off. Most of the other distributions I’ve used manage to get along fine without it (or, they’re very good at preventing me from noticing it): I wasn’t going to go to much effort to get something working that I wasn’t convinced I really, desperately needed.
I guess my point is that, if you want most/all main-stream distributions to ship and enable SELinux, it needs to be much, much more unobtrusive and self-configuring than it is. It probably should “just work” in most cases, and it should only require the user to do a lot of learning and configuring if the user wants to do something that’s outside of, say, 95% of the normal use cases. Sticking /home/ on its own partition and re-using it is something that I’ve done several times, is not particularly unusual, and not something that I think a given distribution’s security policy should add (several) extra steps too.
Shorter version: SELinux isn’t important enough to be worth me doing a lot of homework.
Edit: Actually, I think I did do something along the lines of relabeling it. I seem to recall that I eventually did get logged-in, only to have SELinux generate dozens of warnings about blocking attempts to access a bunch of my account’s various application configuration files. That was the point that I said, “this thing isn’t worth the hassle,” and turned it off.
Edited 2009-06-03 21:09 UTC
SELinux causes ‘a lot’ of issues for people, and it is highly debatable whether the effort is worth it. Even worse, configuring SELinux is like nothing you will ever do anywhere else on a Linux system.
SELinux very complex and not very well documented, no, I don’t want to have to create runtime policies as a response to everything and its configuration and APIs for actually getting it to work are very, very poor. It just isn’t worth the effort.
Managing an enforced SELinux is definitely a pain, but I think it’s be bearable when working on targeted mode.
Any app that wants to take advantage of SELinux could just provide it’s own policy.
Efforts have been made to document SELinux on Fedora 10 that can be seen on :
http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/index.ht…
There is a SELinux team ready to help as I have found after addressing a bug report. There is a feeling that some “expert” users are reluctant to admit they need help.
What application(s) caused that problem and which distribution is used?
It appears it is much easier to give an example without specifying the problem and blame Linux as a whole than simply submitting a bug report to SELinux development and mention what distribution is used.
I think many are missing my point – yes, each problem app can be resolved eventually (e.g., Lotus Domino Server on RHEL 5.0 – the install for Lotus Domino specifically instructs the user to turn of SELinux). Some of the apps are 3rd-party apps and are really the application creators fault, such as the above Lotus Domino. Other times it is an app that comes with the disto (networks apps in general come to mind). My point wasn’t to get “help” for my individual issues, but just to point out the difficulty for the end user with SELinux. It’s great to tell them to fill out a bug report, but it is not practical for most (by the way, I do report bugs in my distro, Ubuntu, at Launchpad).
Most users are just trying to use their computers for daily work, and thus will either disable SELinux or use something else. It is not the fault of SELinux, but just an example of how the lack of standardization sometimes hurts the “end user”. And as I mentioned, the poor end user is usually told to “get over it”, “file a bug report”, or “stop using that app” (such as my Domino Server experience – it was for a job!).
I bet this came about because you disabled Selinux and then loaded a bunch of applications. Later you restarted Selinux, but Selinux did not know about them and so, it did what it is supposed to do., Stop you.
You have to set Selinux to rescan the system, in order to catalog or register the objects security properties.
selinux takes a little learning but it’s not as difficult to figure out as people want to think.
ls -Z is your friend for looking at the contexts of file as is ps -Z for looking at the contexts of processes (along with all the other flags you would normally use of course)
One of the most common problems is people doing something like extracting a tar/gzip file in their home directory and then moving it somewhere else. The easiest example I can think of:
You extract the flash plugin and it is created in your home directory so now it has the context:
unconfined_u:object_r:user_home_t:s0
Now you move it to /usr/lib/mozilla/plugins
moving a file retains it’s context (copying would create the new copy with the correct context) so now it’s wrong. simply run restorecon /usr/lib/mozilla/plugins/libflashplugin.so or whatever it is… then it will work.
You can use chcon to change the context of a file if you want to do it manually as well; or if you know another file that has the correct cotext you can use chcon –reference <filetoreference> <target> to fix the target file.
And if you want to see the contexts associated with a particular service you can do something like ‘semanage fcontext -l | cut -d: -f3 | sort -u | grep “named.*t
And I know you’re saying why the hell do I need to know all that and even a little more… but in truth you really don’t. The selinux troubleshooter in Fedora 10 and 11 is pretty damn good about telling you what to do to fix your selinux issues when their is a denial. Not a 100%, but a good 95%+ of the time it’s right.
Might I suggest that, in terms of security at least, sandboxing in Chrome on Linux is probably a waste of time and resources? Read any sampling of a dozen OSNews comments to see the same old (and mostly true) security arguments trotted out before you, but the only benefit I can see to sandboxing in a Linux web browser would be isolating plugins and tabs from eachother so our pathetic excuse for a Flash plugin causes less headaches when it crashes – and I’m not even sure if that’s called “sandboxing”, or if it is, if it’s the same context!
Might I suggest that, in terms of security at least, sandboxing in Chrome on Linux is probably a waste of time and resources? Read any sampling of a dozen OSNews comments to see the same old (and mostly true) security arguments trotted out before you, but the only benefit I can see to sandboxing in a Linux web browser would be isolating plugins and tabs from eachother so our pathetic excuse for a Flash plugin causes less headaches when it crashes – and I’m not even sure if that’s called “sandboxing”, or if it is, if it’s the same context!
So, your argument for not using sandboxing is that it’s hard to get root user account even if something breaks out of the browser? Well, that’s a REALLY poor argument. The most valuable information on any computer is the users’ files and if anything breaks out of the browser it doesn’t need root account to read any of the users’ files.
I agree completely. If we, the community of Linux users, want to smugly brag about our platform’s excelent security, then it really should support (and support easily!) powerful techniques for limiting the damage that can be done by compromising one of the OS’s weakest points, as far as security is concerned. It’s a good point that I really don’t want someone who compromises my browser to be able to read my files (or, for that matter, to check in on my browser’s cached data, or peek at what’s going on in other tabs, since I do, for example, my banking on-line).
Sorry, I posted that well past my bed time
. Trying to sound eloquent, I came off looking like more of an idiot than usual. I wasn’t thinking of browser cache or flash cookies and such. I’m surprised sandboxing should be so hard in Linux though…
How did you get that out of the OP’s argument? I didn’t get much at all from it, but I didn’t see anything about root, etc.
I’d say it would be better to conceive a security framework agnostic sandbox and then implement a module for each security framework they’d like to support. I guess going for SELinux and AppArmor would be a safe bet. And being modular, nothing could stop somebody from adding another security “provider”. But for now, I’d go with a void security provider, if it can bolster their development. Heck, it’s an alpha browser, don’t expect it to be secure as much as a production ready browser.
That is your solution? Develop an abstraction layer for security systems? Because that worked out so well in the case of audio…
Edited 2009-06-04 07:06 UTC
No wonder: “SELinux XXX nobody understands this well enough to say something intelligent. Specific to Fedora?” (http://code.google.com/p/chromium/wiki/LinuxSandboxing)
They say “finding a mechanism [on Linux] that is guaranteed to work on end-user’s machines is a challenge” – it’s a challenge, not impossible. It will work soon enough. I wouldn’t say it’s a mess, they just can’t seem to figure out [yet] how to do it
Those poor Chrome developers who need to work on Linux sound a lot like poor me when I have to develop on Windows…
(And for my dayjob, I work on an open source application that gets packaged as a binary installer for Linux, Windows and as an app bundle for OSX, so I know the hurt of all three platforms firsthand.)
I’d have to agree.
Things taken for granted on Linux seem impossibly stupid on windows. Usually its a matter of grumbling, sometimes a group grumbling, then a half day to a few days of implementing a (grumble) workaround and making sure it works.
News must be getting lean nowadays.
At least while there’s no consensus across distros, they may as well continue releasing it without sandboxing and let the users/distributors deal with it. If Ubuntu gets a Chrome package, it will probably have the relevant sandboxing configuration included.
Bear in mind that different security frameworks, while a pain, is probably better for security in the end. If a big huge bug in SELinux is found, it’s not going to affect me using AppArmour on my theoretically Ubuntu packaged Chrome. That will even help the SELinux users, as viruses rely on there being lots of vulnerable people to spread efficiently.
Perhaps a better long term solution is for distrubtors to work on a lowest common denominator method of specifying sandboxing that will work across all packaging systems. Or use chroot
A chroot doesn’t garantee you security. It is more secure, but files will still be written on disk and nothing garantee you that an attacker couldn’t find a way to execute them.
Each time I read about Chrome developers saying bad things about development on Linux, I just laugh. That wiki page says root installation is not good option, what a joke
Do Chrome developers, expects to do the same crap they do on Windows, to install a binary on %LOCAL_APP_DATA% for each user????? do they understand the name says DATA!!!!! not programs, what they will do next time MS enforce better security policies and do not allow executable on Data directories, scream monopoly and that they are attacking Google, follow the good practices for the platform you are developing, for Linux, create a deb and an rpm and create a apt/yum repo like Adobe do for flash, use the system updater instead of the internal one on chrome
When I read the original blog entry, I don’t get the impression that it is about complaints. Seems that it is nothing but facts. It mentions something as “a challenge”, which gets transcoded in “a mess” in the article title here.
yeah, that is *peculiar* to say the least. It also appears from the wiki, that its more of a case of there not being a mechanism that is as flexible as they want, more than it being a problem the variety of mechanisms.
Have you ever been on some university computer being 2 years behind in software updates where the admin doesn’t care?
It’s a nice thing if you can do stuff yourself and install newer software in your home directory…
If the chrome devs hate Linux so much, why don’t they just refuse to support it? Getting a bit sick and tired of hearing nothing more than a stream of complaints from this lot.
Maybe it is me, but why do you conclude that Chromium developers hate Linux? Or do you only imply that?
I think the open source and Linux communities see Google as an ally to them. At least there not the enemy like Microsoft. Not including Linux as a platform for Linux could harm the thought of Google being nice to open source and Linux.
Personally I don’t really think Chrome is needed in Linux.
Because Google uses Ubuntu quite a bit I bet they would like to use their own browser on their machines. They could have said we use Ubuntu so that’s where we will support sandboxing, but they are going out of the way to find something that works for everyone.
Maybe because there’s constant vocal demand for it. Every time Chrome news is posted anywhere, regardless of what it’s about, there’s always at least one person going “Where’s the Linux version? When are they gonna release for Linux? Why does Google hate Linux?”
Hey, that’s my line.
In my oppinion Google does this sandboxing stuff only for marketing: people will go with Chrome because it has “sandboxing”. They should code without any bugs in the first place so there won’t be anything that a hacker could find to crash/exploit the browser. And regarding the plugins… collaborate with the plugin developer to fix whatever bugs are found. Or disable the plugin
Or perhaps because the browser is the number one attack vector and Google don’t want a reputation like IE for security.
Now that’s an excellent plan – why didn’t I think of this before?
Only the most trivial and stable (read: nothing but bug fixing is done on it) code is without bugs. Web browser is quite far from trivial…
The same is also true of sandboxing systems.
I’d love for you to locate these angels of coding – these people who can magically put out hundreds of thousands of lines of code without a single error because apparently for the last 30 years the software industry have been using the wrong person; maybe a CEO can give you a courtesy call as to finding out the location of these programming wizards that you claim exist.
I for one want to see more sand boxing, isolating of plugins, tabs, extensions and so forth; so that when one crashes the whole thing doesn’t come down in a screaming heap; when one component has a security problem the whole software stack doesn’t become a giant hole that a 747 could fly through.
You call it lazy, I call it good old fashion common sense; facing reality and doing something about mitigating those risks. To claim that ‘sand boxing’ is for the lazy is akin to saying that, “only wimps wear helmet’s”, “only bad drivers wear safety belts” and “only speeders need air bags”.
Edited 2009-06-03 17:17 UTC
Maybe you should volunteer your awesome, bugfree coding skills then?
I’m also waiting for cars that are never in accidents and airplanes that never crash.
Edited 2009-06-03 19:01 UTC
Obviously not written by a developer. Maybe a new to writing software developer that isn’t mature enough to realize it is a LOT, LOT, LOT harder to create perfect code than it sounds. Especially when you have people spending all day every day looking for ways to break your program and initiate a virus. If anything, blame the tools they have to use. If the tools were better, focusing on helping developers write hardened code they could spend more time on writing what they want their program(s) to do.
All of you are right. It’s difficult if not even impossible to create a bug free software, but that shouldn’t stop us from trying, no? Google has an army of programmers so even if a bug is found it could quickly be fixed and pushed to the “clients” via an automatic update mechanism.
Adding a security framework made by someone outside of Google is another vector for attacking Chrome, since if a bug is found in the security framework then Google wouldn’t have a way to fix the problem and will have to wait for a fix. That’s true with every software, as you add more features to the software you also increase the chances of a bug hiding there.
On the other hand, Google has a lot of money so it could hire a guy (or more) who knows how to “break” things and have him try to bring the browser down. If he finds a way, then the programmer team can fix the bug. It’s no shame to say “hey, we found a bug and we fixed it already, please upgrade”. History has also shown us that many users don’t switch the browser they like even if bugs are found… see the Internet Explorer share
so there is no risk in announcing that you found a bug and FIXED it. Mozilla is fixing bugs in Firefox all the time and still the user base increases.
Maybe application developers should not worry about developing for ‘Linux’ as that is sort of impossible due to its nature. Maybe they should just go one distro at a time. developing Chrome for Ubuntu, Fedora or OpenSuse would be doable I would think. Google could pick their favorite distro or the easiest distro for them to develop on. This just seems like the most common sense way to go about it to me.
Edited 2009-06-03 14:38 UTC
Actually, you are right, and that is often what companies do. All they have to do is pick one (perhaps Ubuntu of Fedora) and get it working on that distro. It is then up to the developers of the other distributions to get it working. Of course, this assumes an open-source model. If instead, Chrome is meant to be a closed-source product, they may as well let the wine folks keep doing their thing. It would not be worth their effort to port it to Linux. The good they get for “plays nice with Linux” would be offset by “thumbs nose at Free Software”.
No, an open source model isn’t needed. Just make it work on Fedora or whatever, and document what kind of dependencies a distro will have to fulfil to make the software work.
I’d be a little surprised if it was meant to be closed source, given the existence of SRWare Iron
http://www.srware.net/en/software_srware_iron.php
From reading the article it honestly sounds like a bit of a PITA on all operating systems to me.
It takes a load of code on Windows
On Linux, they can’t decide which route to go
On OS X, while a framework exists, they are flying blind on knowing which API calls actually work correctly within the framework.
The whole thing sounds like a headache to me on any OS.
Yeah, that’s what I got from it too.
Ideally, it’d be easy on Linux. The obvious candidates are AppArmor and SELinux. They’re both configuration-based, and an appropriate profile for each process would allow Chrome’s sandboxing to just work.
The problem is that neither are universally supported, but most modern distributions support one or the other. I don’t know why they don’t just develop and ship profiles for both, and let the OS apply whichever one it supports.
Everything else mentioned on that page involves abusing other features of the OS to provide sandboxing functionality, which is pretty much what they had to do on Windows as well.
For the Windows version, they didn’t seem to complain about this in the slightest – they just got on with it. They even seemed proud of it, and published details of all the torture they had to go through to make it work. Interesting reading, by the way.
So why all the complaints about every little problem they have on Mac / Linux? Can’t the guys developing the Mac / Linux versions just get on with solving the problems, like they guys who developed the Windows version did?
Sounds like the container APIs that are being added to the Linux kernel might also be useful for this.
Equally well the blog post and the wiki page seem to suggest that they’ve basically not chosen what approach to use on Linux, as opposed to them considering it a “mess”.
Sounds like seccomp could do the job and like it’s probably widely available; sounds like a reasonable situation to me.
There’s information here about the potential for improving seccomp for Chrome’s purposes and / or for alternative sandboxing mechanisms should they be more appropriate.
http://lwn.net/Articles/332974/
When a developper on the chrome browser came to give his talk (in Qc) If I recall correctly what he said, they only used how windows react when the program is started without any rights (no user), by default the program will have the rights of his user and therefor have none what so ever on the system … It was fairly easy as windows already provided a way to do sandboxing without having anything to add on top.
If one reads the http://code.google.com/p/chromium/wiki/LinuxSandboxing more closely, the charge that it is a ‘mess’ under Linux falls short.
The page is intended as an archive, or a discussion of the different ways sandboxing could be achieved on Linux. The page clearly states ‘Some of these are bad ideas, but included so that their flaws can be remembered for future discussion.’ And yes, some of the approaches listed are limited by which distros support them, but overall, the problem is not that there is a surfeit of ideas, but deciding which one of the multiple ways is best.
Based on what I read from the page, the last entry, seccomp seems the most promising approach, as it would provide an effective means for separating the untrusted parts of the renderer while still allowing it to perform the necessary system calls. It would work across platforms.
I also agree with previous posters that requiring that the user be root to install Chrome is not much of a limitation. We already need root privs to install most of our packages – why should Chrome be different?
sounds similiar to the approach of osx, but less flexible.
Google over the past couple of years has been known for hiring only the best of the best. Apparently, Jeremy was hired BEFORE that policy went into effect.
Sheesh….
Edited 2009-06-03 16:34 UTC
It is the distribution maintainers job to incorporate the program into the correct package type and repository. Can Google not simply pick a mechanism, say it’s a dependency and be done? I thought the modular design would allow such things similar to including WINE with the Linux build of Picasa and Google Earth.
Where exactly does he say or explain that it’s a mess? In the code? He sure doesn’t say it the linked blog post. All he says, as far as I can gather, is that there are different frameworks and that it is a challenge. Nowhere does he complain or wine about what a mess it is.
Putting words in people’s mouth isn’t nice.
The editor obviously wants to put down Linux as being “a mess”.
Vista has specific facilities for the allowing low privilege browsers, which are sandboxed in that they can’t alter any files outside of the browser’s own folders (like cache, history), unless the user explicitly performs an action (like saving a web page) that requires going outside the sandbox, in which case the operation goes through a broker that is very small, and therefore very well debugged and unlikely to have holes. IE 7 and later versions of IE take advantage of this functionality.
Hmmm… Now that I think of it, maybe they’re talking about XP when they say that sandboxing on Windows is “complicated”.
I’m not familiar with seccmp, but if it’s universal and stable, it seems — perhaps with a small extension — to be an elegant solution to this problem.
The extension (if it cannot be done currently) would be to allow the signal sent to be catchable. Then all that should be needed is a signal handler that would take the prohibited system calls and map them to an RPC call to a server process which would filter the requests and service those which are acceptable. The server process could be multithreaded child process of the browser, and would have general permission.
This seems to me a cleaner and more elegant way to handle this than to try to build a “one size fits all” sandbox mechanism.
From the wiki:
And if you read all the comments below, you actually see, SELinux is supported on all the major distris RH, SUSE, Debian/Ubuntu and they’ve also been told that SELinux should be the perfect solution and been offered help from Dan Walsh (RH) who has done work on sandboxing before. So their statement about SELinux seems to be wrong and they could’ve easily cleared it up. Also where in the article do they say Linux sandboxing is a mess?
J