On Fri, May 3, 2024 at 6:32 PM Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx> wrote: > > This patch enhances fsverity's capabilities to support both integrity and > authenticity protection by introducing the exposure of built-in > signatures through a new LSM hook. This functionality allows LSMs, > e.g. IPE, to enforce policies based on the authenticity and integrity of > files, specifically focusing on built-in fsverity signatures. It enables > a policy enforcement layer within LSMs for fsverity, offering granular > control over the usage of authenticity claims. For instance, a policy > could be established to permit the execution of all files with verified > built-in fsverity signatures while restricting kernel module loading > from specified fsverity files via fsverity digests. > > The introduction of a security_inode_setintegrity() hook call within > fsverity's workflow ensures that the verified built-in signature of a file > is exposed to LSMs. This enables LSMs to recognize and label fsverity files > that contain a verified built-in fsverity signature. This hook is invoked > subsequent to the fsverity_verify_signature() process, guaranteeing the > signature's verification against fsverity's keyring. This mechanism is > crucial for maintaining system security, as it operates in kernel space, > effectively thwarting attempts by malicious binaries to bypass user space > stack interactions. > > The second to last commit in this patch set will add a link to the IPE > documentation in fsverity.rst. > > Signed-off-by: Deven Bowers <deven.desai@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Fan Wu <wufan@xxxxxxxxxxxxxxxxxxx> Eric, are you okay with the fs-verity patches in v18? If so, it would be nice to get your ACK on this patch at the very least. While it looks like there may be a need for an additional respin to address some new/different feedback from the device-mapper folks, that shouldn't affect the fs-verity portions of the patchset. -- paul-moore.com
