[PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed blob for integrity_iint_cache

[Casey Schaufler]

On 12/1/2023 3:53 PM, Dr. Greg wrote:
> On Fri, Dec 01, 2023 at 10:54:54AM -0800, Casey Schaufler wrote:
>
> Good evening Casey, thanks for taking the time to respond.
>
>> On 11/30/2023 5:05 PM, Dr. Greg wrote:
>>> A suggestion has been made in this thread that there needs to be broad
>>> thinking on this issue, and by extension, other tough problems.  On
>>> that note, we would be interested in any thoughts regarding the notion
>>> of a long term solution for this issue being the migration of EVM to a
>>> BPF based implementation?
>>>
>>> There appears to be consensus that the BPF LSM will always go last, a
>>> BPF implementation would seem to address the EVM ordering issue.
>>>
>>> In a larger context, there have been suggestions in other LSM threads
>>> that BPF is the future for doing LSM's.  Coincident with that has come
>>> some disagreement about whether or not BPF embodies sufficient
>>> functionality for this role.
>>>
>>> The EVM codebase is reasonably modest with a very limited footprint of
>>> hooks that it handles.  A BPF implementation on this scale would seem
>>> to go a long ways in placing BPF sufficiency concerns to rest.
>>>
>>> Thoughts/issues?
>> Converting EVM to BPF looks like a 5 to 10 year process. Creating a
>> EVM design description to work from, building all the support functions
>> required, then getting sufficient reviews and testing isn't going to be
>> a walk in the park. That leaves out the issue of distribution of the
>> EVM-BPF programs. Consider how the rush to convert kernel internals to
>> Rust is progressing. EVM isn't huge, but it isn't trivial, either. Tetsuo
>> had a good hard look at converting TOMOYO to BPF, and concluded that it
>> wasn't practical. TOMOYO is considerably less complicated than EVM.
> Interesting, thanks for the reflections.
>
> On a functional line basis, EVM is 14% of the TOMOYO codebase, not
> counting the IMA code.

For EVM to be completely converted to BPF you'll need significant, but
as yet undiscovered, changes in IMA and, most likely, the LSM infrastructure.

> Given your observations, one would than presume around a decade of
> development effort to deliver a full featured LSM, ie. SELINUX, SMACK,
> APPARMOR, TOMOYO in BPF form.

That's not quite true. A new, from scratch LSM implementing something
like SELinux, Smack or AppArmor would take considerably less time. Converting
an existing LSM and being "bug compatible" is going to be painful.

> Very useful information, we can now return the thread to what appears
> is going to be the vexing implementation of:
>
> lsm_set_order(LSM_ORDER_FU_I_REALLY_AM_GOING_TO_BE_THE_LAST_ONE_TO_RUN);

Just so.

>
> :-)
>
> Have a good weekend.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
>