Message-ID: <87wnbia7jh.fsf@email.froward.int.ebiederm.org>
Date:   Mon, 08 Aug 2022 13:56:18 -0500
From:   "Eric W. Biederman" <ebiederm@...ssion.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Frederick Lawler <fred@...udflare.com>, kpsingh@...nel.org,
        revest@...omium.org, jackmanb@...omium.org, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        jmorris@...ei.org, serge@...lyn.com,
        stephen.smalley.work@...il.com, eparis@...isplace.org,
        shuah@...nel.org, brauner@...nel.org, casey@...aufler-ca.com,
        bpf@...r.kernel.org, linux-security-module@...r.kernel.org,
        selinux@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        kernel-team@...udflare.com, cgzones@...glemail.com,
        karl@...badwolfsecurity.com
Subject: Re: [PATCH v4 0/4] Introduce security_create_user_ns()

Paul Moore <paul@...l-moore.com> writes:

> On Mon, Aug 1, 2022 at 10:56 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> Frederick Lawler <fred@...udflare.com> writes:
>>
>> > While creating a LSM BPF MAC policy to block user namespace creation, we
>> > used the LSM cred_prepare hook because that is the closest hook to prevent
>> > a call to create_user_ns().
>>
>> Re-nack for all of the same reasons.
>> AKA This can only break the users of the user namespace.
>>
>> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>>
>> You aren't fixing what your problem you are papering over it by denying
>> access to the user namespace.
>>
>> Nack Nack Nack.
>>
>> Stop.
>>
>> Go back to the drawing board.
>>
>> Do not pass go.
>>
>> Do not collect $200.
>
> If you want us to take your comments seriously Eric, you need to
> provide the list with some constructive feedback that would allow
> Frederick to move forward with a solution to the use case that has
> been proposed.  You response above may be many things, but it is
> certainly not that.

I did provide constructive feedback.  My feedback to his problem
was to address the real problem of bugs in the kernel.

It is not a constructive approach to shoot the messenger
and is not a constructive approach to blow me off every time you
reply.

I have proposed that is there is a subsystem that is unduly buggy we
stop it from being enabled with a user-namespaces.

Further this is a hook really should have extra-ordinary requirements,
as all it can do is add additional failure modes to something that
does not really fail.  AKA all it can do is break-userspace.

As such I need to see a justification on why it makes sense to
break-userspace.

> We've heard from different users now that there are very real use
> cases for this LSM hook.  I understand you are concerned about adding
 > additional controls to user namespaces, but these are controls
> requested by real users, and the controls being requested (LSM hooks,
> with BPF and SELinux implementations) are configurable by the *users*
> at *runtime*.  This patchset does not force additional restrictions on
> user namespaces, it provides a mechanism that *users* can leverage to
> add additional granularity to the access controls surrounding user
> namespaces.

But that is not the problem that cloudfare encountered and are trying to
solve.

At least that is not what I was told when I asked early in the review
cycle.

All saying that is user-configurable does is shift the blame from the
kernel maintainers to the users.  Shift the responsibility from people
who should have enough expertise to know what is going on to people
who are by definition have other concerns, so are less likely to be as
well informed, and less likely to come up with good solutions.

> Eric, if you have a different approach in mind to adding a LSM hook to
> user namespace creation I think we would all very much like to hear
> about it.  However, if you do not have any suggestions along those
> lines, and simply want to NACK any effort to add a LSM hook to user
> namespace creation, I think we all understand your point of view and
> respectfully disagree.  Barring any new approaches or suggestions, I
> think Frederick's patches look reasonable and I still plan on merging
> them into the LSM next branch when the merge window closes.


But it is my code you are planning to merge this into, and your are
asking me to support something.

I admit I have not had time to read everything.  I am sick and tired
and quite frankly very tired that people are busy wanting to shoot
the messenger to the fact that there are bugs in the kernel.

I am speaking up and engaging as best as I can with objections that
are not hot-air.

You are very much proposing to merge code that can only cause
regressions and cause me grief.  At least that is all I see.  I don't
see anything in the change descriptions of the change that refutes that.

I don't see any interaction in fact with my concerns.

In fact your last reply was to completely blow off my request on how to
address the concerns that inspired this patch and to say other people
have a use too.

At this point I am happy to turn your request around and ask that you
address my concerns and not blow them off.  As I have seen no
constructive engagement with my concerns.   I think that is reasonable
as by definition I will get the support issues when some LSM has some
ill-thought out idea of how things should work and I get the bug report.

Eric

Powered by blists - more mailing lists