Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <223d9eedc03f68cfa4f1624c4673e844e29da7d5.camel@linux.ibm.com>
Subject: Re: [PATCH v2 0/6] bpf-lsm: Extend interoperability with IMA
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Roberto Sassu <roberto.sassu@huawei.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "shuah@kernel.org" <shuah@kernel.org>,
        "ast@kernel.org" <ast@kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "andrii@kernel.org" <andrii@kernel.org>,
        "kpsingh@kernel.org" <kpsingh@kernel.org>,
        "revest@chromium.org" <revest@chromium.org>
Cc:     "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Date:   Fri, 25 Feb 2022 14:11:04 -0500
In-Reply-To: <5117c79227ce4b9d97e193fd8fb59ba2@huawei.com>
References: <20220215124042.186506-1-roberto.sassu@huawei.com>
         <408a96085814b2578486b2859e63ff906f5e5876.camel@linux.ibm.com>
         <5117c79227ce4b9d97e193fd8fb59ba2@huawei.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Precedence: bulk

On Fri, 2022-02-25 at 08:41 +0000, Roberto Sassu wrote:
> > From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> > Sent: Friday, February 25, 2022 1:22 AM
> > Hi Roberto,
> > 
> > On Tue, 2022-02-15 at 13:40 +0100, Roberto Sassu wrote:
> > > Extend the interoperability with IMA, to give wider flexibility for the
> > > implementation of integrity-focused LSMs based on eBPF.
> > 
> > I've previously requested adding eBPF module measurements and signature
> > verification support in IMA.  There seemed to be some interest, but
> > nothing has been posted.
> 
> Hi Mimi
> 
> for my use case, DIGLIM eBPF, IMA integrity verification is
> needed until the binary carrying the eBPF program is executed
> as the init process. I've been thinking to use an appended
> signature to overcome the limitation of lack of xattrs in the
> initial ram disk.

I would still like to see xattrs supported in the initial ram disk. 
Assuming you're still interested in pursuing it, someone would need to
review and upstream it.  Greg?

> 
> At that point, the LSM is attached and it can enforce an
> execution policy, allowing or denying execution and mmap
> of files depending on the digest lists (reference values) read
> by the user space side.
> 
> After the LSM is attached, IMA's job would be just to calculate
> the file digests (currently, I'm using an audit policy to ensure
> that the digest is available when the eBPF program calls
> bpf_ima_inode_hash()).
> 
> The main benefit of this patch set is that the audit policy
> would not be required and digests are calculated only when
> requested by the eBPF program.

Roberto, there's an existing eBPF integrity gap that needs to be
closed, perhaps not for your usecase, but in general.  Is that
something you can look into?

thanks,

Mimi