Bruno PrÃmont <bonbons@xxxxxxxxxxxxxxxxx> writes:
CCing containers listWith recent changes this is tied to the initial user namespace. So the
On Fri, 08 February 2013 minyard@xxxxxxx wrote:From: Corey Minyard <cminyard@xxxxxxxxxx>With recent changes, tying it to init user namespace might even be
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
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?
Actually getting destroy_pid_namespace out of interrupt context wouldn'tThe 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.
be the worst thing in the world.