Weekly Edition
Return to the Kernel pageRecent Features
| |||||||||||||
Quote of the week
SELinux orders a beer object
-- Alan CoxAppArmor order a /beer Hilary says "You are both under 21 you can't" SELinux orders a shandy object AppArmor orders a /shandy
SELinux is refused because the shandy mixer opened a beer object and
shandy inherited beer typing (Log in to post comments)
Quote of the week Posted Jul 5, 2007 15:32 UTC (Thu) by mheily (guest, #27123) [Link] This is standard pro-SELinux nonsense. Under a normal AppArmor (or Systrace) policy, the default action is to deny all file accesses that are not specifically permitted. Thus, unless the policy was specifically written to allow access to '/shandy', the requested operation would be denied. For some reason, some people want to believe that simple path-based security is worthless and we should all adopt complicated object-based labeling and role based security. No thanks.
Quote of the week Posted Jul 5, 2007 15:49 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] AppArmor gives a homeless guy (over 21, therefore able to access /beer) 5 bucks to make a hard link from /beer to /shandy. AppArmor gets drunk, SELinux stays sober.
Quote of the week Posted Jul 5, 2007 16:20 UTC (Thu) by mheily (guest, #27123) [Link] Wrong. Let's say the application 'teenager' runs with the following AppArmor policy:
ALLOW /grape_juice
It doesn't matter how many hardlinks to /beer you make; as long as /grape_juice is owned by root and cannot be modified by the user, the only pathname that the 'teenager' application can access is '/grape_juice'.
Meanwhile, your SELinux system will fail randomly with obtuse log messages like:
Dec 10 13:56:28 server kernel: audit(1160762188.535:1884): avc: denied { name_connect } for pid=4437 comm="test.pl" dest=80 \
Which makes you so frustrated and clueless that you turn SELinux off, or put it into non-enforcing mode.
Disabled SELinux gets drunk on /beer.
Quote of the week Posted Jul 5, 2007 23:27 UTC (Thu) by smoogen (subscriber, #97) [Link] And both probably fall down if process SpeakEasy downloaded from Foobar is run in an unrestricted mode because Mom and Dad just wanted it to work. SpeakEasy runs as root and the kid just turns off security until he can get beer.
Remember everyone, security is hard... let's go shopping.
Quote of the week Posted Jul 6, 2007 14:09 UTC (Fri) by tialaramex (subscriber, #21167) [Link] Is that an AppArmor policy? The documentation seems to suggest that policies don't look like that at all. Any realistic policy is going to be full of wildcards, whereupon the previous poster's point comes back into play, the security of the system doesn't really depend on not being able to get things that are named "beer" in the filesystem but on not being able to get at things which /are/ alchoholic beverages.
Anyway, the behaviour from AppArmor developers reminds me too much of the people who show up every so often to demand that yield() should magically figure out that there's no work to be done for a while and sleep. If you don't understand what you're doing then you're going to screw up, and screaming at the kernel developers about it may make you /feel/ better but to everyone else it just makes you look /stupid/. At least the people abusing yield() are stuck in userspace where they can only waste CPU time.
The SELinux system you had problems with in December is complaining that a perl script was forbidden to use HTTP (or at least, something on an HTTP port). If you wrote it, and are sure that it's safe, give it an unrestricted context. If a Black Hat wrote it, and has somehow run it on your machine, it's probably trying (and thanks to SELinux, failing) to post forum spam. There are tools that could have told you that if you have some specific objection to learning to read SELinux advisories yourself.
Quote of the week Posted Jul 6, 2007 14:56 UTC (Fri) by mheily (guest, #27123) [Link]
The policy I used was for example purposes only to show how a path-based system works. I have used Systrace (systrace.org) in my own projects which is functionally similar to AppArmor. I am not familiar with AppArmor's syntax, but the basic ideas are the same.
Your concern about the use of wildcards is unfounded. For example, lets say you wanted to restrict the Gimp to only accessing files under /usr/share/pixmaps. The policy might look something like:
ALLOW /usr/share/pixmaps/*
As long as the user doesn't have permission to write to any files in the /usr/share/pixmaps directory, there is no reason to be worried about the wildcard.
The only time you start running into trouble is when you try to write a policy that restricts the user from accessing their own files, files that they have created and have ownership over. In that instance, the SELinux system is better because you can set fine-grained access controls on what the *user* does that is independent of which files they are accessing. For example, you can restrict which TCP ports the user is allowed to connect to.
The alleged superiority of SELinux over AppArmor reminds me of the debate over microkernels versus monolithic kernels. In theory, the microkernel is more flexible and powerful, but in practice it adds more complexity than is needed. The monolithic kernel is simpler and gets the job done "right now" with a minimum of fuss. The microkernel architecture, like SELinux, is a grand idea that needs more time and effort to reach it's full potential.
Alan Cox's comments were part of an effort to reject the inclusion of AppArmor in the stock Linux kernel. Some people feel that SELinux is so vastly superior to AppArmor that there is no point having both systems as an option. They continue to use bogus arguments against path-based systems to make it seem like AppArmor offers *no* added protection.
I think both systems have their merits and should be made part of the official Linux kernel (as long as the AppArmor code is of sufficient quality). Let the users decide which approach is better for them.
|
|||||||||||||