From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hch@infradead.org,
linux-fsdevel@vger.kernel.org,
Dmitry Kasatkin <dmitry.kasatkin@huawei.com>
Subject: Re: [PATCHv5 1/1] ima: re-introduce own integrity cache lock
Date: Mon, 04 Dec 2017 07:06:13 -0500 [thread overview]
Message-ID: <1512389173.3977.26.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <fe908aedea9e8a03789bfaace514b5b10f20b301.1512153609.git.dmitry.kasatkin@huawei.com>
Hi Dmitry,
On Fri, 2017-12-01 at 20:40 +0200, Dmitry Kasatkin wrote:
> The original design was discussed 3+ years ago, but was never completed/upstreamed.
> Based on the recent discussions with Linus
> https://patchwork.kernel.org/patch/9975919, I've rebased this patch.
>
> Before IMA appraisal was introduced, IMA was using own integrity cache
> lock along with i_mutex. process_measurement and ima_file_free took
> the iint->mutex first and then the i_mutex, while setxattr, chmod and
> chown took the locks in reverse order. To resolve the potential deadlock,
> i_mutex was moved to protect entire IMA functionality and the redundant
> iint->mutex was eliminated.
>
> Solution was based on the assumption that filesystem code does not take
> i_mutex further. But when file is opened with O_DIRECT flag, direct-io
> implementation takes i_mutex and produces deadlock. Furthermore, certain
> other filesystem operations, such as llseek, also take i_mutex.
>
> More recently some filesystems have replaced their filesystem specific
> lock with the global i_rwsem to read a file. As a result, when IMA
> attempts to calculate the file hash, reading the file attempts to take
> the i_rwsem again.
>
> To resolve O_DIRECT related deadlock problem, this patch re-introduces
> iint->mutex. But to eliminate the original chmod() related deadlock
> problem, this patch eliminates the requirement for chmod hooks to take
> the iint->mutex by introducing additional atomic iint->attr_flags to
> indicate calling of the hooks. The allowed locking order is to take
> the iint->mutex first and then the i_rwsem.
>
> Original flags were cleared in chmod(), setxattr() or removwxattr() hooks
> and tested when file was closed or opened again. New atomic flags are set
> or cleared in those hooks and tested to clear iint->flags on close or on open.
>
> Atomic flags are following:
> * IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown, chgrp)
> and file attributes have changed. On file open, it causes IMA to clear
> iint->flags to re-evaluate policy and perform IMA functions again.
> * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called and
> extended attributes have changed. On file open, it causes IMA to clear
> iint->flags IMA_DONE_MASK to re-appraise.
> * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated.
> It is cleared if file policy changes and no update is needed.
> * IMA_DIGSIG - indicates that file security.ima has signature and file
> security.ima must not update to file has on file close.
Nice! I've been testing with this patch and all seems good. Before
queueing this patch to be upstreamed, I'd appreciate if others tested
using it as well. It applies cleanly to the next-queued branch.
A subsequent patch will remove the O_DIRECT check in
ima_calc_file_hash().
Fixes: Commit 6552321831dc "xfs: remove i_iolock and use i_rwsem in
the VFS inode instead"
thanks,
Mimi
next prev parent reply other threads:[~2017-12-04 12:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 18:40 [PATCHv5 1/1] ima: re-introduce own integrity cache lock Dmitry Kasatkin
2017-12-04 12:06 ` Mimi Zohar [this message]
2017-12-04 13:42 ` Roberto Sassu
2017-12-04 15:40 ` Dmitry Kasatkin
2017-12-04 16:30 ` Dmitry Kasatkin
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=1512389173.3977.26.camel@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dmitry.kasatkin@huawei.com \
--cc=hch@infradead.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 \
/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