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(-)
--
2.32.0
__ima_inode_hash() checks if a digest has been already calculated by
looking for the integrity_iint_cache structure associated to the passed
inode.
Users of ima_file_hash() (e.g. eBPF) might be interested in obtaining the
information without having to setup an IMA policy so that the digest is
always available at the time they call this function.
Call ima_collect_measurement() in __ima_inode_hash(), if the file
descriptor is available (passed by ima_file_hash()), and store the file
measurement in a temporary integrity_iint_cache structure.
This change does not cause memory usage increase, due to using the
temporary integrity_iint_cache structure, and due to freeing the
ima_digest_data structure inside integrity_iint_cache before exiting from
__ima_inode_hash().
For compatibility reasons, the behavior of ima_inode_hash() remains
unchanged.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/integrity/ima/ima_main.c | 36 +++++++++++++++++++++----------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 946ba8a12eab..3562a212a5ba 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -520,15 +520,27 @@ int ima_file_check(struct file *file, int mask)
}
EXPORT_SYMBOL_GPL(ima_file_check);
-static int __ima_inode_hash(struct inode *inode, char *buf, size_t buf_size)
+static int __ima_inode_hash(struct inode *inode, struct file *file, char *buf,
+ size_t buf_size)
{
- struct integrity_iint_cache *iint;
- int hash_algo;
+ struct integrity_iint_cache *iint = NULL, tmp_iint;
+ int rc, hash_algo;
- if (!ima_policy_flag)
- return -EOPNOTSUPP;
+ if (ima_policy_flag)
+ iint = integrity_iint_find(inode);
+
+ if (!iint && file) {
+ memset(&tmp_iint, 0, sizeof(tmp_iint));
+ tmp_iint.inode = inode;
+
+ rc = ima_collect_measurement(&tmp_iint, file, NULL, 0,
+ ima_hash_algo, NULL);
+ if (rc < 0)
+ return -EOPNOTSUPP;
+
+ iint = &tmp_iint;
+ }
- iint = integrity_iint_find(inode);
if (!iint)
return -EOPNOTSUPP;
@@ -552,12 +564,14 @@ static int __ima_inode_hash(struct inode *inode, char *buf, size_t buf_size)
hash_algo = iint->ima_hash->algo;
mutex_unlock(&iint->mutex);
+ if (iint == &tmp_iint)
+ kfree(iint->ima_hash);
+
return hash_algo;
}
/**
- * ima_file_hash - return the stored measurement if a file has been hashed and
- * is in the iint cache.
+ * ima_file_hash - return a measurement of the file
* @file: pointer to the file
* @buf: buffer in which to store the hash
* @buf_size: length of the buffer
@@ -570,7 +584,7 @@ static int __ima_inode_hash(struct inode *inode, char *buf, size_t buf_size)
* The file hash returned is based on the entire file, including the appended
* signature.
*
- * If IMA is disabled or if no measurement is available, return -EOPNOTSUPP.
+ * If the measurement cannot be performed, return -EOPNOTSUPP.
* If the parameters are incorrect, return -EINVAL.
*/
int ima_file_hash(struct file *file, char *buf, size_t buf_size)
@@ -578,7 +592,7 @@ int ima_file_hash(struct file *file, char *buf, size_t buf_size)
if (!file)
return -EINVAL;
- return __ima_inode_hash(file_inode(file), buf, buf_size);
+ return __ima_inode_hash(file_inode(file), file, buf, buf_size);
}
EXPORT_SYMBOL_GPL(ima_file_hash);
@@ -605,7 +619,7 @@ int ima_inode_hash(struct inode *inode, char *buf, size_t buf_size)
if (!inode)
return -EINVAL;
- return __ima_inode_hash(inode, buf, buf_size);
+ return __ima_inode_hash(inode, NULL, buf, buf_size);
}
EXPORT_SYMBOL_GPL(ima_inode_hash);
--
2.32.0
Fix some warnings in ima_main.c, displayed with W=n make argument.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/integrity/ima/ima_main.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 8c6e4514d494..946ba8a12eab 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -418,6 +418,7 @@ int ima_file_mmap(struct file *file, unsigned long prot)
/**
* ima_file_mprotect - based on policy, limit mprotect change
+ * @vma: vm_area_struct protection is set to
* @prot: contains the protection that will be applied by the kernel.
*
* Files can be mmap'ed read/write and later changed to execute to circumvent
@@ -610,8 +611,8 @@ EXPORT_SYMBOL_GPL(ima_inode_hash);
/**
* ima_post_create_tmpfile - mark newly created tmpfile as new
- * @mnt_userns: user namespace of the mount the inode was found from
- * @file : newly created tmpfile
+ * @mnt_userns: user namespace of the mount the inode was found from
+ * @inode: inode of the newly created tmpfile
*
* No measuring, appraising or auditing of newly created tmpfiles is needed.
* Skip calling process_measurement(), but indicate which newly, created
@@ -643,7 +644,7 @@ void ima_post_create_tmpfile(struct user_namespace *mnt_userns,
/**
* ima_post_path_mknod - mark as a new inode
- * @mnt_userns: user namespace of the mount the inode was found from
+ * @mnt_userns: user namespace of the mount the inode was found from
* @dentry: newly created dentry
*
* Mark files created via the mknodat syscall as new, so that the
@@ -814,8 +815,8 @@ int ima_load_data(enum kernel_load_data_id id, bool contents)
* ima_post_load_data - appraise decision based on policy
* @buf: pointer to in memory file contents
* @size: size of in memory file contents
- * @id: kernel load data caller identifier
- * @description: @id-specific description of contents
+ * @load_id: kernel load data caller identifier
+ * @description: @load_id-specific description of contents
*
* Measure/appraise/audit in memory buffer based on policy. Policy rules
* are written in terms of a policy identifier.
--
2.32.0
> From: Shuah Khan [mailto:[email protected]]
> Sent: Tuesday, February 15, 2022 4:46 PM
> On 2/15/22 5:40 AM, Roberto Sassu wrote:
> > Fix some warnings in ima_main.c, displayed with W=n make argument.
> >
>
> Thank you for fixing these. Doc builds are full of them and few less
> is welcome.
>
> Adding the warns or summary of them to change log will be good.
Hi Shuah
ok, I will add a brief description of what I fixed in the next version
of the patch set.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
> > Signed-off-by: Roberto Sassu <[email protected]>
> > ---
> > security/integrity/ima/ima_main.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/security/integrity/ima/ima_main.c
> b/security/integrity/ima/ima_main.c
> > index 8c6e4514d494..946ba8a12eab 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -418,6 +418,7 @@ int ima_file_mmap(struct file *file, unsigned long prot)
> >
> > /**
> > * ima_file_mprotect - based on policy, limit mprotect change
> > + * @vma: vm_area_struct protection is set to
> > * @prot: contains the protection that will be applied by the kernel.
> > *
>
>
> Reviewed-by: Shuah Khan <[email protected]>
>
> thanks,
> -- Shuah
On 2/15/22 5:40 AM, Roberto Sassu wrote:
> Fix some warnings in ima_main.c, displayed with W=n make argument.
>
Thank you for fixing these. Doc builds are full of them and few less
is welcome.
Adding the warns or summary of them to change log will be good.
> Signed-off-by: Roberto Sassu <[email protected]>
> ---
> security/integrity/ima/ima_main.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 8c6e4514d494..946ba8a12eab 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -418,6 +418,7 @@ int ima_file_mmap(struct file *file, unsigned long prot)
>
> /**
> * ima_file_mprotect - based on policy, limit mprotect change
> + * @vma: vm_area_struct protection is set to
> * @prot: contains the protection that will be applied by the kernel.
> *
Reviewed-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
> From: Roberto Sassu
> Sent: Tuesday, February 15, 2022 1:41 PM
> 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.
Hi everyone
I published the new DIGLIM eBPF, that takes advantage of
the new features introduced with this patch set:
https://github.com/robertosassu/diglim-ebpf
the eBPF program is in ebpf/diglim_kern.c
If you could have a look and give me some comments
or suggestions, it would be very appreciated!
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
> 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(-)
>
> --
> 2.32.0
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
On Fri, 2022-02-25 at 08:41 +0000, Roberto Sassu wrote:
> > From: Mimi Zohar [mailto:[email protected]]
> > 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
> From: Mimi Zohar [mailto:[email protected]]
> 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, 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:[email protected]]
> > > 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:[email protected]]
> > > > 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: Roberto Sassu
> Sent: Monday, February 28, 2022 10:08 AM
> > From: Mimi Zohar [mailto:[email protected]]
> > Sent: Friday, February 25, 2022 8:11 PM
> > On Fri, 2022-02-25 at 08:41 +0000, Roberto Sassu wrote:
> > > > From: Mimi Zohar [mailto:[email protected]]
> > > > 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
> From: Mimi Zohar [mailto:[email protected]]
> Sent: Friday, February 25, 2022 8:11 PM
> On Fri, 2022-02-25 at 08:41 +0000, Roberto Sassu wrote:
> > > From: Mimi Zohar [mailto:[email protected]]
> > > 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
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:[email protected]]
> > > Sent: Friday, February 25, 2022 8:11 PM
> > > On Fri, 2022-02-25 at 08:41 +0000, Roberto Sassu wrote:
> > > > > From: Mimi Zohar [mailto:[email protected]]
> > > > > 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