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