Message-ID: <876cdd6b-6082-4503-b2fe-3bb11c30965a@schaufler-ca.com>
Date:   Fri, 1 Dec 2023 16:17:44 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     Roberto Sassu <roberto.sassu@...weicloud.com>,
        Paul Moore <paul@...l-moore.com>, viro@...iv.linux.org.uk,
        brauner@...nel.org, chuck.lever@...cle.com, jlayton@...nel.org,
        neilb@...e.de, kolga@...app.com, Dai.Ngo@...cle.com,
        tom@...pey.com, jmorris@...ei.org, serge@...lyn.com,
        zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
        dhowells@...hat.com, jarkko@...nel.org,
        stephen.smalley.work@...il.com, eparis@...isplace.org,
        mic@...ikod.net, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
        selinux@...r.kernel.org, Roberto Sassu <roberto.sassu@...wei.com>,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed
 blob for integrity_iint_cache

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
>

Powered by blists - more mailing lists