Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > > > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> > >> There is no backing store to ramfs and file creation > >> rules are the same as for any other filesystem so > >> it is semantically safe to allow unprivileged users > >> to mount it. > >> > >> The memory control group successfully limits how much > >> memory ramfs can consume on any system that cares about > >> a user namespace root using ramfs to exhaust memory > >> the memory control group can be deployed. > > > > But that does mean that to avoid this new type of attack, when handed a > > new kernel (i.e. by one's distro) one has to explicitly (know about and) > > configure those limits. The "your distro should do this for you" > > argument doesn't seem right. And I'd really prefer there not be > > barriers to user namespaces being compiled in when there don't have to > > be. > > The thing is this really isn't a new type of attack. There are a lot of Of course. > existing methods to exhaust memory with the default configuration on > most distros. All this is is a new method to method to implement such > an attack. Right. ... > > What was your thought on the suggestion to only allow FS_USERNS_MOUNT > > mounts by users confined in a non-init memory cgroup? > > Over design. Ok. Fair. > So shrug. The mechanisms that I am suggesting people use already exist, > and appear to have been present long enough to have made it into debian > stable release February of 2011. Heh - right, libcgroup does have its problems, but I don't think there are any problems with the pam module actually. I'm meant to talk with the debian maintainer for them soon, will test. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
