On Mon, Aug 1, 2022 at 6:35 PM Paul Moore [off-list ref] wrote:

On Mon, Aug 1, 2022 at 11:25 AM Casey Schaufler [off-list ref] wrote:

quoted

On 8/1/2022 6:13 AM, Frederick Lawler wrote:

quoted

On 7/22/22 7:20 AM, Paul Moore wrote:

quoted

On July 22, 2022 2:12:03 AM Martin KaFai Lau [off-list ref] wrote:

quoted

On Thu, Jul 21, 2022 at 12:28:04PM -0500, Frederick Lawler wrote:

quoted

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().

The calls look something like this:

cred = prepare_creds()
security_prepare_creds()
call_int_hook(cred_prepare, ...
if (cred)
create_user_ns(cred)

We noticed that error codes were not propagated from this hook and
introduced a patch [1] to propagate those errors.

The discussion notes that security_prepare_creds()
is not appropriate for MAC policies, and instead the hook is
meant for LSM authors to prepare credentials for mutation. [2]

Ultimately, we concluded that a better course of action is to
introduce
a new security hook for LSM authors. [3]

This patch set first introduces a new security_create_user_ns()
function
and userns_create LSM hook, then marks the hook as sleepable in BPF.

Patch 1 and 4 still need review from the lsm/security side.

This patchset is in my review queue and assuming everything checks
out, I expect to merge it after the upcoming merge window closes.

I would also need an ACK from the BPF LSM folks, but they're CC'd on
this patchset.

Based on last weeks comments, should I go ahead and put up v4 for
5.20-rc1 when that drops, or do I need to wait for more feedback?

As the primary consumer of this hook is BPF I would really expect their
reviewed-by before accepting this.

We love all our in-tree LSMs equally.  As long as there is at least
one LSM which provides an implementation and has ACK'd the hook, and
no other LSMs have NACK'd the hook, then I have no problem merging it.
I doubt it will be necessary in this case, but if we need to tweak the
hook in the future we can definitely do that; we've done this in the
past when it has made sense.

As a reminder, the LSM hooks are *not* part of the "don't break
userspace" promise.  I know it gets a little muddy with the way the

That's correct. Also, with BPF LSM, we encourage users to
build the application / bpf program logic to be resilient to changes
in the LSM hooks.

I am happy to share how we've done it, if folks are interested.

- KP

BPF LSM works, but just as we don't want to allow one LSM to impact
the runtime controls on another, we don't want to allow one LSM to
freeze the hooks for everyone.

--
paul-moore.com