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.
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.
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);
:-)
Have a good weekend.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
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
>