[PATCH v10 5/8] rust: security: add abstraction for secctx

[Alice Ryhl]

On Tue, Sep 17, 2024 at 3:18 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Mon, Sep 16, 2024 at 11:40 AM Casey Schaufler <casey at schaufler-ca.com> wrote:
> > On 9/15/2024 2:07 PM, Alice Ryhl wrote:
> > > On Sun, Sep 15, 2024 at 10:58 PM Kees Cook <kees at kernel.org> 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@schaufler-ca.com/
> > >>
> > >> 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