linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Junxiao Bi <junxiao.bi@oracle.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Cc: paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
	axboe@kernel.dk, konrad.wilk@oracle.com, joe.jin@oracle.com,
	junxiao.bi@oracle.com
Subject: Re: [PATCH V2] debugfs: allow access relay files in lockdown mode
Date: Mon, 17 Apr 2023 15:34:19 -0500	[thread overview]
Message-ID: <878reqs0xg.fsf@linux.ibm.com> (raw)
In-Reply-To: <20230412205316.7114-1-junxiao.bi@oracle.com>

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).


> v2 <- v1:
> Fix build error when CONFIG_RELAY is not defined.
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/oe-kbuild-all/202304121714.6mahd9EW-lkp@intel.com/
>
> Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
> ---
>  fs/debugfs/file.c     | 9 +++++++++
>  include/linux/relay.h | 8 ++++++++
>  2 files changed, 17 insertions(+)
>
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 1f971c880dde..c52c94e20366 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -21,6 +21,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/poll.h>
>  #include <linux/security.h>
> +#include <linux/relay.h>
>  
>  #include "internal.h"
>  
> @@ -142,6 +143,11 @@ EXPORT_SYMBOL_GPL(debugfs_file_put);
>   * Only permit access to world-readable files when the kernel is locked down.
>   * We also need to exclude any file that has ways to write or alter it as root
>   * can bypass the permissions check.
> + * Exception:
> + * 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.
>   */
>  static int debugfs_locked_down(struct inode *inode,
>  			       struct file *filp,
> @@ -154,6 +160,9 @@ static int debugfs_locked_down(struct inode *inode,
>  	    !real_fops->mmap)
>  		return 0;
>  
> +	if (is_relay_file(real_fops))
> +		return 0;
> +
>  	if (security_locked_down(LOCKDOWN_DEBUGFS))
>  		return -EPERM;
>  
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 72b876dd5cb8..914f116d826e 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -279,8 +279,16 @@ extern const struct file_operations relay_file_operations;
>  
>  #ifdef CONFIG_RELAY
>  int relay_prepare_cpu(unsigned int cpu);
> +static inline int is_relay_file(const struct file_operations *fops)
> +{
> +	return fops == &relay_file_operations;
> +}
>  #else
>  #define relay_prepare_cpu     NULL
> +static inline int is_relay_file(const struct file_operations *fops)
> +{
> +	return 0;
> +}

The return type should be bool for predicate functions like this IMO.

  reply	other threads:[~2023-04-17 20:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-12 20:53 [PATCH V2] debugfs: allow access relay files in lockdown mode Junxiao Bi
2023-04-17 20:34 ` Nathan Lynch [this message]
2023-04-17 21:56   ` Paul Moore
2023-04-17 23:48     ` Junxiao Bi

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=878reqs0xg.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=jmorris@namei.org \
    --cc=joe.jin@oracle.com \
    --cc=junxiao.bi@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).