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

Kurt Garloff
2006-04-19T06:50:16Z

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

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

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.
(The submission to LKML should happen RSN, the committment has
been there since a long time!)

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.

Best,
--
Kurt Garloff, Head Architect Linux R&D, Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]