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

[Serge E. Hallyn]

Quoting Kurt Garloff (garloff@xxxxxxx):
> 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.

Ok, but...  why not?

Have you ever tried, at 4pm some afternoon, sitting in a room with some
paper and implementing the AA user interface on top of selinux?

An initial selinux policy can basically be:

print "type base_t;"

for c in object_class:
	"allow base_t base_t:c *;"

Then, if the AA user has a profile

	/bin/login {
		/etc/shadow r
	}

it creates domain login_t, entry type login_et assigned to /bin/login,
and shadow_t as a type which login_t can only read, but non-restricted
domains (i.e. base_t) can read and write.  It also makes read and write
macros for a bunch of selinux perms (i.e. ioctl, etc), the way the
Tresys CDE tool does.

I do want LSM to survive, and am reserving my judgement of AA until
I see the code, but if it really is just about ease of use, then
perhaps it should be a pure userspace thing?

OTOH perhaps there are reasons why you can't do this, and you can
explain why the above won't work.

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