On Tue, Sep 17, 2024 at 3:18 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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. We discussed this email in-person at Plumbers. I'll outline what we discussed here. > This brings up the point I really want to discuss: what portions of > the LSM framework are currently accessible to Rust, It's relatively limited. I'm adding a way to access the secctx as a string, and a way to manipulate `struct cred`. Basically it just lets you take and drop refcounts on the credential and pass a credential to functions. Other than what is in this patch series, Binder also needs a few other methods. Here are the signatures: fn binder_set_context_mgr(mgr: &Credential) -> Result; fn binder_transaction(from: &Credential, to: &Credential) -> Result; fn binder_transfer_binder(from: &Credential, to: &Credential) -> Result; fn binder_transfer_file(from: &Credential, to: &Credential, file: &File) -> Result; These methods just call into the equivalent C functions. The `Result` return type can hold either an "Ok" which indicates success, or an "Err" which indicates an error. In the latter case, it will hold whichever errno that the C api returns. > 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. That's fine. None of the Rust APIs are stable either. Rust uses the bindgen tool to convert C headers into Rust declarations, so changes to the C api will result in a build failure. This makes it easy to discover issues. > 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? Ideally, you would add a CONFIG_RUST build to your CI setup so that you catch issues early. Of course, if something slips through, then we run build tests on linux-next too, so anything that falls through the cracks should get caught by that. If anything needs Rust changes, you can CC the rust-for-linux list and me, and we will take a look. Same applies to review of Rust code. Alice
