[PATCH v5 0/4] Introduce security_create_user_ns()

[Eric W. Biederman]

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 reason why I implemented user namespaces is so that all of linux's
neat features could be exposed to non-root userspace processes, in
a way that doesn't break suid root processes.


The access control you are adding to user namespaces looks to take that
away.  It looks to remove the whole point of user namespaces.


So without any mention of how people intend to use this feature, without
any code that uses this hook to implement semantics.  Without any talk
about how this semantic change is reasonable.  I strenuously object.

Eric