diff mbox series

[-next] evm: Use __vfs_setxattr() to update security.evm

Message ID 20221228030248.94285-1-xiujianfeng@huawei.com (mailing list archive)
State Handled Elsewhere
Headers show
Series [-next] evm: Use __vfs_setxattr() to update security.evm | expand

Commit Message

Xiu Jianfeng Dec. 28, 2022, 3:02 a.m. UTC
Currently it uses __vfs_setxattr_noperm() to update "security.evm",
however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
being called inside this function, which don't make any sense for xattr
"security.evm", because the handlers of these two hooks, such as selinux
and smack, only care about their own xattr.

On the other hand, there is a literally rather than actually cyclical
callchain as follows:
security_inode_post_setxattr
  ->evm_inode_post_setxattr
    ->evm_update_evmxattr
      ->__vfs_setxattr_noperm
        ->security_inode_post_setxattr

So use __vfs_setxattr() to update "security.evm".

Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
---
 security/integrity/evm/evm_crypto.c   | 7 +++----
 security/integrity/ima/ima_appraise.c | 8 ++++----
 2 files changed, 7 insertions(+), 8 deletions(-)

Comments

Mimi Zohar Jan. 18, 2023, 9:45 p.m. UTC | #1
On Wed, 2022-12-28 at 11:02 +0800, Xiu Jianfeng wrote:
> Currently it uses __vfs_setxattr_noperm() to update "security.evm",
> however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
> being called inside this function, which don't make any sense for xattr
> "security.evm", because the handlers of these two hooks, such as selinux
> and smack, only care about their own xattr.

Updating the security.ima hash triggers re-calculating and writing the
security.evm HMAC.  Refer to evm_inode_post_setxattr().

Mimi

> 
> On the other hand, there is a literally rather than actually cyclical
> callchain as follows:
> security_inode_post_setxattr
>   ->evm_inode_post_setxattr
>     ->evm_update_evmxattr
>       ->__vfs_setxattr_noperm
>         ->security_inode_post_setxattr
> 
> So use __vfs_setxattr() to update "security.evm".
> 
> Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
> ---
>  security/integrity/evm/evm_crypto.c   | 7 +++----
>  security/integrity/ima/ima_appraise.c | 8 ++++----
>  2 files changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index fa5ff13fa8c9..d8275dfa49ef 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -376,10 +376,9 @@ int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
>  			   xattr_value_len, &data);
>  	if (rc == 0) {
>  		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
> -		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
> -					   XATTR_NAME_EVM,
> -					   &data.hdr.xattr.data[1],
> -					   SHA1_DIGEST_SIZE + 1, 0);
> +		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
> +				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
> +				    SHA1_DIGEST_SIZE + 1, 0);
>  	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
>  		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
>  	}
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index ee6f7e237f2e..d2de9dc6c345 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -98,10 +98,10 @@ static int ima_fix_xattr(struct dentry *dentry,
>  		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
>  		iint->ima_hash->xattr.ng.algo = algo;
>  	}
> -	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
> -				   &iint->ima_hash->xattr.data[offset],
> -				   (sizeof(iint->ima_hash->xattr) - offset) +
> -				   iint->ima_hash->length, 0);
> +	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
> +			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
> +			    (sizeof(iint->ima_hash->xattr) - offset) +
> +			    iint->ima_hash->length, 0);
>  	return rc;
>  }
>
Guozihua (Scott) Jan. 30, 2023, 1:53 a.m. UTC | #2
On 2023/1/19 5:45, Mimi Zohar wrote:
> On Wed, 2022-12-28 at 11:02 +0800, Xiu Jianfeng wrote:
>> Currently it uses __vfs_setxattr_noperm() to update "security.evm",
>> however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
>> being called inside this function, which don't make any sense for xattr
>> "security.evm", because the handlers of these two hooks, such as selinux
>> and smack, only care about their own xattr.
> 
> Updating the security.ima hash triggers re-calculating and writing the
> security.evm HMAC.  Refer to evm_inode_post_setxattr().
> 
> Mimi

