linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>,
	"petr.pavlu@suse.com" <petr.pavlu@suse.com>,
	"samitolvanen@google.com" <samitolvanen@google.com>,
	"da.gomez@samsung.com" <da.gomez@samsung.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"paul@paul-moore.com" <paul@paul-moore.com>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"mcoquelin.stm32@gmail.com" <mcoquelin.stm32@gmail.com>,
	"alexandre.torgue@foss.st.com" <alexandre.torgue@foss.st.com>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"wufan@linux.microsoft.com" <wufan@linux.microsoft.com>,
	"pbrobinson@gmail.com" <pbrobinson@gmail.com>,
	"zbyszek@in.waw.pl" <zbyszek@in.waw.pl>,
	"hch@lst.de" <hch@lst.de>,
	"mjg59@srcf.ucam.org" <mjg59@srcf.ucam.org>,
	"pmatilai@redhat.com" <pmatilai@redhat.com>,
	"jannh@google.com" <jannh@google.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"jikos@kernel.org" <jikos@kernel.org>,
	"mkoutny@suse.com" <mkoutny@suse.com>,
	"ppavlu@suse.com" <ppavlu@suse.com>,
	"petr.vorel@gmail.com" <petr.vorel@gmail.com>,
	"mzerqung@0pointer.de" <mzerqung@0pointer.de>,
	"kgold@linux.ibm.com" <kgold@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v6 00/15] integrity: Introduce the Integrity Digest Cache
Date: Tue, 3 Dec 2024 20:06:14 +0000	[thread overview]
Message-ID: <B135AC90-7CE5-4E51-90B1-9D82031668A8@oracle.com> (raw)
In-Reply-To: <17ef4f662e594c8431a00fe423507af4f6a82286.camel@huaweicloud.com>



> On Nov 26, 2024, at 3:41 AM, Roberto Sassu <roberto.sassu@huaweicloud.com> wrote:
> 
> On Tue, 2024-11-26 at 00:13 +0000, Eric Snowberg wrote:
>> 
>>> On Nov 19, 2024, at 3:49 AM, Roberto Sassu <roberto.sassu@huaweicloud.com> wrote:
>>> 
>>> From: Roberto Sassu <roberto.sassu@huawei.com>
>>> 
>>> The Integrity Digest Cache can also help IMA for appraisal. IMA can simply
>>> lookup the calculated digest of an accessed file in the list of digests
>>> extracted from package headers, after verifying the header signature. It is
>>> sufficient to verify only one signature for all files in the package, as
>>> opposed to verifying a signature for each file.
>> 
>> Is there a way to maintain integrity over time?  Today if a CVE is discovered 
>> in a signed program, the program hash can be added to the blacklist keyring. 
>> Later if IMA appraisal is used, the signature validation will fail just for that 
>> program.  With the Integrity Digest Cache, is there a way to do this?  
> 
> As far as I can see, the ima_check_blacklist() call is before
> ima_appraise_measurement(). If it fails, appraisal with the Integrity
> Digest Cache will not be done.


It is good the program hash would be checked beforehand and fail if it is 
contained on the list. 

The .ima keyring may contain many keys.  If one of the keys was later 
revoked and added to the .blacklist, wouldn't this be missed?  It would 
be caught during signature validation when the file is later appraised, but 
now this step isn't taking place.  Correct?

With IMA appraisal, it is easy to maintain authenticity but challenging to 
maintain integrity over time. In user-space there are constantly new CVEs.  
To maintain integrity over time, either keys need to be rotated in the .ima 
keyring or program hashes need to be frequently added to the .blacklist.   
If neither is done, for an end-user on a distro, IMA-appraisal basically 
guarantees authenticity.

While I understand the intent of the series is to increase performance, 
have you considered using this to give the end-user the ability to maintain 
integrity of their system?  What I mean is, instead of trying to import anything 
from an RPM, just have the end-user provide this information in some format 
to the Digest Cache.  User-space tools could be built to collect and format 
the data needed by the Digest Cache.  This data  may allow multiple versions 
of the same program.  The data would then be signed by one of the system 
kernel keys (either something in the secondary or machine keyring), to maintain 
a root of trust.  This would give the end-user the ability to have integrity however 
they see fit.  This leaves the distro to provide signed programs and the end-user 
the ability to decide what level of software they want to run on their system.  If 
something isn't in the Digest Cache, it gets bumped down to the traditional 
IMA-appraisal.  I think it would simplify the problem you are trying to solve, 
especially around the missing kernel PGP code required for all this to work, 
since it wouldn't be necessary.   With this approach, besides the performance 
gain, the end-user would gain the ability to maintain integrity that is enforced by
the kernel.


  reply	other threads:[~2024-12-03 20:07 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19 10:49 [PATCH v6 00/15] integrity: Introduce the Integrity Digest Cache Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 01/15] lib: Add TLV parser Roberto Sassu
