On Thu, 2024-06-20 at 13:13 -0400, Paul Moore wrote: > On Thu, Jun 20, 2024 at 1:06 PM Roberto Sassu > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > On Thu, 2024-06-20 at 12:51 -0400, Paul Moore wrote: > > > On Thu, Jun 20, 2024 at 12:31 PM Roberto Sassu > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote: > > > > > On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu > > > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote: > > > > > > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu > > > > > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote: > > > > > > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu > > > > > > > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > Making it a kernel subsystem would likely mean replicating what the LSM > > > > > > > > > > infrastructure is doing, inode (security) blob and being notified about > > > > > > > > > > file/directory changes. > > > > > > > > > > > > > > > > > > Just because the LSM framework can be used for something, perhaps it > > > > > > > > > even makes the implementation easier, it doesn't mean the framework > > > > > > > > > should be used for everything. > > > > > > > > > > > > > > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM. > > > > > > > > > > > > > > > > That makes it a clear target for the security subsystem, and as you > > > > > > > > suggested to start for IMA, if other kernel subsystems require them, we > > > > > > > > can make it as an independent subsystem. > > > > > > > > > > > > > > Have you discussed the file digest cache functionality with either the > > > > > > > IPE or BPF LSM maintainers? While digest_cache may support these > > > > > > > > > > > > Well, yes. I was in a discussion since long time ago with Deven and > > > > > > Fan. The digest_cache LSM is listed in the Use Case section of the IPE > > > > > > cover letter: > > > > > > > > > > > > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@xxxxxxxxxxxxxxxxxxx/ > > > > > > > > > > I would hope to see more than one sentence casually mentioning that > > > > > there might be some integration in the future. > > > > > > > > Sure, I can work more with Fan to do a proper integration. > > > > > > That seems like a good pre-requisite for turning digest_cache into a > > > general purpose subsystem. > > > > > > > > > I also developed an IPE module back in the DIGLIM days: > > > > > > > > > > > > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@xxxxxxxxxx/ > > > > > > > > > > That looks like more of an fs-verity integration to me. Yes, of > > > > > course there would be IPE changes to accept a signature/digest from a > > > > > digest cache, but that should be minor. > > > > > > > > True, but IPE will also benefit from not needing to specify every > > > > digest in the policy. > > > > > > Sure, but that isn't really that important from a code integration > > > perspective, that's an admin policy issue. I expect there would be > > > much more integration work with fs-verity than with IPE, and I think > > > the fs-verity related work might be a challenge. > > > > Uhm, not sure what you mean, but I don't plan to touch fsverity. There > > was already work to get the fsverity digest. All I would need to do > > from my side is to request a digest cache for the inode being verified > > by IPE and to query the fsverity digest. > > So your proposed file digest cache wouldn't be used as a replacement > for the fs-verity digest? Hmm. I'll leave this up to you and Fan > (current IPE maintainer), but I'm not sure how much value this would > have for IPE, especially since I believe IPE's fs-verity support is > mostly around fs-verity signatures. The digest_cache (LSM) would store fsverity digests in the hash table. At the moment, there is no available source for those, but they could be included in RPM headers like regular digests. IPE will compare the digest from fsverity with the digest queried on the digest cache. Roberto > > Of course IPE should also capture kernel reads and verify the file > > containing the reference digests, used to build the digest cache. > > > > > > Also, the design choice of attaching the digest cache to the inode > > > > helps LSMs like IPE that don't have a per inode cache on their own. > > > > Sure, IPE would have to do a digest lookup every time, but at least on > > > > an already populated hash table. > > > > > > Just because you need to attach some state to an inode does not mean a > > > file digest cache must be a LSM. It could be integrated into the VFS > > > or it could be a separate subsystem; either way it could provide an > > > API (either through well defined data structures or functions) that > > > could be used by various LSMs and filesystems that provide integrity > > > protection. > > > > Given that IMA solved the same problem after 15 years, when it became > > an LSM, I'm not super optimistic on that. But if VFS people or other > > subsystem maintainers would be open for such alternative, I can give it > > a try. > > I think you should, because I'm not currently supportive of > digest_cache as a standalone LSM. >
