From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Peter Enderborg <peter.enderborg@sony.com>
Cc: linux-kernel@vger.kernel.org,
"Rafael J . Wysocki" <rafael@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v3] debugfs: Add access restriction option
Date: Wed, 17 Jun 2020 16:15:35 +0200 [thread overview]
Message-ID: <20200617141535.GA2624659@kroah.com> (raw)
In-Reply-To: <20200617133738.6631-1-peter.enderborg@sony.com>
On Wed, Jun 17, 2020 at 03:37:38PM +0200, Peter Enderborg wrote:
> Since debugfs include sensitive information it need to be treated
> carefully. But it also has many very useful debug functions for userspace.
> With this option we can have same configuration for system with
> need of debugfs and a way to turn it off. This gives a extra protection
> for exposure on systems where user-space services with system
> access are attacked.
>
> When enabled it is needed a kernel command line parameter to be activated.
>
> It can be on or off, but also internally on but not seen from user-space.
> This no-fs mode do not register a debugfs as filesystem, but client can
> register their parts in the internal structures. This data can be readed
> with a debugger or saved with a crashkernel. When it is off clients
> get EPERM error when accessing the functions for registering their
> components.
>
> Signed-off-by: Peter Enderborg <peter.enderborg@sony.com>
> ---
> v2. Removed MOUNT as part of restrictions. Added API's restrictions as
> separate restriction.
> v3 Updated Documentation after Randy Dunlap reviews and suggestions.
>
> .../admin-guide/kernel-parameters.txt | 11 +++++
> fs/debugfs/inode.c | 47 +++++++++++++++++++
> lib/Kconfig.debug | 10 ++++
> 3 files changed, 68 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index fb95fad81c79..249c86e53bb7 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -827,6 +827,17 @@
> useful to also enable the page_owner functionality.
> on: enable the feature
>
> + debugfs= [KNL] When CONFIG_DEBUG_FS_RESTRICTED is set, this parameter
> + enables what is exposed to userspace.
> + Format: { on, no_fs, off }
> + on: All functions are enabled.
> + no_fs: Filesystem is not registered but kernel clients can
> + access APIs and a crashkernel can be used to read
> + it's content. There its nothing to mount.
> + off: (default) Filesystem is not registered and clients
> + get a -EPERM as result when trying to register files
> + or directories within debugfs.
> +
> debugpat [X86] Enable PAT debugging
>
> decnet.addr= [HW,NET]
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index b7f2e971ecbc..2bd80a932ae1 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -31,10 +31,17 @@
> #include "internal.h"
>
> #define DEBUGFS_DEFAULT_MODE 0700
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> +#define DEBUGFS_ALLOW_API 0x2
> +#define DEBUGFS_ALLOW_FS 0x1
BIT()?
And a tab?
And why a #ifdef?
> +#endif
>
> static struct vfsmount *debugfs_mount;
> static int debugfs_mount_count;
> static bool debugfs_registered;
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> +static unsigned int debugfs_allow;
> +#endif
Why #ifdef?
>
> /*
> * Don't allow access attributes to be changed whilst the kernel is locked down
> @@ -266,6 +273,10 @@ static struct dentry *debug_mount(struct file_system_type *fs_type,
> int flags, const char *dev_name,
> void *data)
> {
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> + if (!(debugfs_allow & DEBUGFS_ALLOW_API))
> + return ERR_PTR(-EPERM);
> +#endif
Ick, all of this #ifdef is a mess, and can be totally avoided if you do
the logic right here. Please make it so that the functions and almost
all of the .c code does not have #ifdef CONFIG_DEBUG_FS_RESTRICTED at
all.
> return mount_single(fs_type, flags, data, debug_fill_super);
> }
>
> @@ -385,6 +396,12 @@ static struct dentry *__debugfs_create_file(const char *name, umode_t mode,
> if (IS_ERR(dentry))
> return dentry;
>
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> + if (!(debugfs_allow & DEBUGFS_ALLOW_API)) {
> + failed_creating(dentry);
> + return ERR_PTR(-EPERM);
> + }
> +#endif
> inode = debugfs_get_inode(dentry->d_sb);
> if (unlikely(!inode)) {
> pr_err("out of free dentries, can not create file '%s'\n",
> @@ -541,6 +558,12 @@ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
> if (IS_ERR(dentry))
> return dentry;
>
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> + if (!(debugfs_allow & DEBUGFS_ALLOW_API)) {
> + failed_creating(dentry);
> + return ERR_PTR(-EPERM);
> + }
> +#endif
> inode = debugfs_get_inode(dentry->d_sb);
> if (unlikely(!inode)) {
> pr_err("out of free dentries, can not create directory '%s'\n",
> @@ -583,6 +606,12 @@ struct dentry *debugfs_create_automount(const char *name,
> if (IS_ERR(dentry))
> return dentry;
>
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> + if (!(debugfs_allow & DEBUGFS_ALLOW_API)) {
> + failed_creating(dentry);
> + return ERR_PTR(-EPERM);
> + }
> +#endif
> inode = debugfs_get_inode(dentry->d_sb);
> if (unlikely(!inode)) {
> pr_err("out of free dentries, can not create automount '%s'\n",
> @@ -786,10 +815,28 @@ bool debugfs_initialized(void)
> }
> EXPORT_SYMBOL_GPL(debugfs_initialized);
>
> +static int __init debugfs_kernel(char *str)
> +{
> +#ifdef CONFIG_DEBUG_FS_RESTRICTED
> + if (str && !strcmp(str, "on"))
> + debugfs_allow = DEBUGFS_ALLOW_API | DEBUGFS_ALLOW_FS;
> + if (str && !strcmp(str, "no-fs"))
> + debugfs_allow |= DEBUGFS_ALLOW_API;
> + if (str && !strcmp(str, "off"))
> + debugfs_allow = 0;
It's set to 0 by default, no need to set it again, right?
> +#endif
> + return 0;
> +
> +}
> +early_param("debugfs", debugfs_kernel);
Why is this a valid parm even if the option is not enabled? Do you mean
to do that? Why?
thanks,
greg k-h
next prev parent reply other threads:[~2020-06-17 14:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 13:37 [PATCH v3] debugfs: Add access restriction option Peter Enderborg
2020-06-17 14:15 ` Greg Kroah-Hartman [this message]
2020-06-17 14:39 ` Enderborg, Peter
2020-06-17 15:10 ` Randy Dunlap
2020-06-22 8:30 ` [PATCH v4 0/2] " Peter Enderborg
2020-06-22 8:30 ` [PATCH 1/2] tracefs: Remove unnecessary debug_fs checks Peter Enderborg
2020-06-22 9:18 ` Greg Kroah-Hartman
2020-06-22 13:47 ` Steven Rostedt
2020-06-22 8:30 ` [PATCH 2/2] debugfs: Add access restriction option Peter Enderborg
2020-07-10 13:06 ` Greg Kroah-Hartman
2020-07-15 8:42 ` [PATCH v5 0/2] " Peter Enderborg
2020-07-15 8:42 ` [PATCH 1/2] tracefs: Remove unnecessary debug_fs checks Peter Enderborg
2020-07-15 8:42 ` [PATCH 2/2] debugfs: Add access restriction option Peter Enderborg
2020-07-15 9:39 ` Greg Kroah-Hartman
2020-07-15 10:03 ` Enderborg, Peter
2020-07-15 10:35 ` Greg Kroah-Hartman
2020-07-15 10:59 ` Enderborg, Peter
2020-07-21 6:47 ` Enderborg, Peter
2020-07-15 15:25 ` [PATCH v6 0/2] " Peter Enderborg
2020-07-15 15:25 ` [PATCH 1/2] tracefs: Remove unnecessary debug_fs checks Peter Enderborg
2020-07-15 15:25 ` [PATCH 2/2] debugfs: Add access restriction option Peter Enderborg
2020-07-16 3:30 ` Randy Dunlap
2020-07-16 4:54 ` [PATCH v7 0/2] " Peter Enderborg
2020-07-16 4:54 ` [PATCH 1/2] tracefs: Remove unnecessary debug_fs checks Peter Enderborg
2020-07-16 4:54 ` [PATCH 2/2] debugfs: Add access restriction option Peter Enderborg
2020-07-16 5:12 ` Randy Dunlap
2020-07-16 7:15 ` [PATCH v8 0/2] " Peter Enderborg
2020-07-16 7:15 ` [PATCH 1/2] tracefs: Remove unnecessary debug_fs checks Peter Enderborg
2020-07-16 7:15 ` [PATCH 2/2] debugfs: Add access restriction option Peter Enderborg
2020-07-16 15:26 ` Randy Dunlap
2020-07-23 15:11 ` [PATCH v8 0/2] " Greg Kroah-Hartman
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=20200617141535.GA2624659@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.enderborg@sony.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.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 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.