mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.


      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®