Re: [PATCH] Move console redirect to pid namespace
From: Eric W. Biederman
Date: Wed Feb 13 2013 - 14:08:35 EST
Bruno PrÃmont <bonbons@xxxxxxxxxxxxxxxxx> writes:
> CCing containers list
> On Fri, 08 February 2013 minyard@xxxxxxx wrote:
>> From: Corey Minyard <cminyard@xxxxxxxxxx>
>> The console redirect - ioctl(fd, TIOCCONS) - is not in a namespace,
>> thus a container can do a redirect and grab all the I/O on the host
>> and all container consoles.
>> This change puts the redirect in the pid namespace.
>> Signed-off-by: Corey Minyard <cminyard@xxxxxxxxxx>
>> I'm pretty sure this patch is not correct, but I'm not quite sure the
>> best way to fix this. I'm not 100% sure that the pid namespace is the
>> right place, but it seemed the most reasonable of all the choices. The
>> other obvious choice is the mount namespace, but it didn't seem as good
>> a fit.
> With recent changes, tying it to init user namespace might even be
With recent changes this is tied to the initial user namespace. So the
simple solution to this and so many other similiar security problems is
to run your container in a user namespace.
The permission check currently is capable(CAP_SYS_ADMIN) which requires
the caller to have the CAP_SYS_ADMIN in the initial user namespace.
Is there a desire to have TIOCCONS not just fail in a container but to
have TIOCCONS work in a container specific way?
>> The other problem is that I don't think you can call fput() from
>> destroy_pid_namespace(). That can be called from interrupt context,
>> and I don't think fput() is safe there. I know it's not safe in 3.4
>> with the RT patch applied. However, the only way I've come up with to
>> fix it is to add a workqueue, and that seems a bit heavy for this.
Actually getting destroy_pid_namespace out of interrupt context wouldn't
be the worst thing in the world.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/