2024-11-19 16:51   ` Randy Dunlap
2025-01-21 13:29   ` Thomas Weißschuh
2025-01-21 13:48     ` Roberto Sassu
2025-01-21 14:21       ` Thomas Weißschuh
2025-01-21 14:29         ` Roberto Sassu
2025-01-21 14:55     ` Roberto Sassu
2025-01-21 21:42       ` Thomas Weißschuh
2024-11-19 10:49 ` [PATCH v6 02/15] module: Introduce ksys_finit_module() Roberto Sassu
2024-11-19 12:14   ` Christoph Hellwig
2024-11-19 14:33     ` Roberto Sassu
2024-11-19 20:10     ` Luis Chamberlain
2024-11-20  9:16       ` Roberto Sassu
2024-11-20  9:18         ` Roberto Sassu
2024-11-25 23:40         ` Luis Chamberlain
2024-11-26  7:56           ` Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 03/15] integrity: Introduce the Integrity Digest Cache Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 04/15] digest_cache: Initialize digest caches Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 05/15] digest_cache: Add securityfs interface Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 06/15] digest_cache: Add hash tables and operations Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 07/15] digest_cache: Allow registration of digest list parsers Roberto Sassu
2024-11-19 16:46   ` Randy Dunlap
2024-11-19 16:48     ` Roberto Sassu
2024-11-25 23:53   ` Luis Chamberlain
2024-11-26 10:25     ` Roberto Sassu
2024-11-26 19:04       ` Luis Chamberlain
2024-11-27  9:51         ` Roberto Sassu
2024-11-27 19:53           ` Luis Chamberlain
2024-11-28  8:23             ` Roberto Sassu
2024-11-28 20:40               ` Luis Chamberlain
2024-11-29  8:30                 ` Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 08/15] digest_cache: Parse tlv digest lists Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 09/15] digest_cache: Populate the digest cache from a digest list Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 10/15] digest_cache: Add management of verification data Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 11/15] digest_cache: Add support for directories Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 12/15] digest cache: Prefetch digest lists if requested Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 13/15] digest_cache: Reset digest cache on file/directory change Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 14/15] selftests/digest_cache: Add selftests for the Integrity Digest Cache Roberto Sassu
2024-11-19 10:49 ` [PATCH v6 15/15] docs: Add documentation of " Roberto Sassu
2024-11-19 20:03 ` [PATCH v6 00/15] integrity: Introduce " Luis Chamberlain
2024-11-26  0:13 ` Eric Snowberg
2024-11-26 10:41   ` Roberto Sassu
2024-12-03 20:06     ` Eric Snowberg [this message]
2024-12-04 10:44       ` Roberto Sassu
2024-12-05  0:57         ` Eric Snowberg
2024-12-05  8:53           ` Roberto Sassu
2024-12-05 16:16             ` Roberto Sassu
2024-12-05 19:41               ` Eric Snowberg
2024-12-06 10:06                 ` Roberto Sassu
2024-12-06 15:15                   ` Eric Snowberg
2024-12-06 15:26                     ` Roberto Sassu
2024-11-27 17:30 ` Dr. Greg
2024-11-27 17:56   ` Roberto Sassu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B135AC90-7CE5-4E51-90B1-9D82031668A8@oracle.com \
    --to=eric.snowberg@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=corbet@lwn.net \
    --cc=da.gomez@samsung.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=jikos@kernel.org \
    --cc=jmorris@namei.org \
    --cc=kgold@linux.ibm.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=mkoutny@suse.com \
    --cc=mzerqung@0pointer.de \
    --cc=paul@paul-moore.com \
    --cc=pbrobinson@gmail.com \
    --cc=petr.pavlu@suse.com \
    --cc=petr.vorel@gmail.com \
    --cc=pmatilai@redhat.com \
    --cc=ppavlu@suse.com \
    --cc=roberto.sassu@huawei.com \
    --cc=roberto.sassu@huaweicloud.com \
    --cc=samitolvanen@google.com \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=wufan@linux.microsoft.com \
    --cc=zbyszek@in.waw.pl \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).