| |||||||||||||
Walsh: Google Chrome PolicyWalsh: Google Chrome PolicyPosted Oct 12, 2009 17:39 UTC (Mon) by qg6te2 (guest, #52587)Parent article: Walsh: Google Chrome Policy 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.
(Log in to post comments)
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.
|
|||||||||||||