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

[Casey Schaufler]

On 1/15/2012 11:45 PM, Andrew Lutomirski wrote:
> 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.

My point is that if you're interacting with untrusted code it's
somewhat dangerous to change system call behavior and if you're
dealing strictly with trusted code you don't need to change
system call behavior.

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

My preference is that we not complicate an environment that has
already proven too difficult for many programmers to use effectively.

> 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.

Believe me, I am familiar with programs, trusted and otherwise,
that go wonky when there are little changes in the behavior of
syscalls. My take is that making security decisions based on the
system call used rather than on the thing being accessed leads
the programmer to expect behavior that does not always match the
underlying implementation. Yes, system call based controls are
easier to use and understand. That does not make them correct.

> 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.

As much as I dislike the modern application paradigms, I don't
see a lot of point in investing in new security facilities that
are not of value in that arena. And I really mean of value, not
just something that some "architect" threw onto a spreadsheet for
the PM to track. I expect that we're overdue for a mindset changing
sort of facility to address the issues that really matter.

Patches for that to follow, but not any time soon. :-)

> --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/