On Mon, Aug 1, 2022 at 6:35 PM Paul Moore paul@paul-moore.com wrote:
On Mon, Aug 1, 2022 at 11:25 AM Casey Schaufler casey@schaufler-ca.com wrote:
On 8/1/2022 6:13 AM, Frederick Lawler wrote:
On 7/22/22 7:20 AM, Paul Moore wrote:
On July 22, 2022 2:12:03 AM Martin KaFai Lau kafai@fb.com wrote:
On Thu, Jul 21, 2022 at 12:28:04PM -0500, Frederick Lawler wrote:
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