On Wed, 2024-11-27 at 11:53 -0800, Luis Chamberlain wrote:
On Wed, Nov 27, 2024 at 10:51:11AM +0100, Roberto Sassu wrote:
For eBPF programs we are also in a need for a better way to measure/appraise them.
I am confused now, I was under the impression this "Integrity Digest Cache" is just a special thing for LSMs, and so I was under the impression that kernel_read_file() lsm hook already would take care of eBPF programs.
Yes, the problem is that eBPF programs are transformed in user space before they are sent to the kernel:
https://lwn.net/Articles/977394/
The Integrity Digest Cache can be used for the measurement/appraisal of the initial eBPF ELF file, when they are accessed from the filesystem, but the resulting blob sent to the kernel will be different.
Now, I'm trying to follow you on the additional kernel_read_file() calls. I agree with you, if a parser tries to open again the file that is being verified it would cause a deadlock in IMA (since the inode mutex is already locked for verifying the original file).
Just document this on the parser as a requirement.
Ok, will do.
Supporting kernel modules opened the road for new deadlocks, since one can ask a digest list to verify a kernel module, but that digest list requires the same kernel module. That is why the in-kernel mechanism is 100% reliable,
Are users of this infrastructure really in need of modules for these parsers?
I planned to postpone this to later, and introduced two parsers built- in (TLV and RPM). However, due to Linus's concern regarding the RPM parser, I moved it out in a kernel module.
OK this should be part of the commit log, ie that it is not desirable to have an rpm parser in-kernel for some users.
I understand. Will add in the commit log.
Just to clarify, we are not talking about the full blown librpm in the kernel, but a 243 LOC that I rewrote to obtain only the information I need. I also formally verified it with pseudo/totally random data with Frama-C:
https://github.com/robertosassu/rpm-formal/blob/main/validate_rpm.c
Thanks
Roberto