On Wed, Jan 15, 2014 at 07:53:54PM -0000, Seth Forshee wrote:
> 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?
mknod isn't possible from a userns, otherwise we'd be in a lot more
problem than just tty devices (think what would hapeen if I could mknod
sda in a container).
On Wed, Jan 15, 2014 at 07:53:54PM -0000, Seth Forshee wrote: tty_inode( tty), ns_of_pid( tty->session) , CAP_SYS_ADMIN) current_ user_ns( ), CAP_SYS_ADMIN). CAP_SYS_ ADMIN) || user_namespace( ) == ns_of_pid( tty->session) && current_ user_ns( ), CAP_SYS_ADMIN)))) {
> 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(
> > 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(
>
> 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(
>
> 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(
> (current_
> ns_capable(
> /* steal tty */
> }
>
> Or am I being too paranoid?
mknod isn't possible from a userns, otherwise we'd be in a lot more
problem than just tty devices (think what would hapeen if I could mknod
sda in a container).
> /bugs.launchpad .net/bugs/ 1263738 /bugs.launchpad .net/ubuntu/ +source/ linux/+ bug/1263738/ +subscriptions
> --
> You received this bug notification because you are subscribed to lxc in
> Ubuntu.
> Matching subscriptions: containers
> https:/
>
> Title:
> login console 0 in user namespace container is not configured right
>
> To manage notifications about this bug go to:
> https:/
-- www.ubuntu. com
Stéphane Graber
Ubuntu developer
http://