[v2,0/6] bpf-lsm: Extend interoperability with IMA

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-4 gives 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 5-6 allows eBPF-based LSMs to evaluate files read by the kernel.

Changelog

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 (6):
  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: Add test for bpf_ima_file_hash()
  bpf-lsm: Make bpf_lsm_kernel_read_file() as sleepable
  selftests/bpf: Add test for bpf_lsm_kernel_read_file()

 include/uapi/linux/bpf.h                      | 11 +++++
 kernel/bpf/bpf_lsm.c                          | 21 +++++++++
 security/integrity/ima/ima_main.c             | 47 ++++++++++++-------
 tools/include/uapi/linux/bpf.h                | 11 +++++
 tools/testing/selftests/bpf/ima_setup.sh      |  2 +
 .../selftests/bpf/prog_tests/test_ima.c       | 30 ++++++++++--
 tools/testing/selftests/bpf/progs/ima.c       | 34 ++++++++++++--
 7 files changed, 132 insertions(+), 24 deletions(-)

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.

thanks,

Mimi

> 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.

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.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

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

On Fri, Feb 25, 2022 at 02:11:04PM -0500, Mimi Zohar wrote:
> 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?

Me?  How about the filesystem maintainers and developers?  :)

There's a reason we never added xattrs support to ram disks, but I can't
remember why...

thanks,

gre gk-h

On Sat, 2022-02-26 at 09:07 +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 25, 2022 at 02:11:04PM -0500, Mimi Zohar wrote:
> > 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?
> 
> Me?  How about the filesystem maintainers and developers?  :)
> 
> There's a reason we never added xattrs support to ram disks, but I can't
> remember why...

CPIO 'newc' format doesn't support xattrs.

thanks,

Mimi

> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Friday, February 25, 2022 8:11 PM
> 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?

I could revise this work. However, since appended signatures
would work too, I would propose to extend this appraisal
mode to executables, if it is fine for you.

> > 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?

It could be possible I look into it.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

> From: Roberto Sassu
> Sent: Monday, February 28, 2022 10:08 AM
> > From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> > Sent: Friday, February 25, 2022 8:11 PM
> > 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?
> 
> I could revise this work. However, since appended signatures
> would work too, I would propose to extend this appraisal
> mode to executables, if it is fine for you.

Regarding this patch set, I kindly ask if you could accept it,
after I make the changes suggested.

The changes are simple, and waiting another kernel cycle
seems too long.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

> > > 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?
> 
> It could be possible I look into it.
> 
> Roberto
> 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Zhong Ronghua

On Mon, Feb 28, 2022 at 09:12:35AM +0000, Roberto Sassu wrote:
> > From: Roberto Sassu
> > Sent: Monday, February 28, 2022 10:08 AM
> > > From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> > > Sent: Friday, February 25, 2022 8:11 PM
> > > 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?
> > 
> > I could revise this work. However, since appended signatures
> > would work too, I would propose to extend this appraisal
> > mode to executables, if it is fine for you.
> 
> Regarding this patch set, I kindly ask if you could accept it,
> after I make the changes suggested.
> 
> The changes are simple, and waiting another kernel cycle
> seems too long.

3 months is not a long time, get it right first, there is no deadline
here.

thanks,

greg k-h