On Thu, Mar 28, 2024 at 01:17:23PM -0700, Fan Wu wrote: > fsverity: consume fsverity built-in signatures via LSM hook Nothing is being "consumed" in this patch. I think you might mean something like "expose verified fsverity built-in signatures to LSMs". > 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 built-in > fsverity signatures while restricting kernel module loading to specified > hashes. No, this patch does not enable "restricting kernel module loading to specified hashes." That can be done without this patch. > The introduction of a security_inode_setintegrity() hook call within > fsverity's workflow ensures that the verified built-in signature of a file > is stored in the inode's LSM blobs. No, it doesn't. As I said on v15, this is not what IPE actually uses it for. Also, even if IPE did cache the built-in signature in i_security, the mere fact that it's cached would say nothing about what it's actually used for. > diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst > index 13e4b18e5dbb..e13cf10211c8 100644 > --- a/Documentation/filesystems/fsverity.rst > +++ b/Documentation/filesystems/fsverity.rst > @@ -86,6 +86,19 @@ authenticating fs-verity file hashes include: > signature in their "security.ima" extended attribute, as controlled > by the IMA policy. For more information, see the IMA documentation. > > +- Integrity Policy Enforcement (IPE). IPE supports enforcing access > + control decisions based on immutable security properties of files, > + including those protected by fs-verity's built-in signatures. > + "IPE policy" specifically allows for the authorization of fs-verity > + files using properties such as ``fsverity_digest`` for identifying > + files by their verity digest, and ``fsverity_signature`` to validate > + files signed with fs-verity's built-in signature mechanism. Maybe leave out the "such as" above, since fsverity_digest and fsverity_signature are all the IPE properties related to fs-verity. > + This integration enhances security by ensuring the integrity and > + authenticity of files on a per-file basis, leveraging fs-verity's > + robust protection capabilities in conjunction with IPE's policy-driven > + access control. This reads a bit like a marketing blurb and feels a bit out of place, especially when it comes right after the paragraph about IMA which didn't include a similar sentence even though the exact same sentence would apply to IMA too. Maybe just leave this sentence out. > @@ -457,7 +470,10 @@ Enabling this option adds the following: > On success, the ioctl persists the signature alongside the Merkle > tree. Then, any time the file is opened, the kernel verifies the > file's actual digest against this signature, using the certificates > - in the ".fs-verity" keyring. > + in the ".fs-verity" keyring. This verification happens as long as the > + file's signature exists, regardless of the state of the sysctl variable > + "fs.verity.require_signatures" described in the next item. The IPE LSM > + relies on this behavior to save verified signatures into LSM blobs. No, IPE doesn't do that. - Eric
