The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
	corbet@lwn.net, viro@zeniv.linux.org.uk, brauner@kernel.org,
	jack@suse.cz, dmitry.kasatkin@gmail.com,
	eric.snowberg@oracle.com, paul@paul-moore.com, jmorris@namei.org,
	serge@hallyn.com
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v3 5/6] ima: Defer fixing security.ima to __fput()
Date: Fri, 31 Jan 2025 11:52:18 -0500	[thread overview]
Message-ID: <574ab3058a019c0536c29f54516c48fdae82af12.camel@linux.ibm.com> (raw)
In-Reply-To: <20250122172432.3074180-6-roberto.sassu@huaweicloud.com>

On Wed, 2025-01-22 at 18:24 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
> 
> IMA-Appraisal implements a fix mode, selectable from the kernel command
> line by specifying ima_appraise=fix.
> 
> The fix mode is meant to be used in a TOFU (trust on first use) model,
> where systems are supposed to work under controlled conditions before the
> real enforcement starts.
> 
> Since the systems are under controlled conditions, it is assumed that the
> files are not corrupted, and thus their current data digest can be trusted,
> and written to security.ima.
> 
> When IMA-Appraisal is switched to enforcing mode, the security.ima value
> collected during the fix mode is used as a reference value, and a mismatch
> with the current value cause the access request to be denied.
> 
> However, since fixing security.ima is placed in ima_appraise_measurement()
> during the integrity check, it requires the inode lock to be taken in
> process_measurement(), in addition to ima_update_xattr() invoked at file
> close.
> 
> Postpone the security.ima update to ima_check_last_writer(), by setting the
> new atomic flag IMA_UPDATE_XATTR_FIX in the inode integrity metadata, in
> ima_appraise_measurement(), if security.ima needs to be fixed. In this way,
> the inode lock can be removed from process_measurement(). Also, set the
> cause appropriately for the fix operation and for allowing access to new
> and empty signed files.
> 
> Finally, update security.ima when IMA_UPDATE_XATTR_FIX is set, and when
> there wasn't a previous security.ima update, which occurs if the process
> closing the file descriptor is the last writer.
> 
> Deferring fixing security.ima has a side effect: metadata of files with an
> invalid EVM HMAC cannot be updated until the file is close. In alternative
> to waiting, it is also recommended to add 'evm=fix' in the kernel command
> line to handle this case (recommendation added to kernel-parameters.txt as
> well).
> 
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---

[ ... ]

> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -158,13 +158,16 @@ static void ima_check_last_writer(struct ima_iint_cache
> *iint,
>  				  struct inode *inode, struct file *file)
>  {
>  	fmode_t mode = file->f_mode;
> -	bool update;
> +	bool update = false, update_fix;
>  
> -	if (!(mode & FMODE_WRITE))
> +	update_fix = test_and_clear_bit(IMA_UPDATE_XATTR_FIX,
> +					&iint->atomic_flags);
> +
> +	if (!(mode & FMODE_WRITE) && !update_fix)
>  		return;
>  
>  	ima_iint_lock(inode);
> -	if (atomic_read(&inode->i_writecount) == 1) {
> +	if ((mode & FMODE_WRITE) && atomic_read(&inode->i_writecount) == 1) {
>  		struct kstat stat;
>  
>  		update = test_and_clear_bit(IMA_UPDATE_XATTR,
> @@ -181,6 +184,10 @@ static void ima_check_last_writer(struct ima_iint_cache *iint,
>  				ima_update_xattr(iint, file);
>  		}
>  	}
> +
> +	if (!update && update_fix)
> +		ima_update_xattr(iint, file);
> +
>  	ima_iint_unlock(inode);
>  }
>  
> @@ -378,13 +385,10 @@ static int process_measurement(struct file *file, const
> struct cred *cred,
>  				      template_desc);
>  	if (rc == 0 && (action & IMA_APPRAISE_SUBMASK)) {
>  		rc = ima_check_blacklist(iint, modsig, pcr);
> -		if (rc != -EPERM) {
> -			inode_lock(inode);
> +		if (rc != -EPERM)
>  			rc = ima_appraise_measurement(func, iint, file,
>  						      pathname, xattr_value,
>  						      xattr_len, modsig);
> -			inode_unlock(inode);
> -		}
>  		if (!rc)
>  			rc = mmap_violation_check(func, file, &pathbuf,
>  						  &pathname, filename);

In ima_appraise_measurement() IMA calls EVM to verify the file metadata
(evm_verifyxattr). One would think that since IMA is not "fixing" security.ima, EVM
would not require the inode lock to be taken by IMA.  However, in addition to
verifying the file metdata, EVM converts the original file metadata signature to an
HMAC.  This does require the inode lock. Perhaps the EVM conversion from a signature
to an HMAC needs to be deferred as well.

Mimi


  reply	other threads:[~2025-01-31 16:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22 17:24 [PATCH v3 0/6] ima: Remove unnecessary inode locks Roberto Sassu
2025-01-22 17:24 ` [PATCH v3 1/6] fs: ima: Remove S_IMA and IS_IMA() Roberto Sassu
2025-01-31 16:54   ` Mimi Zohar
2025-01-22 17:24 ` [PATCH v3 2/6] ima: Remove inode lock Roberto Sassu
2025-01-31 16:56   ` Mimi Zohar
2025-01-22 17:24 ` [PATCH v3 3/6] ima: Detect if lock is held when iint pointer is set in inode security blob Roberto Sassu
2025-01-31 16:51   ` Mimi Zohar
2025-01-22 17:24 ` [PATCH v3 4/6] ima: Mark concurrent accesses to the iint pointer in the " Roberto Sassu
2025-01-31 16:59   ` Mimi Zohar
2025-01-22 17:24 ` [PATCH v3 5/6] ima: Defer fixing security.ima to __fput() Roberto Sassu
2025-01-31 16:52   ` Mimi Zohar [this message]
2025-01-22 17:24 ` [PATCH v3 6/6] ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr Roberto Sassu
2025-02-03  1:31   ` Mimi Zohar

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=574ab3058a019c0536c29f54516c48fdae82af12.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eric.snowberg@oracle.com \
    --cc=jack@suse.cz \
    --cc=jmorris@namei.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=roberto.sassu@huaweicloud.com \
    --cc=serge@hallyn.com \
    --cc=viro@zeniv.linux.org.uk \
    /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