Message-ID: <afe99ad2-bb53-4e80-bc43-f48b03b014cf@schaufler-ca.com>
Date: Sun, 22 Sep 2024 09:50:30 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Kees Cook <kees@...nel.org>, Paul Moore <paul@...l-moore.com>,
 James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
 Miguel Ojeda <ojeda@...nel.org>, Christian Brauner <brauner@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng
 <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...sung.com>,
 Peter Zijlstra <peterz@...radead.org>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Arve Hjønnevåg <arve@...roid.com>,
 Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
 Joel Fernandes <joel@...lfernandes.org>, Carlos Llamas
 <cmllamas@...gle.com>, Suren Baghdasaryan <surenb@...gle.com>,
 Dan Williams <dan.j.williams@...el.com>, Matthew Wilcox
 <willy@...radead.org>, Thomas Gleixner <tglx@...utronix.de>,
 Daniel Xu <dxu@...uu.xyz>, Martin Rodriguez Reboredo <yakoyoku@...il.com>,
 Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
 linux-security-module@...r.kernel.org, rust-for-linux@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v10 5/8] rust: security: add abstraction for secctx

On 9/22/2024 8:08 AM, Alice Ryhl wrote:
> On Mon, Sep 16, 2024 at 5:40 PM 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.
>>
>> 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.

> Alice

Powered by blists - more mailing lists