Re: AppArmor FAQ

[daw@cs.berkeley.edu (David Wagner)]

Crispin Cowan wrote:
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile?

James Morris  wrote:
> [...] you can change the behavior of the application and then bypass 
> policy entirely by utilizing any mechanism other than direct filesystem 
> access: IPC, shared memory, Unix domain sockets, local IP networking, 
> remote networking etc.
[...]
> Just look at their code and their own description of AppArmor.

My gosh, you're right.  What the heck?  With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?

And why isn't this documented clearly, with the implications fully
explained?

I would like to hear the AppArmor developers defend this design decision.
When we developed Janus, over 10 years ago, we defended against these
attack avenues and protected everything -- not just the filesystem.
Systrace does the same, as does Plash.  So does Consh, and MapBox, and
Ostia, to name a few other examples from the research world.  This is
standard stuff that is well-documented in the literature, and it seems to
me it is necessary before you can claim to have a useful jail.  What am
I missing?


P.S. I think the criticisms that "AppArmor is pathname-based" or
"AppArmor doesn't do everything SELinux does" or "AppArmor doesn't do
information flow control" are weak.  But the criticism that "AppArmor
leaves security holes that can be used to escape the jail" seems like
a serious criticism to me.  Perhaps a change of focus is in order.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/