[lxc-devel] User namespaces

[Dwight Engen]

On Sun, 24 Feb 2013 21:12:59 -0800
ebiederm at xmission.com (Eric W. Biederman) wrote:

> 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

Ahh, I missed that, thanks!

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

I agree I don't think nsown_capable() is enough. I'm not sure what we
should be checking though. I don't think we can use pgrp for the same
disassociate reason as tty->session below.

> > (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?

Yes, its done on the ptys lxc set up for the container's /dev/console
and /dev/tty[1-4].

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

I think the reason mingetty wants to do the vhangup is still valid in
the container case though? ie. it wants to make sure any process that
has fds refering to the slave pty from the last login session get set
to hung up ops.

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

What defines which user namespace a pty is in? I guess I'm not sure
if the pty master should be considered outside the new user namespace
or not. lxc creates the pty pair while in the parent ns, and chowns
the slave into a uid in the new user ns. I guess it could fchown the
master too, though it doesn't right now. The mingetty attempting vhangup
is in the new user ns.

ns_of_pid(tty->session)->user_ns is likely also the new user ns, but I
think we can't just use that in a ns_capable check because tty->session
might be NULL if the the tty has been disassociated as the controlling
terminal. I think we need a check that will work even after
disassociation since there could still be fds that need hang up.

> Eric
>