Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Message-ID: <2637d5294d4a7ae871f1b758f5a30234836e2463.camel@huaweicloud.com>
Subject: Re: [PATCH v15 00/11] LSM: Three basic syscalls
From:   Roberto Sassu <roberto.sassu@huaweicloud.com>
To:     Paul Moore <paul@paul-moore.com>, Mimi Zohar <zohar@linux.ibm.com>
Cc:     Casey Schaufler <casey@schaufler-ca.com>,
        linux-security-module@vger.kernel.org, jmorris@namei.org,
        serge@hallyn.com, keescook@chromium.org,
        john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
        stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, mic@digikod.net,
        linux-integrity@vger.kernel.org
Date:   Wed, 18 Oct 2023 11:31:17 +0200
In-Reply-To: <6f33144c850c40e9438a6de2cf3004e223508755.camel@huaweicloud.com>
References: <20230912205658.3432-1-casey.ref@schaufler-ca.com>
         <20230912205658.3432-1-casey@schaufler-ca.com>
         <CAHC9VhRcbp3iWQwL7FTUrcU1C3OsZ413Nbq+17oTwW7hZ7XvBw@mail.gmail.com>
         <CAHC9VhSqY5+DR-jXprrftb1=CzDvhTh0Ep66A16RMd4L7W7TYw@mail.gmail.com>
         <ae39864947debbc7c460db478b8abe1c147b7d5c.camel@huaweicloud.com>
         <CAHC9VhRQ7xpeSX7b3VZfzQ15noJ8mgauNMuHWo_n3hMgsYMAfQ@mail.gmail.com>
         <468436cf766732a3cfc55d07ad119a6ccdc815c1.camel@huaweicloud.com>
         <CAHC9VhTjHT-DGKu0=cZPVb=+kMwmbPdr8HiVWJq-yzaDiYk_SA@mail.gmail.com>
         <6f33144c850c40e9438a6de2cf3004e223508755.camel@huaweicloud.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-10-17 at 18:07 +0200, Roberto Sassu wrote:
> On Tue, 2023-10-17 at 11:58 -0400, Paul Moore wrote:
> > On Tue, Oct 17, 2023 at 3:01 AM Roberto Sassu
> > <roberto.sassu@huaweicloud.com> wrote:
> > > On Mon, 2023-10-16 at 11:06 -0400, Paul Moore wrote:
> > > > On Mon, Oct 16, 2023 at 8:05 AM Roberto Sassu
> > > > <roberto.sassu@huaweicloud.com> wrote:
> > > > > 
> > > > > Sorry, I just noticed LSM_ID_IMA. Since we have the 'integrity' LSM, I
> > > > > think it should be LSM_ID_INTEGRITY.
> > > > > 
> > > > > Mimi, all, do you agree? If yes, I send a patch shortly.
> > > > 
> > > > I believe LSM_ID_IMA is the better option, despite "integrity" already
> > > > being present in Kconfig and possibly other areas.  "IMA" is a
> > > > specific thing/LSM whereas "integrity" is a property, principle, or
> > > > quality.  Especially as we move forward with promoting IMA as a full
> > > > and proper LSM, we should work towards referring to it as "IMA" and
> > > > not "integrity".
> > > > 
> > > > If anything we should be working to support "IMA" in places where we
> > > > currently have "integrity" so that we can eventually deprecate
> > > > "integrity".
> > > 
> > > Hi Paul
> > > 
> > > I fully understand your argument. However, 'integrity' has been the
> > > word to identify the integrity subsystem since long time ago.
> > > 
> > > Reducing the scope to 'ima' would create some confusion since, while
> > > 'ima' is associated to integrity, it would not encompass EVM.
> > 
> > Using LSM_ID_IMA to reference the combination of IMA+EVM makes much
> > more sense to me than using LSM_ID_INTEGRITY, especially as we move
> > towards promoting IMA+EVM and adopting LSM hooks for integrity
> > verification, opening the door for other integrity focused LSMs.
> 
> + Mimi, linux-integrity
> 
> Ok, just to understand before posting v4, the code looks like this:

I worked on a new proposal. Let me know what you think. It is available
here:

https://github.com/robertosassu/linux/tree/ima-evm-lsms-v4-devel-v6


I made IMA and EVM as standalone LSMs and removed 'integrity'. They
maintain the same properties of 'integrity', i.e. they are the last and
always enabled.

During initialization, 'ima' and 'evm' call integrity_iintcache_init(),
so that they can get integrity metadata. I added a check to ensure that
this function is called only once. I also added the lsmid parameter so
that the integrity-specific functions are added under the LSM ID of the
caller.

I added a new LSM ID for EVM, does not look good that IMA and EVM are
represented by LSM_ID_IMA.

Finally, I had to drop the patch to remove the rbtree, because without
the 'integrity' LSM, space in the security blob cannot be reserved.
Since integrity metadata is shared, it cannot be reserved by 'ima' or
'evm'.

An intermediate solution would be to keep the 'integrity' LSM just to
reserve space in the security blob. Or, we remove the rbtree if/when
IMA and EVM use disjoint integrity metadata.

Roberto