lkml.org 
[lkml]   [2012]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH PLACEHOLDER 1/3] fs/exec: "always_unprivileged" patch
    On Sun, Jan 15, 2012 at 6:41 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
    > On 1/15/2012 2:07 PM, Andrew Lutomirski wrote:
    >>
    >> On Sun, Jan 15, 2012 at 1:32 PM, Casey Schaufler<casey@schaufler-ca.com>
    >>
    >> If you don't trust that binary, then why are you execing it with saved
    >> uid != euid in the first place?
    >
    >
    > If I could trust the binary I wouldn't need your no_new_privs
    > semantics in the first place. Do you have any idea how big the
    > chrome browser binary is? You can't link it on a 32bit machine
    > it uses so much address space. On top of that, most modern
    > applications are compositions of scripts and interpreters built
    > on top of multiple layers of middleware. Of course I don't trust
    > the binary!
    >

    I'm not sure we're really talking about the same thing here. I agree
    that, if you are trying to sandbox untrusted code, then you probably
    don't want that code messing with setuid, capset, or any other
    privilege-changing operation.

    no_new_privs is not intended to be that sandbox. It is, by itself, at
    best a small reduction in attack surface.

    The attack surface accessible to a program (e.g. chrome) that you run
    normally is huge. There is filesystem access, ptrace, unix sockets,
    any available privileges, setuid programs, /proc, etc. LSMs try to
    characterize and control that whole attack surface. seccomp mode 2
    allows a whitelisting approach in which everything is denied except
    that which is explicitly allowed (and I think that's a much better
    approach to sandboxing things). The problem is that seccomp mode 2,
    as well as anything else that changes the behavior of syscalls in a
    nonstandard way (chroot, unshare, etc), can cause existing code to
    malfunction. That's how the sendmail bug came to be -- dropping a
    privilege made sendmail do the wrong thing. This type of attack works
    by changing something that persists across a *gain* of privilege and
    then attacking the code that gains that privilege. If new things like
    seccomp mode 2 require no_new_privs, then that entire class of attacks
    is prevented.

    In answer to your specific example, if you are trying to sandbox
    chrome or anything else and you forget to drop your privileged saved
    uid, I really don't think it's no_new_privs's job to rescue you.

    --Andy


    \
     
     \ /
      Last update: 2012-01-16 08:49    [W:3.060 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site