lkml.org 
[lkml]   [2007]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: AppArmor FAQ
    From
    Date
    On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote:
    > Karl MacMillan <kmacmill@redhat.com> writes:
    >
    > > No - the real fix is to change the applications or to run under a policy
    > > that confines all applications. Most of the problems with resolv.conf,
    > > mtab, etc. stem from admin processes (e.g., editors or shell scripts)
    > > all running under the same unconfined domain.
    > >
    > > In some cases applications need modification as only the application has
    > > enough information to determine the correct label. Usually this means
    > > preserving labels from input files or separating the output into
    > > distinct directories so type transitions or label inheritance will work.
    > >
    > > restorecond is just a hack not a requirement or a sign that something is
    > > wrong with the model. That is why it is a userspace application and not
    > > integrated into the kernel mechanism.
    >
    > You nicely show one of the major disadvantages of the label model vs the path
    > model here: it requires modification of a lot of applications.

    It is true that many applications that already deal with mode bits need
    to become aware of labels, just as with ACLs, and that this makes it a
    bit harder and slower to roll out something that is label-based. But
    the right solution is rarely quick and easy, and a lot of work has
    already happened to integrate such support into userland.

    To look at it in a slightly different way, the AA emphasis on not
    modifying applications could be viewed as a limitation. Ultimately,
    users have security goals that go beyond just what the OS can directly
    enforce and at least some applications (notably things like X, D-BUS,
    PostgreSQL, etc) need to likewise support strong domain separation and
    controlled information flow through their own internal objects and
    operations. SELinux provides APIs and infrastructure for such
    applications, and has already done quite a bit of work in that space
    (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have
    no interest in going there (and would have to recant its emphasis on no
    application mods to do so). If you actually want to truly confine a
    desktop application, you can't limit yourself to the kernel. And the
    label model provides a unifying abstraction for dealing with all of
    these various objects, whereas the path/"natural abstraction" model has
    no unifying abstraction at all.

    --
    Stephen Smalley
    National Security Agency

    -
    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: 2007-04-19 19:51    [W:0.022 / U:30.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site