Re: [PATCH PLACEHOLDER 1/3] fs/exec: "always_unprivileged" patch

[Andrew Lutomirski]

On Sun, Jan 15, 2012 at 6:41 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 1/15/2012 2:07 PM, Andrew Lutomirski wrote:
>>
>> On Sun, Jan 15, 2012 at 1:32 PM, Casey Schaufler<casey@xxxxxxxxxxxxxxxx>
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/