Re: [RFC][PATCH 3/8] ima: Add digest_cache policy keyword

[Mimi Zohar <zohar@linux.ibm.com>]

On Fri, 2024-03-08 at 10:05 +0100, Roberto Sassu wrote:
> On Thu, 2024-03-07 at 14:43 -0500, Mimi Zohar wrote:
> > On Wed, 2024-02-14 at 15:35 +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > Add the 'digest_cache=' policy keyword, to enable the usage of digest
> > > caches for specific IMA actions and purposes.
> > > 
> > > At the moment, it accepts only 'content' as value, as digest caches can be
> > > only used only for measurement and appraisal of file content. In the
> > > future, it might be possible to use them for file metadata too.
> > 
> > At least from this patch, it is unclear why 'digest_cache' requires an
> > option.  
> > The usage - measure, appraise - is based on 'action'.  From an IMA
> > perspective,
> > does the file content make a difference?  And if it did, then file 'data'
> > would
> > parallel file 'metadata'.
> 
> I wanted to express the fact that digest caches, if available, can only
> be used to appraise file data, if there is no metadata (similarly to
> module-style appended signatures).
> 
> That would prevent for example the scenario where appraisal of file
> data is successful without having verified current metadata, and EVM
> attaches to the file a valid HMAC on file close, based on the current
> xattr value (trust at first use).

Correct. There's no requirement for 'security.ima' to exist to calculate the EVM
HMAC.  Before using EVM HMAC, the filesystem needs to be properly labeled by
walking the filesystem.  The HMAC is calculated based on the existing file
metadata.  The first use is during a setup stage and subsequently for new files.

> 
> An IMA rule with 'digest_cache=metadata' would take a different code
> path. It would make IMA send to evm_verifyxattr() the calculated file
> digest (since there is no security.ima), and let EVM calculate and
> search the digest of file metadata in the digest cache.

Ok.  So no 'security.evm' either, but a metadata digest cache.

I understand the need to provide EVM with the file hash in this case, but as
much as possible, IMA and EVM should be independent of each other.

> 
> I didn't go that far yet, but this is more or less what I would like to
> do, also based on my old implementation of the IMA Digest Lists
> extension (which supports file metadata lookup).
> 
> > Without having to pass around "digest_cache_mask" would simplify this patch.
> 
> We need to pass it anyway, to let process_measurement() know that it
> can use digest caches. Or we can make 'flags' in ima_iint_cache a u64,
> and introduce new flags.

It's bad enough that the function parameters change when there's actual data. 
Yes, please increase the size of 'flags' and introduce new flags.

thanks,

Mimi

> > > The 'digest_cache=' keyword can be specified for the subset of IMA hooks
> > > listed in ima_digest_cache_func_allowed().
> > > 
> > > POLICY_CHECK has been excluded for measurement, because policy changes
> > > must
> > > be visible in the IMA measurement list. For appraisal, instead, it might
> > > be
> > > useful to load custom policies in the initial ram disk (no security.ima
> > > xattr).
> > > 
> > > Add the digest_cache_mask member to the ima_rule_entry structure, and set
> > > the flag IMA_DIGEST_CACHE_MEASURE_CONTENT if 'digest_cache=content' was
> > > specified for a measure rule, IMA_DIGEST_CACHE_APPRAISE_CONTENT for an
> > > appraise rule.
> > > 
> > > Propagate the mask down to ima_match_policy() and ima_get_action(), so
> > > that
> > > process_measurement() can make the final decision on whether or not digest
> > > caches should be used to measure/appraise the file being evaluated.
> > > 
> > > Since using digest caches changes the meaning of the IMA measurement list,
> > > which will include only digest lists and unknown files, enforce specifying
> > > 'pcr=' with a non-standard value, when 'digest_cache=content' is specified
> > > in a measure rule.
> > > 
> > > This removes the ambiguity on the meaning of the IMA measurement list.
> > > 
> > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > >