The AppArmor debate begins [LWN.net]

The AppArmor debate begins

Posted Apr 27, 2006 3:47 UTC (Thu) by jamesm (guest, #2273)
Parent article: The AppArmor debate begins

I'd like to address the idea AppArmor is simple for "mere mortals" to administer in comparison with SELinux, which I believe to be a myth. In this thread, the creator of AppArmor admits that he doesn't understand the thunderbird policy on his own machine, and alarmingly, why it has setuid capability. Quote:

  > but as you posted an example profile with "capability setuid", I must
  > admit I am curious as to why an email client needs that.

  Well now that is a very good question, but it has nothing to do with
  AppArmor. The AppArmor learning mode just records the actions that the
  application performs. With or without AppArmor, the Thunderbird mail
  client is using cap_setuid. AppArmor gives you the opportunity to *deny*
  that capability, so you can try blocking it and find out. But for
  documentation on why Thunderbird needs it, you would have to look at
  mozilla.org not the AppArmor pages.

As they add more policy coverage for things like IPC and networking, it will only become more complicated, but without the strong security assurance features of SELinux. This also demonstrates the way the AppArmor tool encapsulates existing behavior, without any real design or understanding of the security implications of the policy being generated.

(Log in to post comments)

The AppArmor debate begins

Posted Apr 27, 2006 6:56 UTC (Thu) by nix (subscriber, #2304) [Link]

This is the *point* of the learning system. The idea is that you run your target app in learning mode while it is *not* being attacked (which basically runs it with everything banned, but with the system set to log, not deny failed operations, and then analyzes the logfile). The resulting policy will only allow the target app to do what it did while you were running it in learning mode, which may include... unexpected things.

If you want to know *why* those unexpected things are being done, you'll have to examine the app's source code: and oddly enough Crispin didn't want to do that for a monster like Thunderbird.

This is (yet another place) where *exactly* the same criticism can be made of SELinux, except that of course because it doesn't have a learning mode you'll have to do the log analysis yourself.

The AppArmor debate begins

Posted Apr 27, 2006 8:58 UTC (Thu) by james (subscriber, #1325) [Link]

audit2allow is a "learning mode" for SELinux -- it takes the audited failures and creates rules to allow them.

audit2allow: more details

Posted Apr 27, 2006 17:10 UTC (Thu) by bkoz (guest, #4027) [Link]

Thanks.

Huh. Interesting. This tool looks quite useful.

I found more details here:
http://www.samag.com/documents/s=9820/sam0508a/0508a.htm

Is there other documentation about this? (Targeted at non-studly sys admin types such as myself?)

audit2allow: more details

Posted Apr 27, 2006 19:36 UTC (Thu) by jamesm (guest, #2273) [Link]

Try the SELinux wiki: http://fedoraproject.org/wiki/SELinux Dan Walsh's blog: http://danwalsh.livejournal.com/ There's also a comprehensive book coming out, soon.

The AppArmor debate begins

Posted Apr 27, 2006 13:10 UTC (Thu) by jamesm (guest, #2273) [Link]

The exact same criticism cannot be made, as this is not the primary way that policy is developed under SELinux (it comes with the apps). You can use audit2allow, but I would not recommend it as anything but an adjunct to designing policy and then only if you understand what it's doing. (I know that it's mentioned in a lot of the online documentation -- possibly without enough caveats). I was discussing something similar to a learning mode for SELinux with another developer last year at OLS, and it can definitely be done, say, with per-process permissive mode. I don't think it's the right approach alone, but could be useful when used by a trained policy developer with some other features such as static analysis of the source code, peeking inside RPMs etc. There are tools now being developed for SELinux which operate at a higher level, with a wizard-like interface which allows security goals to be defined by the user, from which a security policy is generated.

The AppArmor debate begins

Posted May 1, 2006 16:04 UTC (Mon) by Method (guest, #26150) [Link]

Congratulations, you identified the precise problem with this type of system. For comparison the SELinux Thunderbird policy *does not* include this capability, proof positive that iterative active policy development will yeild higher quality policies than 'status quo encapsulation'. If thunderbird functions properly without this permission then it should not be there.

See http://securityblog.org/brindle/2006/03/25/security-anti-...
for more commentary on that sort of policy development.

The point mentioned in your post about using learning mode while the app is not being attacked is talked about in the above article but I'll refute it here incase people don't want to read it. Once your system is active (eg., thunderbird is fetching mail from your server) it is no longer in a known good state, you have no idea if it is being attacked or otherwise compromised. The fact that blindly writing policies in this manner can actually create channels for the attackers to operate on after the policy is active is disturbing and IMHO a very compelling argument against this type of behavior.

The AppArmor debate begins

Posted Apr 27, 2006 10:19 UTC (Thu) by jschrod (subscriber, #1646) [Link]

It would help to get your critique in context to know if you're an independent observer or if you're working on SElinux.

Your past comments about SElinux, in previous stories on lwn.net, showed that you are very familiar with that topic. You brushed away several times the criticue of SElinux's complexity. So, how involved are you in SELinux? (That's not to say that your critic is invalid. It is about the expectation if you will represent both sides or one side of the discussion, with your arguments.)

For the record, I'm involved in neither SELinux nor AppArmor, but try to follow the developments.

Joachim

The AppArmor debate begins

Posted Apr 27, 2006 12:58 UTC (Thu) by jamesm (guest, #2273) [Link]

I'm James Morris and a long time SELiunx developer (I thought that was well known).

The AppArmor debate begins

Posted Apr 27, 2006 18:24 UTC (Thu) by wcooley (guest, #1233) [Link]

It's a little bit disingeneous to call Crispin the "creator" of AppArmor. Crispin writes papers, not code (I've heard him say as much myself when I worked at WireX [the company's name before Immunix and the Novell purchase]). He's a PhD theorist, not a programmer, and he tends to not get mired in details--so it would come as no surprise that he doesn't understand the Thunderbird profile on his machine.

Yes, he led the development of the higher-level aspects of AppArmor and wrote papers and secured funding, but most of the actual implementation details were handled by Greg Kroah-Hartman, Chris Wright, Steve Beattie, Seth Arnold and Jesse Michael (maybe others now too).

The AppArmor debate begins

Posted Apr 27, 2006 19:46 UTC (Thu) by jamesm (guest, #2273) [Link]

Well, that's never been my impression, and doesn't seem to match the way he describes himself.

"developed the StackGuard C compiler buffer overflow defensev and the AppArmor application security system. He lead the effort to build the LSM (Linux Security Modules) feature into Linux 2.6,"

http://www.linuxworldexpo.com/live/12/events/12BOS06A/con...

"Architect of the AppArmor Project"

http://www.fosdem.org/index/speakers/speakers_cowan

"Crispin Cowan is the chief architect of SubDomain, and CTO at WireX Communications."

http://www.seifried.org/security/products/20010912-immuni...