On Sun, Sep 22, 2024 at 6:50 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > On 9/22/2024 8:08 AM, Alice Ryhl wrote: > > 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? > > 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. > > > 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
