[lxc-devel] Kernel bug? Setuid apps and user namespaces

[Andy Lutomirski]

On Mon, Apr 7, 2014 at 11:13 AM, Serge E. Hallyn <serge at hallyn.com> wrote:
> Quoting Andy Lutomirski (luto at amacapital.net):
>> I'm starting to think that we need to extend dumpable to something
>> much more general like a list of struct creds that someone needs to be
>> able to ptrace, *in addition to current creds* in order to access
>> sensitive /proc files, coredumps, etc.  If you get started as setuid,
>
> Hm, yeah, this sort of makes sense.
>
>> then you start with two struct creds in the list (or maybe just your
>> euid and uid).  If you get started !setuid, then your initial creds
>> are in the list.  It's possible that few or no things will need to
>> change that list after execve.
>>
>> If all of the entries and current->cred are in the same user_ns, then
>> we can dump as userns root.  If they're in different usernses, then we
>> dump as global root or maybe the common ancestor root.
>> setuid(getuid()) and other such nastiness may have to empty the list,
>> or maybe we can just use a prctl for that.
>
> A few questions,
>
> 1. is there any other action which would trigger adding a new cred to
> the ist?

I don't think so.  Anyone who can ptrace you from the start can
corrupt you such that you leak rights even if some future action
prevents new ptracers from attaching.

OTOH, it might be nice for something like an HTTPS server to be able
to fork and shove its private key into the child, while preventing
anyone from ptracing the child.  But doing this securely without help
from someone with a different uid might be impossible anyway.

>
> 2. would execve clear (and re-init) the list of creds?

Probably.  Thoughts?

We could have a way to ask execve not to reinit the list.  Such a
mechanism would have to require no_new_privs to prevent a
straightforward attack on any setuid binary.

We's also want PR_SET_DUMPABLE or a new prctl to be able reset the
list to contain just current-.cred, I think.

--Andy