Date: Sat, 05 Feb 2022 08:57:34 -0500 From: James Bottomley <James.Bottomley@...senPartnership.com> To: "Anton V. Boyarshinov" <boyarsh@...linux.org>, Christian Brauner <brauner@...nel.org> Cc: viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org, ebiederm@...ssion.com, legion@...nel.org, ldv@...linux.org, linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com, Christoph Hellwig <hch@....de>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH] Add ability to disallow idmapped mounts On Sat, 2022-02-05 at 10:57 +0300, Anton V. Boyarshinov wrote: > В Fri, 4 Feb 2022 16:10:32 +0100 > Christian Brauner <brauner@...nel.org> пишет: > > > > > It turns off much more than idmapped mounts only. More fine > > > grained control seems better for me. > > > > If you allow user namespaces and not idmapped mounts you haven't > > reduced your attack surface. > > I have. And many other people have. People who have creating user > namespaces by unpriviliged user disabled. Which would defeat the purpose of user namespaces which is to allow the creation of unprivileged containers by anyone and allow us to reduce the container attack surface by reducing the actual privilege given to some real world containers. You've raised vague, unactionable security concerns about this, but basically one of the jobs of user namespaces is to take some designated features guarded by CAP_SYS_ADMIN and give the admin of the namespace (the unprivileged user) access to them. There are always going to be vague security concerns about doing this. If you had an actual, actionable concern, we could fix it. What happens without this is that containers that need the functionality now have to run with real root inside, which is a massively bigger security problem. Adding knobs to disable features for unactionable security concerns gives a feel good in terms of security theatre, but it causes system unpredictability in that any given application now has to check if a feature is usable before it uses it and figure out what to do if it isn't available. The more we do it, the bigger the combinatoric explosion of possible missing features and every distro ends up having a different default combination. The bottom line is it's much better to find and fix actual security bugs than create a runtime configuration nightmare. > I find it sad that we have no tool in mainline kernel to limit users > access to creating user namespaces except complete disabling them. > But many distros have that tools. Different tools with different > interfaces and semantics :( Have you actually proposed something? A more granular approach to globally disabling user namespaces might be acceptable provided it doesn't lead to a feature configuration explosion. James
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.