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 22:47:41
Also in: bpf, linux-kselftest, lkml, netdev, selinux

On Mon, Aug 8, 2022 at 3:43 PM Eric W. Biederman [off-list ref] wrote:
"Eric W. Biederman" [off-list ref] writes:
quoted
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.

You just artificially constrained the problems, so that no other
solution is acceptable.  On that basis alone I am object to this whole
approach to steam roll over me and my code.
If you want an example of what kind of harm it can cause to introduce a
failure where no failure was before I invite you to look at what
happened with sendmail when setuid was modified to fail, when changing
the user of a process would cause RLIMIT_NPROC to be exceeded.
I think we are all familiar with the sendmail capabilities bug and the
others like it, but using that as an excuse to block additional access
controls seems very weak.  The Linux Kernel is very different from
when the sendmail bug hit (what was that, ~20 years ago?), with
advancements in capabilities and other discretionary controls, as well
as mandatory access controls which have enabled Linux to be certified
through a number of third party security evaluations.
I am not arguing that what you are proposing is that bad but unexpected
failures cause real problems, and at a minimum that needs a better
response than: "There is at least one user that wants a failure here".
Let me fix that for you: "There are multiple users who want to have
better visibility and access control for user namespace creation."

--
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