[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
    Quoting Kurt Garloff (
    > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-19 14:13    [W:0.024 / U:2.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site