Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <04d878d4b2441bb8a579a4191d8edc936c5a794a.camel@linux.ibm.com>
Subject: Re: [PATCH v3 0/9] bpf-lsm: Extend interoperability with IMA
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     KP Singh <kpsingh@kernel.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Roberto Sassu <roberto.sassu@huawei.com>, shuah@kernel.org,
        ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
        yhs@fb.com, revest@chromium.org, gregkh@linuxfoundation.org,
        linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        Florent Revest <revest@google.com>,
        Kees Cook <keescook@chromium.org>
Date:   Thu, 03 Mar 2022 11:29:57 -0500
In-Reply-To: <CACYkzJ4fmJ4XtC6gx6k_Gjq0n5vjSJyq=L--H-Eho072HJoywA@mail.gmail.com>
References: <20220302111404.193900-1-roberto.sassu@huawei.com>
         <20220302222056.73dzw5lnapvfurxg@ast-mbp.dhcp.thefacebook.com>
         <fe1d17e7e7d4b5e4cdeb9f96f5771ded23b7c8f0.camel@linux.ibm.com>
         <CACYkzJ4fmJ4XtC6gx6k_Gjq0n5vjSJyq=L--H-Eho072HJoywA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Precedence: bulk

On Thu, 2022-03-03 at 17:17 +0100, KP Singh wrote:
> On Thu, Mar 3, 2022 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > [Cc'ing Florent, Kees]
> >
> > Hi Alexei,
> >
> > On Wed, 2022-03-02 at 14:20 -0800, Alexei Starovoitov wrote:
> > > On Wed, Mar 02, 2022 at 12:13:55PM +0100, Roberto Sassu wrote:
> > > > Extend the interoperability with IMA, to give wider flexibility for the
> > > > implementation of integrity-focused LSMs based on eBPF.
> > > >
> > > > Patch 1 fixes some style issues.
> > > >
> > > > Patches 2-6 give the ability to eBPF-based LSMs to take advantage of the
> > > > measurement capability of IMA without needing to setup a policy in IMA
> > > > (those LSMs might implement the policy capability themselves).
> > > >
> > > > Patches 7-9 allow eBPF-based LSMs to evaluate files read by the kernel.
> > > >
> > > > Changelog
> > > >
> > > > v2:
> > > > - Add better description to patch 1 (suggested by Shuah)
> > > > - Recalculate digest if it is not fresh (when IMA_COLLECTED flag not set)
> > > > - Move declaration of bpf_ima_file_hash() at the end (suggested by
> > > >   Yonghong)
> > > > - Add tests to check if the digest has been recalculated
> > > > - Add deny test for bpf_kernel_read_file()
> > > > - Add description to tests
> > > >
> > > > v1:
> > > > - Modify ima_file_hash() only and allow the usage of the function with the
> > > >   modified behavior by eBPF-based LSMs through the new function
> > > >   bpf_ima_file_hash() (suggested by Mimi)
> > > > - Make bpf_lsm_kernel_read_file() sleepable so that bpf_ima_inode_hash()
> > > >   and bpf_ima_file_hash() can be called inside the implementation of
> > > >   eBPF-based LSMs for this hook
> > > >
> > > > Roberto Sassu (9):
> > > >   ima: Fix documentation-related warnings in ima_main.c
> > > >   ima: Always return a file measurement in ima_file_hash()
> > > >   bpf-lsm: Introduce new helper bpf_ima_file_hash()
> > > >   selftests/bpf: Move sample generation code to ima_test_common()
> > > >   selftests/bpf: Add test for bpf_ima_file_hash()
> > > >   selftests/bpf: Check if the digest is refreshed after a file write
> > > >   bpf-lsm: Make bpf_lsm_kernel_read_file() as sleepable
> > > >   selftests/bpf: Add test for bpf_lsm_kernel_read_file()
> > > >   selftests/bpf: Check that bpf_kernel_read_file() denies reading IMA
> > > >     policy
> > >
> > > We have to land this set through bpf-next.
> > > Please get the Acks for patches 1 and 2, so we can proceed.
> >
> 
> Hi Mimi,
> 
> > Each year in the LSS integrity status update talk, I've mentioned the
> > eBPF integrity gaps.  I finally reached out to KP, Florent Revest, Kees
> 
> Thanks for bringing this up and it's very timely because we have been
> having discussion around eBPF program signing and delineating that
> from eBPF program integrity use-cases.
> 
> My plan is to travel to LSS (travel and visa permitting) and we can discuss
> it more there.
> 
> If you prefer we can also discuss it before in one of the BPF office hours:
> 
> https://docs.google.com/spreadsheets/d/1LfrDXZ9-fdhvPEp_LHkxAMYyxxpwBXjywWa0AejEveU/edit#gid=0

Sounds good.

> 
> > and others, letting them know that I'm concerned about the eBPF module
> > integrity gaps.  True there is a difference between signing the eBPF
> > source modules versus the eBPF generated output, but IMA could at least
> > verify the integrity of the source eBPF modules making sure they are
> > measured, the module hash audited, and are properly signed.
> >
> > Before expanding the ima_file_hash() or ima_inode_hash() usage, I'd
> > appreciate someone adding the IMA support to measure, appraise, and
> > audit eBPF modules.  I realize that closing the eBPF integrity gaps is
> > orthogonal to this patch set, but this patch set is not only extending
> 
> This really is orthogonal and IMHO it does not seem rational to block this
> patchset on it.
> 
> > the ima_file_hash()/ima_inode_hash() usage, but will be used to
> > circumvent IMA.  As per usual, IMA is policy based, allowing those
> 
> I don't think they are being used to circumvent IMA but for totally
> different use-cases (e.g. as a data point for detecting attacks).
> 
> 
> > interested in eBPF module integrity to define IMA policy rules.

That might be true for your usecase, but not Roberto's.  From the cover
letter above, Roberto was honest in saying:

Patches 2-6 give the ability to eBPF-based LSMs to take advantage of
the measurement capability of IMA without needing to setup a policy in
IMA (those LSMs might implement the policy capability themselves).

-- 
thanks,

Mimi