From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
Dmitry Kasatkin <d.kasatkin@samsung.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
John Johansen <john.johansen@canonical.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
James Morris <jmorris@namei.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kernel-team <kernel-team@lists.ubuntu.com>
Subject: Re: Kernel panic at Ubuntu: IMA + Apparmor
Date: Fri, 25 Apr 2014 22:21:28 +0100 [thread overview]
Message-ID: <20140425212128.GB18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <874n1h16le.fsf@x220.int.ebiederm.org>
On Fri, Apr 25, 2014 at 01:45:17PM -0700, Eric W. Biederman wrote:
> IMA-appraisal is fundamentally broken because I can take a mandatory
> file lock and prevent IMA-apprasial.
>
> Using kernel_read is what allows this.
>
> > Isn't it a clear motivating case???
>
> kernel_read is not appropriate for IMA use. The rest of this is just
> the messenger.
>
> IMA needs to use a cousin of kernel_read that operates at a lower level
> than vfs_read. A function that all of the permission checks and the
> fsnotify work.
It's worse than that, actually ;-/ IMA hooks in __fput() have interesting
interplay with revoke-related stuff as well. Another very messy thing in
the same area is that it actually does ->read() from under ->i_mutex, leading
to all kinds of interesting locking issues...
I doubt that your "let's open-code vfs_read() guts" would be a good idea;
if nothing else, it might make more sense to make rw_verify_area() skip
the mandlock and security theatre when called in such situation.
What a mess... ;-/
next prev parent reply other threads:[~2014-04-25 21:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 13:00 Kernel panic at Ubuntu: IMA + Apparmor Dmitry Kasatkin
2014-04-25 14:48 ` Dmitry Kasatkin
2014-04-25 18:23 ` Oleg Nesterov
2014-04-25 19:04 ` Eric W. Biederman
2014-04-25 19:25 ` Oleg Nesterov
2014-04-25 19:40 ` Eric W. Biederman
2014-04-25 20:01 ` Oleg Nesterov
2014-04-25 20:20 ` Dmitry Kasatkin
2014-04-25 20:45 ` Eric W. Biederman
2014-04-25 20:52 ` Dmitry Kasatkin
2014-04-25 21:27 ` Eric W. Biederman
2014-04-25 21:46 ` Dmitry Kasatkin
2014-04-25 21:56 ` Dmitry Kasatkin
2014-04-25 22:38 ` Eric W. Biederman
2014-04-26 8:58 ` Dmitry Kasatkin
2014-04-26 13:56 ` Al Viro
2014-04-26 16:54 ` Dmitry Kasatkin
2014-04-26 17:42 ` Al Viro
2014-04-26 19:03 ` Dmitry Kasatkin
2014-04-25 22:11 ` Eric W. Biederman
2014-04-26 8:49 ` Dmitry Kasatkin
2014-04-25 21:21 ` Al Viro [this message]
2014-04-25 21:43 ` Eric W. Biederman
2014-04-25 21:55 ` Al Viro
2014-04-25 22:25 ` Eric W. Biederman
2014-04-29 13:00 ` 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=20140425212128.GB18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=d.kasatkin@samsung.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=kernel-team@lists.ubuntu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=zohar@linux.vnet.ibm.com \
/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.