kernel-packages team mailing list archive

[Serge Hallyn <1263738@xxxxxxxxxxxxxxxxxx>]

Quoting Seth Forshee (seth.forshee+lp@xxxxxxxxxxxxx):
> 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1263738

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

Status in “linux” package in Ubuntu:
  Confirmed
Status in “lxc” package in Ubuntu:
  Triaged
Status in “linux” source package in Trusty:
  Confirmed
Status in “lxc” source package in Trusty:
  Triaged

Bug description:
  When you create a container in a private user namespace, when you start the
  container without the '-d' flag, that console is not properly set up.  Logging in
  gives you

  -bash: no job control in this shell

  and hitting ctrl-c reboots the container.

  Consoles from 'lxc-console -n $container' behave correctly.

  This may be a kernel issue, as discussed here:

  http://lists.linuxcontainers.org/pipermail/lxc-
  devel/2013-October/005843.html

  so also marking this as affecting the kernel.

  This can be worked around, but really needs to be fixed before trusty
  is frozen.

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