[lkml]   [2013]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH review 5/6] userns: Allow the userns root to mount ramfs.
Quoting Eric W. Biederman (
> "Serge E. Hallyn" <> writes:
> > Quoting Eric W. Biederman (
> >>
> >> 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.



> > 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.


 \ /
  Last update: 2013-01-27 20:01    [W:0.039 / U:2.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site