Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[Stephen Smalley <sds@tycho.nsa.gov>]

On Tue, 2006-04-18 at 23:38 +0200, Kurt Garloff wrote:
> Hi,
> 
> On Tue, Apr 18, 2006 at 12:58:19PM +0100, Christoph Hellwig wrote:
> > It's doing access control on pathnames, which can't work in unix enviroments.
> > It's following the default permit behaviour which causes pain in anything
> > security-related (compare [1]).
> 
> Pathnames are problematic, no doubt.
> So AppArmor does currently do some less-than-nice things to get around
> this.
> On the other side, pathnames is what the admins see and use, so it is
> the right abstraction for the sysadmin, if you want to make a higher
> level of security available to people without the need to get them
> a large amount of extra training.
> So that gap needs to be bridged somehow.

The gap should be bridged in userspace.  Not by having the kernel rely
on pathnames.

> Maybe there are better ways compared to what AA does currently, and
> constructive suggestions are very welcome!
> 
> And no, just claiming that AA is useless or crap is not constructive
> AFAICT. And saying that is should be better done as part of SElinux
> is not either.
> 
> The goals are quite different. SElinux is a solution that wants to
> implement policies that cover lots of things. It's accordingly powerful
> and complex.

Sorry, what precisely does AppArmor want to do?  SELinux wants to
provide a mechanism that can support higher level confidentiality and
integrity goals with _confidence_ and can support application security
requirements as well (recognizing that security doesn't end with the
OS).

> AppArmor is easy. Everyone with a little background in Un*x can
> understand what it does and how it needs to be configured.
> Eventually, most sysadmins of the world can configure it correctly
> and thus make their systems more secure.

Userspace, userspace, userspace.  That is where ease-of-use is handled.
Making their systems more secure is open to debate.  And remember that
if ease-of-use is your sole or primary criteria, then anyone can always
beat AppArmor at that game.

> I don't want to judge, but I think the approaches and goals are 
> different enough to grant both (and evetually others) the right 
> to live.
> 
> Actually, I'm a bit worried about the discussion.
> When I chose Linux, it was about the freedom of choice.
> And we have a nice abstraction (LSM) that allows this freedom. At
> a small price. It's not pleasant to see that some people want to move
> away from that.

I've seen no shortage of times on linux-fsdevel and linux-kernel where a
kernel developer has explained to someone that trying to rely on
pathnames is broken.  Why should AppArmor be exempted from the same
criteria?  And even if we assume that pathnames are a sound basis, it is
very clear from the code (last I looked) that LSM is not a good fit for
what AppArmor is trying to do, so why should AppArmor be using LSM?
  
-- 
Stephen Smalley
National Security Agency

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