[lkml]   [2010]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Preview of changes to the Security susbystem for 2.6.36
    Hi Christoph,

    On Mon, Aug 02, 2010 at 08:24:21AM -0400, Christoph Hellwig wrote:
    > As mentioned a few times during the past discussion moving broken
    > code into a LSM doesn't magically fix it. In fact YAMA is not any kind
    > of (semi-)coherent security policy like Selinux, smack or similar but
    > just a random set of hacks that you didn't get past the subsystem
    > maintainers.

    I would love to have these "hacks" in the subsystem directly. But no one
    has stepped forward to decode Al Viro's hints.

    I'm getting pretty tired of moving this logic back and forth between the
    subsystems and an LSM. You yourself told me to put these things in an
    LSM[1], and yet now you're saying I shouldn't.

    > Al gave you some very clear advice how a the sticky check should be

    This is patently false. "Very clear advice" would have included actionable
    instructions. He (and everyone else) has ignored my requests for
    clarification[2]. If you see how the check should be implemented, please
    send a patch demonstrating how. I would greatly prefer having these
    protections in the VFS itself.

    > done for symlinks (if we need it at all, which I tend to disagree with),

    I can see how one might disagree with it, but anyone who handles day-to-day
    security threats understands this protection to be a clear and obvious
    solution for the past decade.

    > and the ptrace check completely breaks crash handlers that we have
    > in all kinds of applications. If you can get it into the main ptrace

    I've seen two so far. Both are addressed with a one line fix. And I would
    stress that no other existing subsystem in the kernel can provide the same
    level of control that my ptrace exception logic provides. SELinux cannot do

    > code past Roland and Oleg that's fine, but just pushing it out into
    > a tree that has percieved easier merge criteria doesn't work.

    This advice is precisely counter to prior advise. It would seem that no one
    knows how to handle these patches. I find it very simple; either:
    - let me put them in an LSM that people can choose to enable
    - help me get the patches into shape for the subsystems directly

    Since the latter has been repeatedly denied, the former was suggested to
    me, which I implemented. The option "give up" is not available to me.
    Perhaps there is another option I could choose from so I can get these
    protections into the mainline kernel?



    Kees Cook
    Ubuntu Security Team

     \ /
      Last update: 2010-08-02 19:01    [W:0.022 / U:16.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site