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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> > > > > > > > > > > > > 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
