Thread (54 messages) 54 messages, 7 authors, 2025-01-21

Re: [PATCH v6 00/15] integrity: Introduce the Integrity Digest Cache

From: Eric Snowberg <eric.snowberg@oracle.com>
Date: 2024-12-05 00:58:41
Also in: linux-doc, linux-integrity, linux-kselftest, linux-modules, linux-security-module, lkml

On Dec 4, 2024, at 3:44 AM, Roberto Sassu [off-list ref] wrote:

On Tue, 2024-12-03 at 20:06 +0000, Eric Snowberg wrote:
quoted
quoted
On Nov 26, 2024, at 3:41 AM, Roberto Sassu [off-list ref] wrote:

On Tue, 2024-11-26 at 00:13 +0000, Eric Snowberg wrote:
quoted
quoted
On Nov 19, 2024, at 3:49 AM, Roberto Sassu [off-list ref] 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?
For files included in the digest lists, yes, there won't be detection
of later revocation of a key. However, it will still work at package
level/digest list level, since they are still appraised with a
signature.

We can add a mechanism (if it does not already exist) to invalidate the
integrity status based on key revocation, which can be propagated to
files verified with the affected digest lists.
quoted
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 
This is already possible, digest-cache-tools
(https://github.com/linux-integrity/digest-cache-tools) already allow
to create a digest list with the file a user wants.

But in this case, the user is vouching for having taken the correct
measure of the file at the time it was added to the digest list. This
would be instead automatically guaranteed by RPMs or other packages
shipped with Linux distributions.

To mitigate the concerns of CVEs, we can probably implement a rollback
prevention mechanism, which would not allow to load a previous version
of a digest list.
IMHO, pursuing this with the end-user being in control of what is contained 
within the Digest Cache vs what is contained in a distro would provide more
value. Allowing the end-user to easily update their Digest Cache in some way 
without having to do any type of revocation for both old and vulnerable 
applications with CVEs would be very beneficial.

Is there a belief the Digest Cache would be used without signed kernel 
modules?  Is the performance gain worth changing how kernel modules 
get loaded at boot?  Couldn't this part just be dropped for easier acceptance?  
Integrity is already maintained with the current model of appended signatures. 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help