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
