linux-kernel - Re: [PATCH v6 07/15] digest_cache: Allow registration of digest list parsers

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]

Message-ID: <Z0Ybvzy7ianR-Sx9@bombadil.infradead.org>
Date: Tue, 26 Nov 2024 11:04:31 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
	eric.snowberg@...cle.com, corbet@....net, petr.pavlu@...e.com,
	samitolvanen@...gle.com, da.gomez@...sung.com,
	akpm@...ux-foundation.org, paul@...l-moore.com, jmorris@...ei.org,
	serge@...lyn.com, shuah@...nel.org, mcoquelin.stm32@...il.com,
	alexandre.torgue@...s.st.com, linux-integrity@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-api@...r.kernel.org, linux-modules@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-kselftest@...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 v6 07/15] digest_cache: Allow registration of digest list
 parsers

On Tue, Nov 26, 2024 at 11:25:07AM +0100, Roberto Sassu wrote:
> On Mon, 2024-11-25 at 15:53 -0800, Luis Chamberlain wrote:
> 
> Firmware, eBPF programs and so on are supposed

Keyword: "supposed". 

> As far as the LSM infrastructure is concerned, I'm not adding new LSM
> hooks, nor extending/modifying the existing ones. The operations the
> Integrity Digest Cache is doing match the usage expectation by LSM (net
> denying access, as discussed with Paul Moore).

If modules are the only proven exception to your security model you are
not making the case for it clearly.

> The Integrity Digest Cache is supposed to be used as a supporting tool
> for other LSMs to do regular access control based on file data and
> metadata integrity. In doing that, it still needs the LSM
> infrastructure to notify about filesystem changes, and to store
> additional information in the inode and file descriptor security blobs.
> 
> The kernel_post_read_file LSM hook should be implemented by another LSM
> to verify the integrity of a digest list, when the Integrity Digest
> Cache calls kernel_read_file() to read that digest list.

If LSM folks *do* agree that this work is *suplementing* LSMS then sure,
it was not clear from the commit logs. But then you need to ensure the
parsers are special snowflakes which won't ever incur other additional
kernel_read_file() calls.

> Supporting kernel modules opened the road for new deadlocks, since one
> can ask a digest list to verify a kernel module, but that digest list
> requires the same kernel module. That is why the in-kernel mechanism is
> 100% reliable,

Are users of this infrastructure really in need of modules for these
parsers?

  Luis