lkml.org 
[lkml]   [2006]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC][PATCH 0/11] security: AppArmor - Overview
    On Friday April 21, sds@tycho.nsa.gov wrote:
    > On Fri, 2006-04-21 at 10:30 -0700, Chris Wright wrote:
    > > * Stephen Smalley (sds@tycho.nsa.gov) wrote:
    > > > Difficult to evaluate, when the answer whenever a flaw is pointed out is
    > > > "that's not in our threat model." Easy enough to have a protection
    > > > model match the threat model when the threat model is highly limited
    > > > (and never really documented anywhere, particularly in a way that might
    > > > warn its users of its limitations).
    > >
    > > I know, there's two questions. Whether the protection model is valid,
    > > and whether the threat model is worth considering. So far, I've not
    > > seen anything that's compelling enough to show AppArmor fundamentally
    > > broken. Ugly and inefficient, yes...broken, not yet.
    >
    > Access control of any form requires unambiguous identification of
    > subjects and objects in the system. Paths don't achieve such
    > identification. Is that broken enough? If not, what is? What
    > qualifies as broken?

    I have to disagree with this. Paths *do* achieve unambiguous
    identification of something. That something is ..... the path.

    Think about the name of this system for a minute. "AppArmor".
    i.e. it is Armour for an Application. It protects the application.
    It doesn't (as far as I can tell: I'm not an expert and don't work on
    this thing) claim to protect files. It protects applications.

    It protects them from doing the wrong thing - from doing something
    they weren't designed to do. i.e. it protects them from being
    subverted by exploiting a bug.

    A large part of the behaviour of an application is the path names that
    it uses and what it does with them. If an application started doing
    unexpected things with unexpected paths (e.g. exec("/bin/sh") or
    open("/etc/shadow",O_RDONLY)) then this is a sure sign that it has
    been subverted and that AppArmor need to protect it, from itself.

    Obviously the protection will not be complete. The profiles describe
    what the application is expected to do, and to some extent, this
    description will be in general terms. It might identify files that
    can be written to, but not what will be written to them. etc.

    While the protection against subversion cannot be complete, it can be
    sufficient to dramatically reduce the chances of privilege
    escalation. There are lots of wrong things you can get an
    application to do once you find an exploitable bug. Many of these
    will lead to a crash. AppArmor will not try to protect against these
    (I suspect). There are substantially fewer that lead to privilege
    escalation. AppArmor focusses its effort in terms of profile design
    on exactly these sorts of unplanned behaviours.

    So I think you still haven't given convincing evidence that AppArmor
    is broken by design.

    NeilBrown
    -
    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-24 06:22    [W:3.930 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site