Comment 15 for bug 1263738

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.

> 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
of current since current is the one doing the stealing. So that should
probably be ns_capable(current_user_ns(), CAP_SYS_ADMIN).

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?