Hi Mimi,

I believe what Jianfeng is trying to do is to avoid re-triggering
security_inode_post_setxattr if we are updating security.evm. I can't
think of any other xattr that could "absorb" security.evm.
> 
>>
>> On the other hand, there is a literally rather than actually cyclical
>> callchain as follows:
>> security_inode_post_setxattr
>>   ->evm_inode_post_setxattr
>>     ->evm_update_evmxattr
>>       ->__vfs_setxattr_noperm
>>         ->security_inode_post_setxattr
>>
>> So use __vfs_setxattr() to update "security.evm".
>>
>> Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
>> ---
>>  security/integrity/evm/evm_crypto.c   | 7 +++----
>>  security/integrity/ima/ima_appraise.c | 8 ++++----
>>  2 files changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
>> index fa5ff13fa8c9..d8275dfa49ef 100644
>> --- a/security/integrity/evm/evm_crypto.c
>> +++ b/security/integrity/evm/evm_crypto.c
>> @@ -376,10 +376,9 @@ int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
>>  			   xattr_value_len, &data);
>>  	if (rc == 0) {
>>  		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
>> -		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
>> -					   XATTR_NAME_EVM,
>> -					   &data.hdr.xattr.data[1],
>> -					   SHA1_DIGEST_SIZE + 1, 0);
>> +		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>> +				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
>> +				    SHA1_DIGEST_SIZE + 1, 0);
>>  	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
>>  		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
>>  	}
>> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
>> index ee6f7e237f2e..d2de9dc6c345 100644
>> --- a/security/integrity/ima/ima_appraise.c
>> +++ b/security/integrity/ima/ima_appraise.c
>> @@ -98,10 +98,10 @@ static int ima_fix_xattr(struct dentry *dentry,
>>  		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
>>  		iint->ima_hash->xattr.ng.algo = algo;
>>  	}
>> -	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
>> -				   &iint->ima_hash->xattr.data[offset],
>> -				   (sizeof(iint->ima_hash->xattr) - offset) +
>> -				   iint->ima_hash->length, 0);
>> +	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>> +			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
>> +			    (sizeof(iint->ima_hash->xattr) - offset) +
>> +			    iint->ima_hash->length, 0);
>>  	return rc;
>>  }
>>  
> 
>
Mimi Zohar Jan. 31, 2023, 11:31 a.m. UTC | #3
On Mon, 2023-01-30 at 09:53 +0800, Guozihua (Scott) wrote:
> On 2023/1/19 5:45, Mimi Zohar wrote:
> > On Wed, 2022-12-28 at 11:02 +0800, Xiu Jianfeng wrote:
> >> Currently it uses __vfs_setxattr_noperm() to update "security.evm",
> >> however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
> >> being called inside this function, which don't make any sense for xattr
> >> "security.evm", because the handlers of these two hooks, such as selinux
> >> and smack, only care about their own xattr.
> > 
> > Updating the security.ima hash triggers re-calculating and writing the
> > security.evm HMAC.  Refer to evm_inode_post_setxattr().
> 
> Hi Mimi,
> 
> I believe what Jianfeng is trying to do is to avoid re-triggering
> security_inode_post_setxattr if we are updating security.evm. I can't
> think of any other xattr that could "absorb" security.evm.

