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 >
