linux-kernel - Re: [PATCH v10 5/8] rust: security: add abstraction for secctx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240922150149.3133570-1-aliceryhl@google.com>
Date: Sun, 22 Sep 2024 15:01:49 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: paul@...l-moore.com
Cc: a.hindborg@...sung.com, alex.gaynor@...il.com, aliceryhl@...gle.com, 
	arve@...roid.com, benno.lossin@...ton.me, bjorn3_gh@...tonmail.com, 
	boqun.feng@...il.com, brauner@...nel.org, casey@...aufler-ca.com, 
	cmllamas@...gle.com, dan.j.williams@...el.com, dxu@...uu.xyz, 
	gary@...yguo.net, gregkh@...uxfoundation.org, jmorris@...ei.org, 
	joel@...lfernandes.org, kees@...nel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, 
	maco@...roid.com, ojeda@...nel.org, peterz@...radead.org, 
	rust-for-linux@...r.kernel.org, serge@...lyn.com, surenb@...gle.com, 
	tglx@...utronix.de, tkjos@...roid.com, tmgross@...ch.edu, 
	viro@...iv.linux.org.uk, wedsonaf@...il.com, willy@...radead.org, 
	yakoyoku@...il.com
Subject: Re: [PATCH v10 5/8] rust: security: add abstraction for secctx

On Tue, Sep 17, 2024 at 3:18 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Mon, Sep 16, 2024 at 11:40 AM Casey Schaufler <casey@...aufler-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@...nel.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