On Sun, Jan 15, 2012 at 1:32 PM, Casey Schaufler<casey@xxxxxxxxxxxxxxxx> wrote:On 1/15/2012 12:59 PM, Andrew Lutomirski wrote:If you don't trust that binary, then why are you execing it with savedOn Sun, Jan 15, 2012 at 12:16 PM, Casey Schaufler
<casey@xxxxxxxxxxxxxxxx> wrote:
On 1/14/2012 12:22 PM, Linus Torvalds wrote:Can you think of *any* plausible attack that is possible with my patchAnd yes, I really seriously do believe that is both safer and simpler
than some model that says "you can drop stuff", and then you have to
start making up rules for what "dropping" means.
Does "dropping" mean allowing setuid(geteuid()) for example? That *is*
dropping the uid in a _POSIX_SAVED_IDS environment. And I'm saying
that no, we should not even allow that. It's simply all too "subtle".
I am casting my two cents worth behind Linus. Dropping
privilege can be every bit as dangerous as granting privilege
in the real world of atrocious user land code. Especially in
the case of security policy enforcing user land code.
(i.e. no_new_privs allows setuid, setresuid, and capset) that would be
prevented or even mitigated if I blocked those syscalls? I can't.
(The sendmail-style attack is impossible with no_new_privs.)
I am notoriously bad at coming up with this sort of example.
I will try, I may not hit the mark, but it should be close.
The application is running with saved uid != euid when
no-new-privs is set. It execs a new binary, which keeps
the saved and effective uids. The program calls setreuid,
which succeeds. It opens the saved userid's files.
uid != euid in the first place?
If you are setting no_new_privs, then
you are new code and should have at least some basic awareness of the
semantics.
The exact same "exploit" is possible if you have
CAP_DAC_OVERRIDE with either no_new_privs semantics -- if you have a
privilege and you run untrusted code, then you had better remove that
privilege somehow for the untrusted code.
IOW, *drop privileges if you are a sandbox*. Otherwise you're screwed
with or without no_new_privs.
Another way of saying this is: no_new_privs is not a sandbox. It's
just a way to make it safe for sandboxes and other such weird things
processes can do to themselves safe across execve. If you want a
sandbox, use seccomp mode 2, which will require you to set
no_new_privs.
--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/