I understand.  Comments below ...
> > 
> >>
> >> On the other hand, there is a literally rather than actually cyclical
> >> callchain as follows:
> >> security_inode_post_setxattr
> >>   ->evm_inode_post_setxattr
> >>     ->evm_update_evmxattr
> >>       ->__vfs_setxattr_noperm
> >>         ->security_inode_post_setxattr
> >>
> >> So use __vfs_setxattr() to update "security.evm".
> >>
> >> Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
> >> ---
> >>  security/integrity/evm/evm_crypto.c   | 7 +++----
> >>  security/integrity/ima/ima_appraise.c | 8 ++++----
> >>  2 files changed, 7 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> >> index fa5ff13fa8c9..d8275dfa49ef 100644
> >> --- a/security/integrity/evm/evm_crypto.c
> >> +++ b/security/integrity/evm/evm_crypto.c
> >> @@ -376,10 +376,9 @@ int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
> >>  			   xattr_value_len, &data);
> >>  	if (rc == 0) {
> >>  		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
> >> -		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
> >> -					   XATTR_NAME_EVM,
> >> -					   &data.hdr.xattr.data[1],
> >> -					   SHA1_DIGEST_SIZE + 1, 0);
> >> +		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
> >> +				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
> >> +				    SHA1_DIGEST_SIZE + 1, 0);

Although __vfs_setxattr_noperm() doesn't do any permission checking, it
does other things - make sure the filesystem supports writing xattrs,
calls fsnotify_xattr().

> >>  	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
> >>  		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
> >>  	}
> >> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> >> index ee6f7e237f2e..d2de9dc6c345 100644
> >> --- a/security/integrity/ima/ima_appraise.c
> >> +++ b/security/integrity/ima/ima_appraise.c
> >> @@ -98,10 +98,10 @@ static int ima_fix_xattr(struct dentry *dentry,
> >>  		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
> >>  		iint->ima_hash->xattr.ng.algo = algo;
> >>  	}
> >> -	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
> >> -				   &iint->ima_hash->xattr.data[offset],
> >> -				   (sizeof(iint->ima_hash->xattr) - offset) +
> >> -				   iint->ima_hash->length, 0);
> >> +	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
> >> +			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
> >> +			    (sizeof(iint->ima_hash->xattr) - offset) +
> >> +			    iint->ima_hash->length, 0);

To clarify, ima_fix_xattr() is either directly called when in "fix"
mode or from ima_update_xattr().  With this change, the recalculated
file hash would be written to security.ima, but security.evm would not
be updated.

> >>  	return rc;
> >>  }
Xiu Jianfeng Feb. 1, 2023, 6:42 a.m. UTC | #4
Hi,

On 2023/1/31 19:31, Mimi Zohar wrote:
> On Mon, 2023-01-30 at 09:53 +0800, Guozihua (Scott) wrote:
>> On 2023/1/19 5:45, Mimi Zohar wrote:
>>> On Wed, 2022-12-28 at 11:02 +0800, Xiu Jianfeng wrote:
>>>> Currently it uses __vfs_setxattr_noperm() to update "security.evm",
>>>> however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
>>>> being called inside this function, which don't make any sense for xattr
>>>> "security.evm", because the handlers of these two hooks, such as selinux
>>>> and smack, only care about their own xattr.
>>>
>>> Updating the security.ima hash triggers re-calculating and writing the
>>> security.evm HMAC.  Refer to evm_inode_post_setxattr().
>>
>> Hi Mimi,
>>
>> I believe what Jianfeng is trying to do is to avoid re-triggering
>> security_inode_post_setxattr if we are updating security.evm. I can't
>> think of any other xattr that could "absorb" security.evm.
> 
> I understand.  Comments below ...
>>>
>>>>
>>>> On the other hand, there is a literally rather than actually cyclical
>>>> callchain as follows:
>>>> security_inode_post_setxattr
>>>>   ->evm_inode_post_setxattr
>>>>     ->evm_update_evmxattr
>>>>       ->__vfs_setxattr_noperm
>>>>         ->security_inode_post_setxattr
>>>>
>>>> So use __vfs_setxattr() to update "security.evm".
>>>>
>>>> Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
>>>> ---
>>>>  security/integrity/evm/evm_crypto.c   | 7 +++----
>>>>  security/integrity/ima/ima_appraise.c | 8 ++++----
>>>>  2 files changed, 7 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
>>>> index fa5ff13fa8c9..d8275dfa49ef 100644
>>>> --- a/security/integrity/evm/evm_crypto.c
>>>> +++ b/security/integrity/evm/evm_crypto.c
>>>> @@ -376,10 +376,9 @@ int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
>>>>  			   xattr_value_len, &data);
>>>>  	if (rc == 0) {
>>>>  		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
>>>> -		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
>>>> -					   XATTR_NAME_EVM,
>>>> -					   &data.hdr.xattr.data[1],
>>>> -					   SHA1_DIGEST_SIZE + 1, 0);
>>>> +		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>>>> +				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
>>>> +				    SHA1_DIGEST_SIZE + 1, 0);
> 
> Although __vfs_setxattr_noperm() doesn't do any permission checking, it
> does other things - make sure the filesystem supports writing xattrs,
> calls fsnotify_xattr().
> 
>>>>  	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
>>>>  		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
>>>>  	}
>>>> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
>>>> index ee6f7e237f2e..d2de9dc6c345 100644
>>>> --- a/security/integrity/ima/ima_appraise.c
>>>> +++ b/security/integrity/ima/ima_appraise.c
>>>> @@ -98,10 +98,10 @@ static int ima_fix_xattr(struct dentry *dentry,
>>>>  		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
>>>>  		iint->ima_hash->xattr.ng.algo = algo;
>>>>  	}
>>>> -	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
>>>> -				   &iint->ima_hash->xattr.data[offset],
>>>> -				   (sizeof(iint->ima_hash->xattr) - offset) +
>>>> -				   iint->ima_hash->length, 0);
>>>> +	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>>>> +			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
>>>> +			    (sizeof(iint->ima_hash->xattr) - offset) +
>>>> +			    iint->ima_hash->length, 0);
> 
> To clarify, ima_fix_xattr() is either directly called when in "fix"
> mode or from ima_update_xattr().  With this change, the recalculated
> file hash would be written to security.ima, but security.evm would not
> be updated.

