On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote:

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

quoted

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.

Sure, I can work more with Fan to do a proper integration.

quoted

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.

True, but IPE will also benefit from not needing to specify every
digest in the policy.

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.

quoted

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.

Yes, I would also like to know their opinion. They already support
getting a file digest from IMA. Adding support for the digest_cache LSM
is a nice complement, to make security decisions based on an
authenticated source of reference digests (signature verification was
not shown in the example).

I still believe that this is something that should live as a service
outside of the LSM.

It will not cost me too much to plug to IMA rather than the LSM
infrastructure, but I would rather prefer the second.

I'm not aware of equivalent facilities in the kernel that would make
the digest_cache LSM work in the same way, so making it as an
independent kernel subsystem seems a too big jump for me.

Roberto