[Bug 1263738] Re: login console 0 in user namespace container is not configured right

[Serge Hallyn]

Quoting Seth Forshee (seth.forshee+lp at canonical.com):
> On Wed, Jan 15, 2014 at 06:37:41PM -0000, Serge Hallyn wrote:
> > If it is possible to get to the inode backing the tty at this point
> > then we should be able to do inode_capable(tty_inode(tty),
> > CAP_SYS_ADMIN), which should be safe and adquate right?
> > 
> > But I dont' think we can get inode from tty.  However we can get the
> 
> I'm new to how capabilities are handled with user namespaces, but at a
> glance I think inode_capable() looks sufficient. We can't get the inode
> from the tty but it could easily be passed as an argument the function
> containing that code.

The question actually remains: what do we need privilege toward?  If
user A has file F open, and we are going to steal F from A...  IIUC we
already should have check for permission to access F right?  So now the
question is only whether we can take something from A, or whether A is
more privileged than us.

> > tty->session which is a struct pid*.  So we can check whether we have
> > ns_capable(ns_of_pid(tty->session), CAP_SYS_ADMIN)
> 
> Except that we're not interested in the capabilities of tty->session but

The ns_capable line doesn't check the capabilities of tty->session,
but rather current's capabilities targeted toward the user namespace
which owns tty->session.

> of current since current is the one doing the stealing. So that should
> probably be ns_capable(current_user_ns(), CAP_SYS_ADMIN).

That would check the privilege of current toward his own userns.  Any
unprivileged user can clone(CLONE_NEWUSER) and have that test evaluate
to true.

> I'm thinking though we also need to verify that tty->session is in the
> same namespace, otherwise nothing seems to prevent a lesser priveleged
> namespace from doing mknod and stealing any tty from another namespace,
> which seems like a serious security issue. So something along the lines
> of:
> 
>   if (arg == 1 &&
>       (capable(CAP_SYS_ADMIN) ||
>        (current_user_namespace() == ns_of_pid(tty->session) &&
>         ns_capable(current_user_ns(), CAP_SYS_ADMIN)))) {
>           /* steal tty */
>   }
> 
> Or am I being too paranoid?

That would be the point of doing:

        ns_capable(ns_of_pid(tty->session), CAP_SYS_ADMIN)

If you are in a child userns of init, you cannot CAP_SYS_ADMIN toward
init's pidns.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1263738

Title:
  login console 0 in user namespace container is not configured right

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263738/+subscriptions