Thanks for you explanation, I will drop this patch.

> 
>>>>  	return rc;
>>>>  }
>
Guozihua (Scott) Feb. 1, 2023, 7:10 a.m. UTC | #5
On 2023/1/31 19:31, Mimi Zohar wrote:
> On Mon, 2023-01-30 at 09:53 +0800, Guozihua (Scott) wrote:
>> On 2023/1/19 5:45, Mimi Zohar wrote:
>>> On Wed, 2022-12-28 at 11:02 +0800, Xiu Jianfeng wrote:
>>>> Currently it uses __vfs_setxattr_noperm() to update "security.evm",
>>>> however there are two lsm hooks(inode_post_setxattr and inode_setsecurity)
>>>> being called inside this function, which don't make any sense for xattr
>>>> "security.evm", because the handlers of these two hooks, such as selinux
>>>> and smack, only care about their own xattr.
>>>
>>> Updating the security.ima hash triggers re-calculating and writing the
>>> security.evm HMAC.  Refer to evm_inode_post_setxattr().
>>
>> Hi Mimi,
>>
>> I believe what Jianfeng is trying to do is to avoid re-triggering
>> security_inode_post_setxattr if we are updating security.evm. I can't
>> think of any other xattr that could "absorb" security.evm.
> 
> I understand.  Comments below ...
>>>
>>>>
>>>> On the other hand, there is a literally rather than actually cyclical
>>>> callchain as follows:
>>>> security_inode_post_setxattr
>>>>   ->evm_inode_post_setxattr
>>>>     ->evm_update_evmxattr
>>>>       ->__vfs_setxattr_noperm
>>>>         ->security_inode_post_setxattr
>>>>
>>>> So use __vfs_setxattr() to update "security.evm".
>>>>
>>>> Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
>>>> ---
>>>>  security/integrity/evm/evm_crypto.c   | 7 +++----
>>>>  security/integrity/ima/ima_appraise.c | 8 ++++----
>>>>  2 files changed, 7 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
>>>> index fa5ff13fa8c9..d8275dfa49ef 100644
>>>> --- a/security/integrity/evm/evm_crypto.c
>>>> +++ b/security/integrity/evm/evm_crypto.c
>>>> @@ -376,10 +376,9 @@ int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
>>>>  			   xattr_value_len, &data);
>>>>  	if (rc == 0) {
>>>>  		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
>>>> -		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
>>>> -					   XATTR_NAME_EVM,
>>>> -					   &data.hdr.xattr.data[1],
>>>> -					   SHA1_DIGEST_SIZE + 1, 0);
>>>> +		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>>>> +				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
>>>> +				    SHA1_DIGEST_SIZE + 1, 0);
> 
> Although __vfs_setxattr_noperm() doesn't do any permission checking, it
> does other things - make sure the filesystem supports writing xattrs,
> calls fsnotify_xattr().

