On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote: > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > > > On July 8, 2016 1:38:19 PM PDT, Andrew Vagin <avagin@xxxxxxxxxxxxx> > > wrote: > > > > What do you think about the idea to mount nsfs and be able to > > > look up any alive namespace by inum: > > > > I think I like it. It will give us a way to enter any extant > > namespace. It will work for Eric's fs namespaces as well. Perhaps > > a /process/ns/<inum> Directory? As you understood, I meant /proc/ns/<inum> (damn mobile phone completions). > *Shivers* > > That makes it very easy to bypass any existing controls that exist > for getting at namespaces. It is true that everything of that kind > is directory based but still. > > Plus I think it would serve as information leak to information > outside of the container. > > An operation to get a user namespace file descriptor from some kernel > object sounds reasonably sane. > > A great big list of things sounds about as scary as it can get. This > is not the time to be making it easier to escape from containers. To be honest, I think this argument is rubbish. If we're afraid of giving out a list of all the namespaces, it means we're afraid there's some security bug and we're trying to obscure it by making the list hard to get. All we've done is allayed fears about the bug but the hackers still know the portals to get through. If such a bug exists, it will be possible to exploit it by simply reconstructing the information from the individual process directories, so obscurity doesn't protect us and all it does is give us a false sense of security. If such a bug doesn't exist, then all the security mechanisms currently in place (like no re-entry to prior namespace) should protect us and we can give out the list. Let's deal with the world as we'd like it to be (no obscure namespace bugs) and accept the consequences and the responsibility for fixing them if we turn out to be slightly incorrect. We'll end up in a far better place than security by obscurity would land us. James _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
