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

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

quoted

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.

That seems like a good pre-requisite for turning digest_cache into a
general purpose subsystem.

quoted

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.

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