From: Junxiao Bi <junxiao.bi@oracle.com>
To: Paul Moore <paul@paul-moore.com>, Nathan Lynch <nathanl@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, jmorris@namei.org,
serge@hallyn.com, axboe@kernel.dk, konrad.wilk@oracle.com,
joe.jin@oracle.com
Subject: Re: [PATCH V2] debugfs: allow access relay files in lockdown mode
Date: Mon, 17 Apr 2023 16:48:57 -0700 [thread overview]
Message-ID: <b68c9e1d-71c8-adf9-f7da-1b56a3d4bfbc@oracle.com> (raw)
In-Reply-To: <CAHC9VhS3LpJ_x7ZfdV83KY3U49XFGMLejz7rsiEH19rzyUfD-w@mail.gmail.com>
On 4/17/23 2:56 PM, Paul Moore wrote:
> On Mon, Apr 17, 2023 at 4:39 PM Nathan Lynch<nathanl@linux.ibm.com> wrote:
>> Junxiao Bi<junxiao.bi@oracle.com> writes:
>>> Relay files are used by kernel to transfer information to userspace, these
>>> files have permission 0400, but mmap is supported, so they are blocked by
>>> lockdown. But since kernel just generates the contents of those files while
>>> not reading it, it is saft to access relay files in lockdown mode.
>>>
>>> With this, blktrace can work well in lockdown mode.
>> Assuming that all relay users do not expose the kinds of information
>> that confidentiality mode tries to restrict, this change seems OK to
>> me. I think that assumption applies to blktrace; apart from that, there
>> is a handful of drivers that use relay files (I searched for
>> relay_open() call sites, maybe there is a better way).
> At the very least I see an Intel graphics driver and some network
> drivers, but like you, that was a quick search and I'm probably
> missing something. At the very least someone needs to go audit those
> users/drivers to ensure this is safe to merge.
>
> However, regardless of what that code audit may turn up, I'm a little
> concerned that it would be all too easy to add a new relay interface
> user which isn't safe. The check in debugfs_locked_down() is far too
> removed from the code which is using the relay interface for it to be
> likely noticed in a future case where an unsafe user is added. This
> looks like a vulnerability waiting to happen.
I got this concern. I will make a new version to limit it to only allow
blktrace trace files.
Thanks,
Junxiao.
prev parent reply other threads:[~2023-04-17 23:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 20:53 Junxiao Bi
2023-04-17 20:34 ` Nathan Lynch
2023-04-17 21:56 ` Paul Moore
2023-04-17 23:48 ` Junxiao Bi [this message]
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=b68c9e1d-71c8-adf9-f7da-1b56a3d4bfbc@oracle.com \
--to=junxiao.bi@oracle.com \
--cc=axboe@kernel.dk \
--cc=jmorris@namei.org \
--cc=joe.jin@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nathanl@linux.ibm.com \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®