On Wed, 2024-06-19 at 12:34 -0400, Paul Moore wrote:
On Wed, Jun 19, 2024 at 11:55 AM Roberto Sassu roberto.sassu@huaweicloud.com wrote:
On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote:
On Wed, Jun 19, 2024 at 3:59 AM Roberto Sassu roberto.sassu@huaweicloud.com wrote:
On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote:
On Mon, Apr 15, 2024 at 10:25 AM Roberto Sassu roberto.sassu@huaweicloud.com wrote:
From: Roberto Sassu roberto.sassu@huawei.com
Integrity detection and protection has long been a desirable feature, to reach a large user base and mitigate the risk of flaws in the software and attacks.
However, while solutions exist, they struggle to reach the large user base, due to requiring higher than desired constraints on performance, flexibility and configurability, that only security conscious people are willing to accept.
This is where the new digest_cache LSM comes into play, it offers additional support for new and existing integrity solutions, to make them faster and easier to deploy.
The full documentation with the motivation and the solution details can be found in patch 14.
The IMA integration patch set will be introduced separately. Also a PoC based on the current version of IPE can be provided.
I'm not sure we want to implement a cache as a LSM. I'm sure it would work, but historically LSMs have provided some form of access control, measurement, or other traditional security service. A digest cache, while potentially useful for a variety of security related applications, is not a security service by itself, it is simply a file digest storage mechanism.
Uhm, currently the digest_cache LSM is heavily based on the LSM infrastructure:
I understand that, but as I said previously, I don't believe that we want to support a LSM which exists solely to provide a file digest cache. LSMs should be based around the idea of some type of access control, security monitoring, etc.
Including a file digest cache in IMA, or implementing it as a standalone piece of kernel functionality, are still options. If you want to pursue this, I would suggest that including the digest cache as part of IMA would be the easier of the two options; if it proves to be generally useful outside of IMA, it can always be abstracted out to a general kernel module/subsystem.
Ok. I thought about IPE and eBPF as potential users. But if you think that adding as part of IMA would be easier, I could try to pursue that.
It isn't clear to me how this would interact with IPE and/or eBPF, but if you believe there is value there I would encourage you to work with those subsystem maintainers. If the consensus is that a general file digest cache is useful then you should pursue the digest cache as a kernel subsystem, just not a LSM.
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.
I guess I will go for the IMA route...
Roberto