On Mon, Sep 16, 2024 at 11:40 AM 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 ... First, thanks for CC'ing the LSM list Alice, I appreciate it. As Kees and Casey already pointed out, there are relevant LSM changes that are nearing inclusion which might be relevant to the Rust abstractions. I don't think there is going to be anything too painful, but I must admit that my Rust knowledge has sadly not progressed much beyond the most basic "hello world" example. This brings up the point I really want to discuss: what portions of the LSM framework are currently accessible to Rust, and what do we (the LSM devs) need to do to preserve the Rust LSM interfaces when the LSM framework is modified? While the LSM framework does not change often, we do modify both the LSM hooks (the security_XXX() calls that serve as the LSM interface/API) and the LSM callbacks (the individual LSM hook implementations) on occasion as they are intentionally not part of any sort of stable API. In a perfect world we/I would have a good enough understanding of the Rust kernel abstractions and would submit patches to update the Rust code as appropriate, but that isn't the current situation and I want to make sure the LSM framework and the Rust interfaces don't fall out of sync. Do you watch the LSM list or linux-next for patches that could affect the Rust abstractions? Is there something else you would recommend? -- paul-moore.com
