[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <749fcbf2e2094606b31a07ba3d480bd90d7c1890.camel@HansenPartnership.com>
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.
