On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu
[off-list ref] wrote:

On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote:

quoted

On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu
[off-list ref] wrote:

quoted

On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote:

quoted

On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu
[off-list ref] wrote:

quoted

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@linux.microsoft.com/ (local)

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@huawei.com/ (local)

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