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. > 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. > As for eBPF, I just need to make the digest_cache LSM API callable by > eBPF programs, very likely not requiring any change on the eBPF > infrastructure itself. That's great, but it would be good to hear from KP and any other BPF LSM devs that this would be desirable. I still believe that this is something that should live as a service outside of the LSM. -- paul-moore.com
