Messages in this thread | | | Date | Thu, 14 Feb 2013 20:08:16 -0600 | From | Corey Minyard <> | Subject | Re: [PATCH] Move console redirect to pid namespace |
| |
On 02/13/2013 01:08 PM, Eric W. Biederman wrote: > Bruno Prémont <bonbons@linux-vserver.org> writes: > >> CCing containers list >> >> On Fri, 08 February 2013 minyard@acm.org wrote: >>> From: Corey Minyard <cminyard@mvista.com> >>> >>> 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@mvista.com> >>> --- >>> >>> 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 >> better. > 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.
I'm not sure I follow. Are these changes in k.org, or in another repository someplace?
> > Is there a desire to have TIOCCONS not just fail in a container but to > have TIOCCONS work in a container specific way?
Well, my desire is for the host console to work properly if a container uses TIOCCONS :-). It seems to me that the most consistent way to handle this is to have TIOCCONS in a container redirect the container's console.
> >>> 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.
I would agree, but it would still require something like a workqueue. Is there a better mechanism?
-corey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |