[PATCH v5 0/4] Introduce security_create_user_ns()

[Paul Moore]

On Thu, Aug 18, 2022 at 10:05 AM Serge E. Hallyn <serge at hallyn.com> wrote:
> On Wed, Aug 17, 2022 at 04:24:28PM -0500, Eric W. Biederman wrote:
> > Paul Moore <paul at paul-moore.com> writes:
> > > On Wed, Aug 17, 2022 at 4:56 PM Eric W. Biederman <ebiederm at xmission.com> wrote:
> > >> Paul Moore <paul at paul-moore.com> writes:
> > >> > On Wed, Aug 17, 2022 at 3:58 PM Eric W. Biederman <ebiederm at xmission.com> wrote:
> > >> >> Paul Moore <paul at paul-moore.com> writes:
> > >> >>
> > >> >> > At the end of the v4 patchset I suggested merging this into lsm/next
> > >> >> > so it could get a full -rc cycle in linux-next, assuming no issues
> > >> >> > were uncovered during testing
> > >> >>
> > >> >> What in the world can be uncovered in linux-next for code that has no in
> > >> >> tree users.
> > >> >
> > >> > The patchset provides both BPF LSM and SELinux implementations of the
> > >> > hooks along with a BPF LSM test under tools/testing/selftests/bpf/.
> > >> > If no one beats me to it, I plan to work on adding a test to the
> > >> > selinux-testsuite as soon as I'm done dealing with other urgent
> > >> > LSM/SELinux issues (io_uring CMD passthrough, SCTP problems, etc.); I
> > >> > run these tests multiple times a week (multiple times a day sometimes)
> > >> > against the -rcX kernels with the lsm/next, selinux/next, and
> > >> > audit/next branches applied on top.  I know others do similar things.
> > >>
> > >> A layer of hooks that leaves all of the logic to userspace is not an
> > >> in-tree user for purposes of understanding the logic of the code.
> > >
> > > The BPF LSM selftests which are part of this patchset live in-tree.
> > > The SELinux hook implementation is completely in-tree with the
> > > subject/verb/object relationship clearly described by the code itself.
> > > After all, the selinux_userns_create() function consists of only two
> > > lines, one of which is an assignment.  Yes, it is true that the
> > > SELinux policy lives outside the kernel, but that is because there is
> > > no singular SELinux policy for everyone.  From a practical
> > > perspective, the SELinux policy is really just a configuration file
> > > used to setup the kernel at runtime; it is not significantly different
> > > than an iptables script, /etc/sysctl.conf, or any of the other myriad
> > > of configuration files used to configure the kernel during boot.
> >
> > I object to adding the new system configuration knob.
>
> I do strongly sympathize with Eric's points.  It will be very easy, once
> user namespace creation has been further restricted in some distros, to
> say "well see this stuff is silly" and go back to simply requiring root
> to create all containers and namespaces, which is generally quite a bit
> easier anywway.  And then, of course, give everyone root so they can
> start containers.

That's assuming a lot.  Many years have passed since namespaces were
first introduced, and awareness of good security practices has
improved, perhaps not as much as any of us would like, but to say that
distros, system builders, and even users are the same as they were so
many years ago is a bit of a stretch in my opinion.

However, even ignoring that for a moment, do we really want to go to a
place where we dictate how users compose and secure their systems?
Linux "took over the world" because it offered a level of flexibility
that wasn't really possible before, and it has flourished because it
has kept that mentality.  The Linux Kernel can be shoehorned onto most
hardware that you can get your hands on these days, with driver
support for most anything you can think to plug into the system.  Do
you want a single-user environment with no per-user separation?  We
can do that.  Do you want a traditional DAC based system that leans
heavy on ACLs and capabilities?  We can do that.  Do you want a
container host that allows you to carve up the system with a high
degree of granularity thanks to the different namespaces?  We can do
that.  How about a system that leverages the LSM to enforce a least
privilege ideal, even on the most privileged root user?  We can do
that too.  This patchset is about giving distro, system builders, and
users another choice in how they build their system.  We've seen both
in this patchset and in previously failed attempts that there is a
definite want from a user perspective for functionality such as this,
and I think it's time we deliver it in the upstream kernel so they
don't have to keep patching their own systems with out-of-tree
patches.

> Eric and Paul, I wonder, will you - or some people you'd like to represent
> you - be at plumbers in September?  Should there be a BOF session there?  (I
> won't be there, but could join over video)  I think a brainstorming session
> for solutions to the above problems would be good.

Regardless of if Eric or I will be at LPC, it is doubtful that all of
the people who have participated in this discussion will be able to
attend, and I think it's important that the users who are asking for
this patchset have a chance to be heard in each forum where this is
discussed.  While conferences are definitely nice - I definitely
missed them over the past couple of years - we can't use them as a
crutch to help us reach a conclusion on this issue; we've debated much
more difficult things over the mailing lists, I see no reason why this
would be any different.

-- 
paul-moore.com