On Sun, Sep 22, 2024 at 6:50 PM Casey Schaufler [off-list ref] wrote:

On 9/22/2024 8:08 AM, Alice Ryhl wrote:

quoted

On Mon, Sep 16, 2024 at 5:40 PM Casey Schaufler [off-list ref] wrote:

quoted

On 9/15/2024 2:07 PM, Alice Ryhl wrote:

quoted

On Sun, Sep 15, 2024 at 10:58 PM Kees Cook [off-list ref] wrote:

quoted

On Sun, Sep 15, 2024 at 02:31:31PM +0000, Alice Ryhl wrote:

quoted

Add an abstraction for viewing the string representation of a security
context.

Hm, this may collide with "LSM: Move away from secids" is going to happen.
https://lore.kernel.org/all/20240830003411.16818-1-casey@schaufler-ca.com/ (local)

This series is not yet landed, but in the future, the API changes should
be something like this, though the "lsmblob" name is likely to change to
"lsmprop"?
security_cred_getsecid()   -> security_cred_getlsmblob()
security_secid_to_secctx() -> security_lsmblob_to_secctx()

The referenced patch set does not change security_cred_getsecid()
nor remove security_secid_to_secctx(). There remain networking interfaces
that are unlikely to ever be allowed to move away from secids. It will
be necessary to either retain some of the secid interfaces or introduce
scaffolding around the lsm_prop structure.

Binder is currently only supported in SELinux, so this isn't a real issue
today. The BPF LSM could conceivably support binder, but only in cases where
SELinux isn't enabled. Should there be additional LSMs that support binder
the hooks would have to be changed to use lsm_prop interfaces, but I have
not included that *yet*.

quoted

Thanks for the heads up. I'll make sure to look into how this
interacts with those changes.

There will be a follow on patch set as well that replaces the LSMs use
of string/length pairs with a structure. This becomes necessary in cases
where more than one active LSM uses secids and security contexts. This
will affect binder.

When are these things expected to land?

I would like them to land in 6.14, but history would lead me to think
it will be later than that. A lot will depend on how well the large set
of LSM changes that went into 6.12 are received.

quoted

 If this patch series gets
merged in the same kernel cycle as those changes, it'll probably need
special handling.

Yes, this is the fundamental downside of the tree merge development model.

Okay. I'm hoping to land this series in 6.13 so hopefully we won't
need to do anything special.

Alice