lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
    * Chris Mason (chris.mason@oracle.com) wrote:
    > I'm sure people there will have a different versions of events. The
    > one part that was discussed was if pathname based security was
    > useful, and a number of the people in the room (outside of
    > novell) said it was. Now, it could be that nobody wanted to argue
    > anymore, since most opinions had come out on one list or another by
    > then.

    Indeed. The trouble is that's too high level compared with the actual
    implementation details. AA is stalled because it has failed to get
    VFS support for it's model. I don't see a nice way out unless it
    changes it's notion of policy language (globbing is the tough one)
    or gets traction to pass dentry/vfsmount all the way down. Paths are
    completely relevant for security, esp. when considering the parent dir
    and the leaf (as in forward lookup case). Retroactively creating the
    full path is at the minimum ugly, and in the worst case can be insecure
    (yes AA has taken many measures to mitigate that insecurity).

    > But as someone who doesn't use either SElinux or AA, I really hope
    > we can get past the part of the debate where:
    >
    > while(1)
    > AA) we think we're making users happy with pathname security
    > SELINUX) pathname security sucks

    Yes. Please. Both parties are miserably failing the sanity test.
    Doing the same thing over and over and expecting different results.

    AA folks: deal with the VFS issues that your patchset have in a palatable
    way (which does not include passing NULL when it's inconvenient to
    do otherwise). You've already missed an opportunity with Christoph's
    suggestions for changes in NFS. I know you've considered many alternative
    approaches and consistently hit dead ends. But please note, if you
    have coded yourself into a corner because of your policy language,
    that's your issue to solve, not ours.

    SELinux folks: do something useful rather than quibbling over the TCSEC
    definition of MAC and AA's poor taste in marketing literature. Here's
    some suggestions:

    1) Make SELinux usable (it's *still* the number one complaint). While
    this is a bit of a cheap shot, it really is one of the core reasons AA
    advocates exist.
    2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
    3) Write an effective exploit against AA that demonstrates the fundamental
    weakness of the model (better make sure it's not also an issue for
    targetted policy).

    thanks,
    -chris
    -
    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-06-23 02:15    [W:2.323 / U:0.652 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site