Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Tony Jones <tonyj@suse.de>]

On Tue, Apr 25, 2006 at 11:01:05AM -0400, Stephen Smalley wrote:
> AppArmor doesn't control IPC (which has been noted previously), and it
> isn't clear how one generalizes its path-based scheme to handle all
> kinds of kernel operations.  

Maybe it will have to grow to handle more operations.  SELinux has grown in
terms of it's features and what it protects.  Clearly you have benefitted
from being open sourced for an extended period of time.  I'm sure you'd love
to debate the history of this :) but there doesn't seem much productive point.

But I agree, it isn't clear how the AA scheme applies to all forms of kernel
operations.

> mechanism.  Which brings up an interesting topic of its own:  If you
> want the AppArmor model, then why not just use existing jail-like or
> virtualization mechanisms?  IIUC, Vservers and OpenVZ are already far

Because it presumes that the application can easily be configured to function
in a jail.

> more complete in their coverage than AppArmor and leverage existing
> kernel mechanisms like namespaces that at least have well-defined
> semantics.  I expect that I could achieve a much higher degree of
> confidence in such a mechanism than in AppArmor.  Why can't AppArmor
> just become a userspace tool for configuring namespaces and setting up
> the environment in which the application runs?

How do you propose handling in a namespace the ability to create new files.
I can see how you could perhaps create a fixed scratch area inside the 
namespace, but what if the application wants to create /var/lib/foo/bar.xxx

You have obviously read the AppArmor docs. How would you propose to handle 
(approximately) the expressiveness of AppArmor policy. Also what does 
/srv/www/htdocs/**.html equate to when this namespace is configured for the 
application. Does the task need to be torn down and restarted if you populate 
more files?

The issue of namespaces being a better way of doing all of this has been raised
a couple of times.  It is an interesting idea for sure. I responded to one of
the posts with the same (above) questions but havn't yet seen a reply.

Other LSM hooks are an option also.  Clearly if we can add new hooks at more
optimal locations where pathnames are available it would be preferable to
the current scheme and (qualifier: the devil is in the details) probably 
preferable to trying to pass vfsmounts fully into the existing hooks.

Tony