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

[Stephen Smalley]

On Tue, 2006-04-25 at 11:11 -0700, Tony Jones wrote:
> 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.

Well, for what it is worth, I think that even in its first public
release in 2000, SELinux provided mediation of more operations than AA
does even now, even if we exclude network controls from consideration
(since SubDomain had some form of network controls in the past that were
temporarily dropped due to LSM limitations).

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

Yes, and this is the real point - it is a question of whether the
underlying model (if it can even be said to have one) generalizes.  With
SELinux, there is a well-defined model and it does generalize.  With AA,
I just don't see it.

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

I'd expect even more compatibility issues with AA-style access controls
than a jail/virtualization approach.

> 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.

I don't know whether existing jail/virtualization solutions can fully
replicate your functionality, but be careful not to confuse the actual
requirements with your current implementation and UI.  And you have to
weigh the gains in robustness against any potential loss in
expressiveness.

> 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.

Not sure what this would look like, but if your module still ends up
calling d_path or equivalent on every open, then it seems problematic
regardless.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/