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. > 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. -- paul-moore.com