Thanks for the explanation Mimi, this makes sense.
> 
>>>>  	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
>>>>  		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
>>>>  	}
>>>> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
>>>> index ee6f7e237f2e..d2de9dc6c345 100644
>>>> --- a/security/integrity/ima/ima_appraise.c
>>>> +++ b/security/integrity/ima/ima_appraise.c
>>>> @@ -98,10 +98,10 @@ static int ima_fix_xattr(struct dentry *dentry,
>>>>  		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
>>>>  		iint->ima_hash->xattr.ng.algo = algo;
>>>>  	}
>>>> -	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
>>>> -				   &iint->ima_hash->xattr.data[offset],
>>>> -				   (sizeof(iint->ima_hash->xattr) - offset) +
>>>> -				   iint->ima_hash->length, 0);
>>>> +	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
>>>> +			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
>>>> +			    (sizeof(iint->ima_hash->xattr) - offset) +
>>>> +			    iint->ima_hash->length, 0);
> 
> To clarify, ima_fix_xattr() is either directly called when in "fix"
> mode or from ima_update_xattr().  With this change, the recalculated
> file hash would be written to security.ima, but security.evm would not
> be updated.

Sorry I missed this part. I agree that it is not a good idea to alter
ima_fix_xattr().
> 
>>>>  	return rc;
>>>>  }
>
diff mbox series

Patch

diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index fa5ff13fa8c9..d8275dfa49ef 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -376,10 +376,9 @@  int evm_update_evmxattr(struct dentry *dentry, const char *xattr_name,
 			   xattr_value_len, &data);
 	if (rc == 0) {
 		data.hdr.xattr.sha1.type = EVM_XATTR_HMAC;
-		rc = __vfs_setxattr_noperm(&init_user_ns, dentry,
-					   XATTR_NAME_EVM,
-					   &data.hdr.xattr.data[1],
-					   SHA1_DIGEST_SIZE + 1, 0);
+		rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
+				    XATTR_NAME_EVM, &data.hdr.xattr.data[1],
+				    SHA1_DIGEST_SIZE + 1, 0);
 	} else if (rc == -ENODATA && (inode->i_opflags & IOP_XATTR)) {
 		rc = __vfs_removexattr(&init_user_ns, dentry, XATTR_NAME_EVM);
 	}
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index ee6f7e237f2e..d2de9dc6c345 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -98,10 +98,10 @@  static int ima_fix_xattr(struct dentry *dentry,
 		iint->ima_hash->xattr.ng.type = IMA_XATTR_DIGEST_NG;
 		iint->ima_hash->xattr.ng.algo = algo;
 	}
-	rc = __vfs_setxattr_noperm(&init_user_ns, dentry, XATTR_NAME_IMA,
-				   &iint->ima_hash->xattr.data[offset],
-				   (sizeof(iint->ima_hash->xattr) - offset) +
-				   iint->ima_hash->length, 0);
+	rc = __vfs_setxattr(&init_user_ns, dentry, d_inode(dentry),
+			    XATTR_NAME_IMA, &iint->ima_hash->xattr.data[offset],
+			    (sizeof(iint->ima_hash->xattr) - offset) +
+			    iint->ima_hash->length, 0);
 	return rc;
 }