From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Frederick Lawler <fred@cloudflare.com>,
kpsingh@kernel.org, revest@chromium.org, jackmanb@chromium.org,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
john.fastabend@gmail.com, jmorris@namei.org, serge@hallyn.com,
stephen.smalley.work@gmail.com, eparis@parisplace.org,
shuah@kernel.org, brauner@kernel.org, casey@schaufler-ca.com,
bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
kernel-team@cloudflare.com, cgzones@googlemail.com,
karl@bigbadwolfsecurity.com
Subject: Re: [PATCH v4 0/4] Introduce security_create_user_ns()
Date: Mon, 08 Aug 2022 14:43:41 -0500 [thread overview]
Message-ID: <87bksu8qs2.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <877d3ia65v.fsf@email.froward.int.ebiederm.org> (Eric W. Biederman's message of "Mon, 08 Aug 2022 14:26:04 -0500")
"Eric W. Biederman" <ebiederm@xmission.com> writes:
> Paul Moore <paul@paul-moore.com> writes:
>
>>> 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 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".
Frankly I would love to see an argument that semantically it ever makes
sense for creating a user namespace to fail. If that argument has
already been made, my apologies to the person who made as I missed it,
in being sick and tired, and frustrated at being blown off, when
I asked for a proper discuss of the problem at hand.
Eric
next prev parent reply other threads:[~2022-08-08 19:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 18:01 [PATCH v4 0/4] Introduce security_create_user_ns() Frederick Lawler
2022-08-01 18:01 ` [PATCH v4 1/4] security, lsm: " Frederick Lawler
2022-08-02 21:47 ` KP Singh
2022-08-03 13:13 ` Frederick Lawler
2022-08-01 18:01 ` [PATCH v4 2/4] bpf-lsm: Make bpf_lsm_userns_create() sleepable Frederick Lawler
2022-08-01 23:00 ` Alexei Starovoitov
2022-08-01 23:06 ` Paul Moore
2022-08-02 21:29 ` KP Singh
2022-08-01 18:01 ` [PATCH v4 3/4] selftests/bpf: Add tests verifying bpf lsm userns_create hook Frederick Lawler
2022-08-02 22:08 ` KP Singh
2022-08-01 18:01 ` [PATCH v4 4/4] selinux: Implement " Frederick Lawler
2022-08-02 2:56 ` [PATCH v4 0/4] Introduce security_create_user_ns() Eric W. Biederman
2022-08-03 2:10 ` Paul Moore
2022-08-08 18:56 ` Eric W. Biederman
2022-08-08 19:16 ` Paul Moore
2022-08-08 19:26 ` Eric W. Biederman
2022-08-08 19:43 ` Eric W. Biederman [this message]
2022-08-08 22:47 ` Paul Moore
2022-08-09 16:07 ` Eric W. Biederman
2022-08-09 16:47 ` Paul Moore
2022-08-09 21:40 ` Eric W. Biederman
2022-08-09 22:40 ` Paul Moore
2022-08-10 0:51 ` Alexei Starovoitov
2022-08-09 17:43 ` Casey Schaufler
2022-08-09 21:52 ` Eric W. Biederman
2022-08-08 19:49 ` Paul Moore
2022-08-09 16:40 ` Eric W. Biederman
2022-08-14 15:55 ` Serge E. Hallyn
2022-08-15 2:32 ` Paul Moore
2022-08-15 15:41 ` Serge E. Hallyn
2022-08-15 16:24 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bksu8qs2.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=cgzones@googlemail.com \
--cc=daniel@iogearbox.net \
--cc=eparis@parisplace.org \
--cc=fred@cloudflare.com \
--cc=jackmanb@chromium.org \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=karl@bigbadwolfsecurity.com \
--cc=kernel-team@cloudflare.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=revest@chromium.org \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=stephen.smalley.work@gmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.