On Mon, Sep 16, 2024 at 5:40 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > On 9/15/2024 2:07 PM, Alice Ryhl wrote: > > On Sun, Sep 15, 2024 at 10:58 PM Kees Cook <kees@xxxxxxxxxx> wrote: > >> On Sun, Sep 15, 2024 at 02:31:31PM +0000, Alice Ryhl wrote: > >>> 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@xxxxxxxxxxxxxxxx/ > >> > >> 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*. > > > 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? If this patch series gets merged in the same kernel cycle as those changes, it'll probably need special handling. Alice
