Received-SPF: pass (google.com: domain of linux-nfs+bounces-252-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Fri, 1 Dec 2023 17:53:32 -0600
From: "Dr. Greg" <greg@enjellic.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Roberto Sassu <roberto.sassu@huaweicloud.com>,
        Paul Moore <paul@paul-moore.com>, viro@zeniv.linux.org.uk,
        brauner@kernel.org, chuck.lever@oracle.com, jlayton@kernel.org,
        neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com, tom@talpey.com,
        jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com,
        dmitry.kasatkin@gmail.com, dhowells@redhat.com, jarkko@kernel.org,
        stephen.smalley.work@gmail.com, eparis@parisplace.org, mic@digikod.net,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org,
        linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
        selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed blob for integrity_iint_cache
Message-ID: <20231201235332.GA19345@wind.enjellic.com>
Reply-To: "Dr. Greg" <greg@enjellic.com>
References: <20231107134012.682009-24-roberto.sassu@huaweicloud.com> <17befa132379d37977fc854a8af25f6d.paul@paul-moore.com> <2084adba3c27a606cbc5ed7b3214f61427a829dd.camel@huaweicloud.com> <CAHC9VhTTKac1o=RnQadu2xqdeKH8C_F+Wh4sY=HkGbCArwc8JQ@mail.gmail.com> <b6c51351be3913be197492469a13980ab379e412.camel@huaweicloud.com> <CAHC9VhSAryQSeFy0ZMexOiwBG-YdVGRzvh58=heH916DftcmWA@mail.gmail.com> <90eb8e9d-c63e-42d6-b951-f856f31590db@huaweicloud.com> <20231201010549.GA8923@wind.enjellic.com> <660e8516-ec1b-41b4-9e04-2b9fabbe59ca@schaufler-ca.com>
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <660e8516-ec1b-41b4-9e04-2b9fabbe59ca@schaufler-ca.com>
User-Agent: Mutt/1.4i

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