From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Krisztian Litkey <kli@iki.fi>
Cc: linux-unionfs@vger.kernel.org,
Krisztian Litkey <krisztian.litkey@intel.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.
Date: Fri, 20 May 2016 10:21:27 -0400 [thread overview]
Message-ID: <1463754087.2763.17.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <1463725718-2461-1-git-send-email-kli@iki.fi>
Hi Krisztian,
cc'ing LSM and AL for comments
On Fri, 2016-05-20 at 02:28 -0400, Krisztian Litkey wrote:
> IMA tracks the integrity of files by hashing the file content
> and storing the hash in an IMA-specific extended attribute
> (security.ima). When a file opened for writing is closed by
> the last writer, IMA recalculates the hash and updates the
> extended attribute. Updating the attribute happens by locking
> the inode mutex and calling __vfs_setxattr_noperm.
>
> For a file on an overlayfs mount, this causes ovl_setxattr
> being eventually called (from __vfs_setxattr_noperm via
> inode->i_op->setxattr) with the inode already locked. In this
> case we cannot do the xattr setting by calling vfs_setxattr
> since that will try to lock the inode mutex again. To avoid
> a deadlock, we check if the mutex is already locked and call
> __vfs_setxattr_noperm or vfs_setxattr accordingly.
>
> Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
> ---
> fs/overlayfs/inode.c | 25 ++++++++++++++-----------
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
> index b29036a..25bfeeb 100644
> --- a/fs/overlayfs/inode.c
> +++ b/fs/overlayfs/inode.c
> @@ -223,25 +223,28 @@ int ovl_setxattr(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> int err;
> - struct dentry *upperdentry;
> + struct dentry *upper;
> +
> + if (ovl_is_private_xattr(name))
> + return -EPERM;
>
> err = ovl_want_write(dentry);
> if (err)
> goto out;
>
> - err = -EPERM;
> - if (ovl_is_private_xattr(name))
> - goto out_drop_write;
> -
> err = ovl_copy_up(dentry);
> - if (err)
> - goto out_drop_write;
> + if (!err)
> + upper = ovl_dentry_upper(dentry);
>
> - upperdentry = ovl_dentry_upper(dentry);
> - err = vfs_setxattr(upperdentry, name, value, size, flags);
> -
> -out_drop_write:
> ovl_drop_write(dentry);
> +
> + if (err)
> + goto out;
> +
> + if (mutex_is_locked(&upper->d_inode->i_mutex))
> + err = __vfs_setxattr_noperm(upper, name, value, size, flags);
As far as I'm aware, the only time that i_mutex is taken, is during
__fput() when IMA writes security.ima. Previous versions of this patch
checked whether the xattr being written was security.ima. It would
probably be a good idea not to make that assumption here. The question
is what should happen if the i_mutex is locked, but the xattr isn't
security.ima. At minimum it should be audited. Al, any comments?
Mimi
> + else
> + err = vfs_setxattr(upper, name, value, size, flags);
> out:
> return err;
> }
next prev parent reply other threads:[~2016-05-20 14:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-15 18:52 [PATCH 1/1] ovl: setxattr: avoid deadlock when writing IMA xattrs Mimi Zohar
2016-05-15 20:07 ` [PATCH v2 1/1] ovl: setxattr: avoid deadlock when setting IMA xattr Krisztian Litkey
[not found] ` <201605161420.u4GEKLHk009316@d03av05.boulder.ibm.com>
2016-05-16 15:13 ` Krisztian Litkey
2016-05-16 20:22 ` Krisztian Litkey
2016-05-18 22:45 ` Mimi Zohar
2016-05-20 6:28 ` [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr Krisztian Litkey
2016-05-20 14:21 ` Mimi Zohar [this message]
2016-05-20 16:29 ` Al Viro
2016-05-20 17:00 ` Mimi Zohar
2016-05-20 20:53 ` Krisztian Litkey
2016-05-30 14:10 ` Miklos Szeredi
2016-05-30 16:50 ` Al Viro
2016-05-31 2:15 ` Mimi Zohar
2016-05-31 2:15 ` Mimi Zohar
2016-05-31 2:15 ` Mimi Zohar
2016-05-31 2:15 ` Mimi Zohar
2016-05-31 2:29 ` Mimi Zohar
2016-05-31 2:29 ` Mimi Zohar
2016-05-31 2:29 ` Mimi Zohar
2016-05-31 2:29 ` Mimi Zohar
2016-05-20 15:18 ` Andy Whitcroft
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=1463754087.2763.17.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=kli@iki.fi \
--cc=krisztian.litkey@intel.com \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.