On Fri, Aug 26, 2022 at 04:00:39PM -0500, Serge Hallyn wrote: > On Fri, Aug 26, 2022 at 05:00:51PM +0000, Song Liu wrote: > > > > > > > On Aug 26, 2022, at 8:24 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > > > > > > On Thu, Aug 25, 2022 at 09:58:46PM +0000, Song Liu wrote: > > >> > > >> > > >>> On Aug 25, 2022, at 12:19 PM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > >>> > > >>> On Thu, Aug 25, 2022 at 2:15 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > >>>> Paul Moore <paul@xxxxxxxxxxxxxx> writes: > > >>>>> On Fri, Aug 19, 2022 at 10:45 AM Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > > >>>>>> I am hoping we can come up with > > >>>>>> "something better" to address people's needs, make everyone happy, and > > >>>>>> bring forth world peace. Which would stack just fine with what's here > > >>>>>> for defense in depth. > > >>>>>> > > >>>>>> You may well not be interested in further work, and that's fine. I need > > >>>>>> to set aside a few days to think on this. > > >>>>> > > >>>>> I'm happy to continue the discussion as long as it's constructive; I > > >>>>> think we all are. My gut feeling is that Frederick's approach falls > > >>>>> closest to the sweet spot of "workable without being overly offensive" > > >>>>> (*cough*), but if you've got an additional approach in mind, or an > > >>>>> alternative approach that solves the same use case problems, I think > > >>>>> we'd all love to hear about it. > > >>>> > > >>>> I would love to actually hear the problems people are trying to solve so > > >>>> that we can have a sensible conversation about the trade offs. > > >>> > > >>> Here are several taken from the previous threads, it's surely not a > > >>> complete list, but it should give you a good idea: > > >>> > > >>> https://lore.kernel.org/linux-security-module/CAHC9VhQnPAsmjmKo-e84XDJ1wmaOFkTKPjjztsOa9Yrq+AeAQA@xxxxxxxxxxxxxx/ > > >>> > > >>>> As best I can tell without more information people want to use > > >>>> the creation of a user namespace as a signal that the code is > > >>>> attempting an exploit. > > >>> > > >>> Some use cases are like that, there are several other use cases that > > >>> go beyond this; see all of our previous discussions on this > > >>> topic/patchset. As has been mentioned before, there are use cases > > >>> that require improved observability, access control, or both. > > >>> > > >>>> As such let me propose instead of returning an error code which will let > > >>>> the exploit continue, have the security hook return a bool. With true > > >>>> meaning the code can continue and on false it will trigger using SIGSYS > > >>>> to terminate the program like seccomp does. > > >>> > > >>> Having the kernel forcibly exit the process isn't something that most > > >>> LSMs would likely want. I suppose we could modify the hook/caller so > > >>> that *if* an LSM wanted to return SIGSYS the system would kill the > > >>> process, but I would want that to be something in addition to > > >>> returning an error code like LSMs normally do (e.g. EACCES). > > >> > > >> I am new to user_namespace and security work, so please pardon me if > > >> anything below is very wrong. > > >> > > >> IIUC, user_namespace is a tool that enables trusted userspace code to > > >> control the behavior of untrusted (or less trusted) userspace code. > > > > > > No. user namespaces are not a way for more trusted code to control the > > > behavior of less trusted code. > > > > Hmm.. In this case, I think I really need to learn more. > > > > Thanks for pointing out my misunderstanding. > > (I thought maybe Eric would chime in with a better explanation, but I'll > fill it in for now :) > > One of the main goals of user namespaces is to allow unprivileged users > to do things like chroot and mount, which are very useful development > tools, without needing admin privileges. So it's almost the opposite > of what you said: rather than to enable trusted userspace code to control > the behavior of less trusted code, it's to allow less privileged code to > do things which do not affect other users, without having to assume *more* > privilege. > > To be precise, the goals were: > > 1. uid mapping - allow two users to both "use uid 500" without conflicting > 2. provide (unprivileged) users privilege over their own resources > 3. absolutely no extra privilege over other resources > 4. be able to nest > > While (3) was technically achieved, the problem we have is that > (2) provides unprivileged users the ability to exercise kernel code > which they previously could not. The consequence of the refusal to give users any way to control whether or not user namespaces are available to unprivileged users is that a non-significant number of distros still carry the same patch for about 10 years now that adds an unprivileged_userns_clone sysctl to restrict them to privileged users. That includes current Debian and Archlinux btw. The LSM hook is a simple way to allow administrators to control this and will allow user namespaces to be enabled in scenarios where they would otherwise not be accepted precisely because they are available to unprivileged users. I fully understand the motivation and usefulness in unprivileged scenarios but it's an unfounded fear that giving users the ability to control user namespace creation via an LSM hook will cause proliferation of setuid binaries (Ignoring for a moment that any fully unprivileged container with useful idmappings has to rely on the new{g,u}idmap setuid binaries to setup useful mappings anyway.) or decrease system safety let alone cause regressions (Which I don't think is an applicable term here at all.). Distros that have unprivileged user namespaces turned on by default are extremely unlikely to switch to an LSM profile that turns them off and distros that already turn them off will continue to turn them off whether or not that LSM hook is available. It's much more likely that workloads that want to minimize their attack surface while still getting the benefits of user namespaces for e.g. service isolation will feel comfortable enabling them for the first time since they can control them via an LSM profile.
