linux-kernel - Re: [PATCH v4 00/14] security: digest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 19 Jun 2024 18:37:49 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Paul Moore <paul@...l-moore.com>
Cc: corbet@....net, jmorris@...ei.org, serge@...lyn.com, 
 akpm@...ux-foundation.org, shuah@...nel.org, mcoquelin.stm32@...il.com, 
 alexandre.torgue@...s.st.com, mic@...ikod.net, 
 linux-security-module@...r.kernel.org, linux-doc@...r.kernel.org, 
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
 bpf@...r.kernel.org, zohar@...ux.ibm.com, dmitry.kasatkin@...il.com, 
 linux-integrity@...r.kernel.org, wufan@...ux.microsoft.com,
 pbrobinson@...il.com,  zbyszek@...waw.pl, hch@....de, mjg59@...f.ucam.org,
 pmatilai@...hat.com,  jannh@...gle.com, dhowells@...hat.com,
 jikos@...nel.org, mkoutny@...e.com,  ppavlu@...e.com, petr.vorel@...il.com,
 mzerqung@...inter.de, kgold@...ux.ibm.com,  Roberto Sassu
 <roberto.sassu@...wei.com>
Subject: Re: [PATCH v4 00/14] security: digest_cache LSM

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@...weicloud.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@...weicloud.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@...weicloud.com> wrote:
> > > > > > 
> > > > > > From: Roberto Sassu <roberto.sassu@...wei.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