lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

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