lkml.org 
[lkml]   [2007]   [Jun]   [21]   [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
    On 2007-06-21T20:33:11, Pavel Machek <pavel@ucw.cz> wrote:

    > inconvenient, yes, insecure, no.

    Well, only if you use the most restrictive permissions. And then you'll
    suddenly hit failure cases which you didn't expect to, which can
    possibly cause another exploit to become visible.

    > I believe AA breaks POSIX, already. rename() is not expected to change
    > permissions on target, nor is link link. And yes, both of these make
    > AA insecure.

    AA is supposed to allow valid access patterns, so for non-buggy apps +
    policies, the rename will be fine and does not change the (observed)
    permissions.

    The time window in the rename+relabel approach however introduces a slot
    where permissions are not consistent. This is a different case.

    > > You _must_ be kidding. The cure is worse than the problem.
    > Possibly.

    Yes.

    > > If that is the only way to implement AA on top of SELinux - and so far,
    > > noone has made a better suggestion - I'm convinced that AA has technical
    > > merit: it does something the on-disk label based approach cannot handle,
    > > and for which there is demand.
    > What demand? SELinux is superior to AA, and there was very little
    > demand for AA. Compare demand for reiser4 or suspend2 with demand for
    > AA.

    SELinux is superior to AA for a certain scenario of use cases; as we can
    see here, it is not superior to AA for _all_ use cases.

    > > The code has improved, and continues to improve, to meet all the coding
    > > style feedback except the bits which are essential to AA's function
    > Which are exactly the bits Christoph Hellwig and Al Viro
    > vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
    > . I believe it takes more than "2 users want it" to overcome veto of
    > VFS maintainer.

    A veto is not a technical argument. All technical arguments (except for
    "path name is ugly, yuk yuk!") have been addressed, have they not?



    Regards,
    Lars

    --
    Teamlead Kernel, SuSE Labs, Research and Development
    SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
    "Experience is the name everyone gives to their mistakes." -- Oscar Wilde

    -
    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-21 21:27    [W:0.022 / U:0.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site