Messages in this thread | | | Date | Wed, 19 Apr 2006 07:10:34 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks |
| |
Quoting Kurt Garloff (garloff@suse.de): > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |