Weekly Edition
Return to the Security page
| |||||||||||||
Walsh: Google Chrome Policy
SELinux hacker Dan Walsh looks at creating policies for the Google Chrome browser on his weblog. His posting is a detailed look at creating SELinux policy for Chrome/Chromium, and, in particular, the Chromium sandbox. "When I write new policy now, I default to permissive domains to make sure I don't blow up the user environment. I usually wait for the next version of the OS to turn permissive domains to enforcing domains. This means I will probably leave chrome_sandbox_t as a permissive domain for all of F12 and turn it enforcing in F13. This allows me to gather lots of AVC's and not force the user to disable SELinux [or] not use chrome. And hopefully allows me to write better policy. You can use the seinfo --permissive command to list all the permissive domains on your system."
(Log in to post comments)
Walsh: Google Chrome Policy Posted Oct 12, 2009 17:14 UTC (Mon) by rriggs (subscriber, #11598) [Link] "You can use the seinfo --permissive command to list all the permissive domains on your system." No, I can't. $ seinfo --permissive
seinfo: unrecognized option '--permissive'
Usage: seinfo [OPTIONS] [EXPRESSION] [POLICY ...]
Try seinfo --help for more help.
This is on Fedora 11.
Walsh: Google Chrome Policy Posted Oct 12, 2009 18:34 UTC (Mon) by michich (subscriber, #17902) [Link]
It seems to be a new option in F12.
Which repository? Posted Oct 12, 2009 17:27 UTC (Mon) by nandersson (guest, #54787) [Link]
Which source/repostory is the best for Chrome/Chromium to add in Fedora? Could someone please post the commands to set it up?
Which repository? Posted Oct 12, 2009 18:45 UTC (Mon) by michich (subscriber, #17902) [Link] Try Tom 'Spot' Callaway's repository. Add achromium.repo file into /etc/yum.repos.d with these contents:
[chromium] name=Chromium Test Packages baseurl=http://spot.fedorapeople.org/chromium/F12/ enabled=1 gpgcheck=0(Change the 'F12' to what Fedora release you actually have.)
Walsh: Google Chrome Policy Posted Oct 12, 2009 17:39 UTC (Mon) by qg6te2 (guest, #52587) [Link] This allows me to gather lots of AVC's and not force the user to disable SELinux [or] not use chrome.Here is one person hoping that the above doesn't imply "I'm going to look at a bazillion bug reports before fixing things". The above quote almost smells like Fedora's good ol' days where half-baked software was forced on unsuspecting users, in the name of "advancing open source software" (read: "let others test this before putting it into the next version of RHEL"). All because the author(s) couldn't be bothered to do a serious round of testing himself/herself beforehand.
Walsh: Google Chrome Policy Posted Oct 12, 2009 18:40 UTC (Mon) by michich (subscriber, #17902) [Link] Here is one person hoping that the above doesn't imply "I'm going to look at a bazillion bug reports before fixing things". Of course it does not. I am surprised you were able to misinterpret it this way. In my experience, Dan reacts quickly to all SELinux-related bugreports in Bugzilla.
Walsh: Google Chrome Policy Posted Oct 12, 2009 19:45 UTC (Mon) by imitev (subscriber, #60045) [Link]
If you ever wrote a selinux policy for a non-trivial application, you'd know that it's *very* hard to get it right the first time, even with a lot of testing. Don't forget that people sometimes use your software in a way you didn't think of; in that specific case gathering AVCs in permissive mode is the way to go.
And BTW, that won't (shouldn't) break chrome/chromium and in the worst case you'll just have to disable selinux, so that's not quite the same as shipping "half-baked" software.
Walsh: Google Chrome Policy Posted Oct 13, 2009 11:59 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Absolutely. SELinux policies are insane.
AppArmor and TOMOYO are _SO_ much better. You can create a usable AppArmor policy in a matter of minutes.
And it doesn't require @#)($@#)($*)(@*# relabeling, extended attributes, works on FAT volumes, etc.
In short, SELinux should be ripped out and replaced with something _sane_.
Walsh: Google Chrome Policy Posted Oct 14, 2009 15:56 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Can you point me to a list of exploits that AppArmor policy has successfully mitigated?
Tresys has a list of SELinux mitigations, you can see it on the right hand side of this page:
Is there anything publicly archived that tracks AppArmor's...effectiveness?
-jef"easy and effective are not synonyms."spaleta
Walsh: Google Chrome Policy Posted Oct 14, 2009 19:32 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
I don't think there are people that keep track of mitigated vulnerabilities.
Mainly because AppArmor has almost no active developers.
SELinux and AppArmor Posted Oct 14, 2009 17:33 UTC (Wed) by rfunk (subscriber, #4054) [Link]
AppArmor is easier, but fatally flawed. It relies on file paths, but on
Unix/Linux filesystems different paths may refer to the same file.
SELinux and AppArmor Posted Oct 14, 2009 19:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
So? AppArmor controls creation of hardlinks, so there's no problem here.
One can say that SELinux dependency on labels which is fatally flawed, since FAT and removable media can have inconsistent labels.
SELinux and AppArmor Posted Oct 15, 2009 2:25 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
SELinux vs AppArmor debate is more involved than "path-based" or not and hard links don't really solve that problem entirely
http://securityblog.org/brindle/2006/04/19/security-anti-...
FAT and removable media don't have "inconsistent labels". They are not labelled at all and SELinux policy can unlabelled filesystems via other methods.
SELinux and AppArmor Posted Oct 15, 2009 12:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
First, the insufficiency of path-based approach is a FUD. It works just fine.
Of course, label-based approach of SELinux is more powerful. But what good do these features do if I need to spend days just to write a basic policy?
AppArmor is 'good enough' for most purposes (like, confining a daemon to read only certain directories). For example, this very FireFox is confined to read and write only several directories by AppArmor on my system.
And its policy is clear enough so even a newbie administrator can understand it.
SELinux and AppArmor Posted Oct 16, 2009 15:50 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
You claim that the argument from a security expert is FUD even though several other experts agree with it. Alright, prove your counter argument. Write a quick AppArmor policy that covers Chrome comprehensively. If it is really as easy as you claim, then it shouldn't any problem, right? Let's deal with reality. SELinux policies are complex because security is complex and if the alternative was so easy, why doesn't it have any developers like you admit yourself?
SELinux and AppArmor Posted Oct 16, 2009 18:22 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
it all depends what experts you decide are qualified to give opinions.
there are many security people out there who consider SELinux far too complicated for normal use, and who see benefits in AppArmor.
SELinux and AppArmor Posted Oct 16, 2009 20:08 UTC (Fri) by nix (subscriber, #2304) [Link]
I suppose it doesn't have any developers because SuSE fired all its
developers and its main developer went to work for Microsoft.
Oh, also because the SELinux people fought tooth and nail to keep it out
Some prophecies are self-fulfilling.
SELinux and AppArmor Posted Oct 16, 2009 20:20 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
canonical has people working on AppArmor, so it's not quite 'no developers' any more.
but the tooth and nail fight to keep it out of the kernel would do a lot to discourage development.
SELinux and AppArmor Posted Oct 17, 2009 0:48 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
That's hilariously wrong. James Morris, SELinux developer at Red Hat is the security sub-system maintainer in the upstream kernel and he has not only accepted alternatives to SELinux and merged them, he also regularly blogs about progress and even expressed hope that AppArmor would get merged
SELinux and AppArmor Posted Oct 17, 2009 2:18 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
I will admit that I do not remember James objecting, but he also hasn't been saying anything to disagree with Stephen Smalley (the other SELinux maintainer) who has been _very_ vocal in his opposition.
SELinux and AppArmor Posted Oct 17, 2009 3:04 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
Stephen Smalley is one of the many SELinux developers but his objections were pretty specific. Some of them were even addressed in subsequent versions of the patch set. I don't see any reasons to object to valid technical criticism.
SELinux and AppArmor Posted Oct 17, 2009 3:19 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
I don't object to valid technical criticism.
however when that becomes 'it doesn't handle this case that SELinux does, so it must be worthless', that stops being valid technical criticism, and the objections have frequently gotten to that stage (and, no, my memory is not good enough to remember exactly who made which objections)
SELinux and AppArmor Posted Oct 17, 2009 3:44 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
It seems you are badly paraphrasing comments elsewhere. If you point a specific link, it would be useful to know what was actually said. Some of the discussions involved the problem that the goals described the developers while submitting the patchset didn't match the patches.
It is ok for a security solution to address a specific subset of the problems while leaving others as outside the scope but the documentation should explicitly say so. If it doesn't then it makes it harder to merge those patches. Smack did a good job of describing the scope of the problem it was trying to address.
SELinux and AppArmor Posted Oct 16, 2009 21:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
AppArmor is not ideologically pure, that's why experts don't like it.
But it's _simple_. And it works.
I don't know what's inside the Chrome policy, but you can see the FireFox policy here:
SELinux and AppArmor Posted Oct 18, 2009 15:47 UTC (Sun) by kleptog (subscriber, #1183) [Link]
My one run in with AppArmor was getting a weird error message from tcpdump. Turns out it was forbidden from reading files outside of /home???
Disabling AppArmor solved the problem. SELinux hasn't got a monopoly on obscure error messages.
Walsh: Google Chrome Policy Posted Oct 15, 2009 18:52 UTC (Thu) by njs (guest, #40338) [Link]
> You can create a usable AppArmor policy in a matter of minutes.
I don't know enough to take an informed position in the SELinux debate, but... perhaps you don't either? Empirically, Ubuntu's Firefox AppArmor policy (new for Karmic) is still not up to snuff, and I'm pretty sure they've been working on it for more than a few minutes.
Walsh: Google Chrome Policy Posted Oct 27, 2009 14:01 UTC (Tue) by robbe (guest, #16131) [Link]
I'd be more interested in how Dan gets all the AVC warnings that his
permissive "beta" policy generates to fix any oversights. Does he rely on users filing bug reports for these (most won't see them, I guess, and everything will work anyway)? Does something phone home?
Walsh: Google Chrome Policy Posted Oct 27, 2009 15:57 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
setroubleshooter is a desktop software that is installed by default and will inform the end user in detail about any SELinux policy violations. In Fedora 12 beta onwards, it will also offer to file a bug report gathering all the information it needs to help debug the problem. That is one way to improve the policy.
Walsh: Google Chrome Policy Posted Oct 12, 2009 18:16 UTC (Mon) by mosfet (guest, #45339) [Link]
The path to redemption via grub: selinux=0
Always, always, use this on desktop systems. Beyond the selinux barrier dragons and weired error messages hide and wait for unsuspecting travelers. Now you may burn the heretic.
Walsh: Google Chrome Policy Posted Oct 12, 2009 20:09 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Burn, heretic!
No, really, SELinux has worked fine on my FC11 desktop system.
I had to look up some stuff to figure out how to allow SELinux and Samba to share a USB drive. However, it is kind of comforting to know that there is no way Samba is going to run around loose on my hard drives.
Walsh: Google Chrome Policy Posted Oct 13, 2009 5:45 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] I've used selinux on desktop fedora systems for years. There have been occasional glitches, but overall it's worked well, and by now the rough edges have been sanded away.
Walsh: Google Chrome Policy Posted Oct 14, 2009 9:21 UTC (Wed) by renox (subscriber, #23785) [Link]
>No, really, SELinux has worked fine on my FC11 desktop system.
Depends on your view of what is 'fine': if I understood correctly, the SELinux policy described prevents Chrome uploading files, which I bet quite a few users will find annoying!
Walsh: Google Chrome Policy Posted Oct 14, 2009 9:27 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Can you explain why the policy would prevent Chrome from upload files? Note that Chromium is not in the Fedora repository yet nor is the policy changes. So this is not applicable to Fedora 11 anyway. In Rawhide, I don't have a problem using Chromium.
Walsh: Google Chrome Policy Posted Oct 22, 2009 7:10 UTC (Thu) by renox (subscriber, #23785) [Link]
>Can you explain why the policy would prevent Chrome from upload files?
Because it's written in the conclusion of Dan Walsh's blog:
Maybe I'm misunderstanding it, I'm not a Chrome or SELinux expert..
Walsh: Google Chrome Policy Posted Oct 13, 2009 8:35 UTC (Tue) by lkundrak (subscriber, #43452) [Link]
Though I won't object that "weirded error messages" pop-out from-time-to-time on Fedora SELinux-enabled desktop, probably a more sane way to get rid of them would be to disable the sealert applet. Point is that you loose less and the "unsuspecting traveller" probably won't be able to fix them anyway.
For me, and I am rather demanding desktop user, SELinux didn't cause any trouble for years (well I can think of one with libvirt, but would a desktop user run that anyway?) and I am running with SELinux enabled and any denial notification disabled (though I look at denial every once in a while out of curiosity,).
|
|||||||||||||