On Mon, 2017-10-30 at 13:17 +0000, Matthew Garrett wrote:
> On Mon, Oct 30, 2017 at 12:38 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, 2017-10-27 at 10:41 +0000, Dmitry Kasatkin wrote:
> >
> >> > @@ -345,7 +350,8 @@ int evm_inode_setxattr(struct dentry *dentry, const
> >> > char *xattr_name,
> >> > if (strcmp(xattr_name, XATTR_NAME_EVM) == 0) {
> >> > if (!xattr_value_len)
> >> > return -EINVAL;
> >> > - if (xattr_data->type != EVM_IMA_XATTR_DIGSIG)
> >> > + if (xattr_data->type != EVM_IMA_XATTR_DIGSIG &&
> >> > + xattr_data->type != EVM_XATTR_PORTABLE_DIGSIG)
> >> > return -EPERM;
> >> > }
> >>
> >> Also I have an impression that evm_protect_xattr will allow to set
> >> security.ima for example,
> >> And it will cause to try to re-calculate hmac over immutable
> >> signature...
> >
> > Right, it will allow evm_inode_post_setxattr() to replace the new file
> > signature with an HMAC.
>
> evm_inode_setxattr() will call evm_protect_xattr(), which will call
> evm_verify_xattr(). This will return INTEGRITY_PASS_IMMUTABLE, which
> will result in evm_protect_xattr() returning -EPERM, so we never get
> to inode_post_setxattr().
Oh, I missed that.
