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: Thu, 20 Jun 2024 11:12:11 +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 14:43 -0400, Paul Moore wrote:
> On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu
> <roberto.sassu@...weicloud.com> wrote:
> > 
> > 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.

Starting from IMA means that we are mixing two different things in the
inode security blob, and I'm not sure that it is more straightforward
than making the digest_cache LSM require the space it needs and be
notified about security events.

Thanks

Roberto