> On Dec 6, 2024, at 3:06 AM, Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > On Thu, 2024-12-05 at 19:41 +0000, Eric Snowberg wrote: >> >>> On Dec 5, 2024, at 9:16 AM, Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: >>> >>> On Thu, 2024-12-05 at 09:53 +0100, Roberto Sassu wrote: >>>> On Thu, 2024-12-05 at 00:57 +0000, Eric Snowberg wrote: >>>>> >>>>>> On Dec 4, 2024, at 3:44 AM, Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: >>>>>> >>>>>> On Tue, 2024-12-03 at 20:06 +0000, Eric Snowberg wrote: >>>>>>> >>>>>>>> On Nov 26, 2024, at 3:41 AM, Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> wrote: >>>>>>>>>> >>>>>>>>>> From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> >>>>>>>>>> >>>>>>>>>> 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. >>>>>> >>>>>>> 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. >>>> >>>> Yes, deleting the digest list would invalidate any integrity result >>>> done with that digest list. >>>> >>>> I developed also an rpm plugin that synchronizes the digest lists with >>>> installed software. Old vulnerable software cannot be verified anymore >>>> with the Integrity Digest Cache, since the rpm plugin deletes the old >>>> software digest lists. >>>> >>>> https://github.com/linux-integrity/digest-cache-tools/blob/main/rpm-plugin/digest_cache.c >>>> >>>> The good thing is that the Integrity Digest Cache can be easily >>>> controlled with filesystem operations (it works similarly to security >>>> blobs attached to kernel objects, like inodes and file descriptors). >>>> >>>> As soon as something changes (e.g. digest list written, link to the >>>> digest lists), this triggers a reset in the Integrity Digest Cache, so >>>> digest lists and files need to be verified again. Deleting the digest >>>> list causes the in-kernel digest cache to be wiped away too (when the >>>> reference count reaches zero). >>>> >>>>> 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. >>>> >>>> I don't like making exceptions in the design, and I recently realized >>>> that it should not be task of the users of the Integrity Digest Cache >>>> to limit themselves. >>> >>> Forgot to mention that your use case is possible. The usage of the >>> Integrity Digest Cache must be explicitly enabled in the IMA policy. It >>> will be used if the matching rule has 'digest_cache=data' (its foreseen >>> to be used also for metadata). >> >> I see a lot of benefit if metadata integrity could be maintained, but in the >> current form of this series, I don't think that is possible. The Digest Cache >> doesn't contain or enforce the file path, which would be necessary to >> maintain integrity. Here is an example of why it would be needed, say >> you have two applications that need a configuration file to start. The first >> application has an empty file where no configuration options are currently >> defined. Now there is a hash for an empty file in the Digest Cache. The >> second application can be started with an empty configuration file, however >> the end-user has added some options to it. If the configuration file for the >> second application is replaced with an empty file, it will not be detected, >> since the Digest Cache would see the empty file hash in its cache. > > I was thinking more to store in the digest cache digests of metadata > (including for example the expected SELinux label), that EVM can > lookup. > > In that way, the problem you foresee cannot happen: if you replace the > file belonging to app2_t with the one belonging to app1_t, SELinux > would deny the permission to access; if you change the SELinux label of > the file, EVM will deny the access. If two different applications have config files in /etc, wouldn't both files have the same SELinux label? > You can still go back to the initial state, for that a rollback > prevention mechanism is needed (maybe EVM can remove the digest of the > initial state from the digest cache when it sees an update?). > > In general, the Integrity Digest Cache should be considered as an > alternative mechanism to validate immutable files, or the initial state > of mutable files. For mutable files, EVM HMAC will protect further > updates. In the example above, from a distro standpoint, most files contained in /etc are viewed as being mutable. However an end-user that wants to maintain integrity on their system wouldn't view it that way. They don't want config changes they have made to be backed out. In the current form they would view this series as an Authenticity Digest Cache. I'm just trying to show that this could be a lot more valuable to the end-user if some things were changed.
