On Tue, Nov 26, 2024 at 11:25:07AM +0100, Roberto Sassu wrote:
On Mon, 2024-11-25 at 15:53 -0800, Luis Chamberlain wrote:
Firmware, eBPF programs and so on are supposed
Keyword: "supposed".
As far as the LSM infrastructure is concerned, I'm not adding new LSM hooks, nor extending/modifying the existing ones. The operations the Integrity Digest Cache is doing match the usage expectation by LSM (net denying access, as discussed with Paul Moore).
If modules are the only proven exception to your security model you are not making the case for it clearly.
The Integrity Digest Cache is supposed to be used as a supporting tool for other LSMs to do regular access control based on file data and metadata integrity. In doing that, it still needs the LSM infrastructure to notify about filesystem changes, and to store additional information in the inode and file descriptor security blobs.
The kernel_post_read_file LSM hook should be implemented by another LSM to verify the integrity of a digest list, when the Integrity Digest Cache calls kernel_read_file() to read that digest list.
If LSM folks *do* agree that this work is *suplementing* LSMS then sure, it was not clear from the commit logs. But then you need to ensure the parsers are special snowflakes which won't ever incur other additional kernel_read_file() calls.
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?
Luis