Thread (2 messages) 2 messages, 2 authors, 2022-08-08

Re: [PATCH v4 0/4] Introduce security_create_user_ns()

From: Paul Moore <paul@paul-moore.com>
Date: 2022-08-08 19:50:07
Also in: bpf, linux-kselftest, lkml, netdev, selinux

Possibly related (same subject, not in this thread)

On Mon, Aug 8, 2022 at 3:26 PM Eric W. Biederman [off-list ref] wrote:
Paul Moore [off-list ref] writes:
quoted
quoted
I did provide constructive feedback.  My feedback to his problem
was to address the real problem of bugs in the kernel.
We've heard from several people who have use cases which require
adding LSM-level access controls and observability to user namespace
creation.  This is the problem we are trying to solve here; if you do
not like the approach proposed in this patchset please suggest another
implementation that allows LSMs visibility into user namespace
creation.
Please stop, ignoring my feedback, not detailing what problem or
problems you are actually trying to be solved, and threatening to merge
code into files that I maintain that has the express purpose of breaking
my users.
I've heard you talk about bugs being the only reason why people would
want to ever block user namespaces, but I think we've all seen use
cases now where it goes beyond that.  However, even if it didn't, the
need to build high confidence/assurance systems where big chunks of
functionality can be disabled based on a security policy is a very
real use case, and this patchset would help enable that.  I've noticed
you like to talk about these hooks being a source of "regressions",
but access controls are not regressions Eric, they are tools that
system builders, administrators, and users use to secure their
systems.

From my perspective, I believe that addresses your feedback around
"fix the bugs" and "this is a regression", which is the only thing
I've noted from your responses in this thread and others, but if I'm
missing something more technical please let me/us know.
You just artificially constrained the problems, so that no other
solution is acceptable.
There is a real need to be able to gain both additional visibility and
access control over user namespace creation, please suggest the
approach(es) you would find acceptable.
On that basis alone I am object to this whole
approach to steam roll over me and my code.
I saw that choice of wording in your last email and thought it a bit
curious, so I did a quick git log dump on kernel/user_namespace.c and
I see approximately 31 contributors to that one file.  I've always
thought of the open source maintainer role as more of a "steward" and
less of an "owner", but that's just my opinion.

-- 
paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help