[lxc-devel] User namespaces

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at ubuntu.com> writes:

> Quoting Dwight Engen (dwight.engen at oracle.com):
>> I finally got around to testing out user namespaces. Very nice to to
>> have container root not be kuid 0! One thing that I noticed was that
>> mingetty in the container was failing because the call to vhangup(2)
>> failed (and thus no lxc-console). I could patch the container to start
>> mingetty with --nohangup, but that feels like a workaround and
>> wouldn't be good when the terminal got reused in the container. Instead
>> I patched my kernel with:
>> 
>> diff --git a/fs/open.c b/fs/open.c
>> index 9b33c0c..7c54d1d7 100644
>> --- a/fs/open.c
>> +++ b/fs/open.c
>> @@ -1059,7 +1059,7 @@ EXPORT_SYMBOL(sys_close);
>>   */
>>  SYSCALL_DEFINE0(vhangup)
>>  {
>> -	if (capable(CAP_SYS_TTY_CONFIG)) {
>> +	if (ns_capable(current_user_ns(), CAP_SYS_TTY_CONFIG)) {
>
> Note there is a nsown_capable(CAP_SYS_TTY_CONFIG) shortcut for this,
> but
>
>>  		tty_vhangup_self();
>>  		return 0;
>>  	}
>> 
>> This lets mingetty work, but I'm not so sure it safe to allow a
>> CAP_SYS_TTY_CONFIG capable process in the namespace hangup whatever
>> terminal it might be able to open and get to be its controlling
>> terminal. I guess the terminal would have to be open()able or
>> TIOCSCTTY'able in the container, but is that enough protection?
>> Thoughts?
>
> I don't think nsown_capable() is sufficient here.  Rather, we need
> to check against the user namespace owning get_current_tty().  So what
> is that, the get_current_tty()->pgrp->upid[level]->user_ns ?
> Or can we walk over the get_current_tty()->tty_files and see if any
> of those match?
>
> (Eric cc:d as this may be something he's already thought about.)

I have not thought about a less than superprivilege revoke.

Is this vhangup happening on pseudo-tty acting as /dev/console?

Part of me really wants to say the answer should be don't do that then.

Reading the code the current unprivileged uses of tty_vhangup are:
- The pty master closing.
- A session group leader exiting with a controlling tty (that is not a pty).

Which suggests that if you are root in the user namespace of the session
that currently owns the tty it is reasonable to force a hangup for
regulary ttys.  I don't know about ptys.

I guess that would require capabilities in ns_of_pid(tty->session)->user_ns.

Being able to kill the process that is the pty master also seems
reasonable.

However I don't think either of those really answer the question for
when it is ok send vhangup to a pty whose master lies outside of the
current user namespace.  Which I am pretty certain is the case in
question.

Eric