linux-kernel - Re: [PATCH 2/2] debugfs: Add access restriction option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Jul 2020 11:39:07 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Peter Enderborg <peter.enderborg@...y.com>
Cc:     linux-kernel@...r.kernel.org,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH 2/2] debugfs: Add access restriction option

On Wed, Jul 15, 2020 at 10:42:07AM +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.
> 
> It is controlled by a configurable default value that can be override
> with a kernel command line parameter. (debugfs=)
> 
> 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@...y.com>
> ---
>  .../admin-guide/kernel-parameters.txt         | 14 +++++++
>  fs/debugfs/inode.c                            | 37 +++++++++++++++++++
>  fs/debugfs/internal.h                         | 14 +++++++
>  lib/Kconfig.debug                             | 32 ++++++++++++++++
>  4 files changed, 97 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index fb95fad81c79..805aa2e58491 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -827,6 +827,20 @@
>  			useful to also enable the page_owner functionality.
>  			on: enable the feature
>  
> +	debugfs=    	[KNL] This parameter enables what is exposed to userspace
> +			and debugfs internal clients.
> +			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
> +				its content. There is nothing to mount.
> +			off: 	Filesystem is not registered and clients
> +			        get a -EPERM as result when trying to register files
> +				or directories within debugfs.
> +				This is equilivant of the runtime functionality if
> +				debugfs was not enabled in the kernel at all.
> +			Default value is set in build-time with a kernel configuration.

Naming is hard.  In looking at this, should "no-fs" be called
"no-mount"?  That's a better description of what it does, right?

Then we can rename the bits to match the documentation so we aren't
constantly thinking of different things and trying to match them up:


> --- a/fs/debugfs/internal.h
> +++ b/fs/debugfs/internal.h
> @@ -29,4 +29,18 @@ struct debugfs_fsdata {
>   */
>  #define DEBUGFS_FSDATA_IS_REAL_FOPS_BIT BIT(0)
>  
> +/* Access BITS */
> +#define DEBUGFS_ALLOW_API	BIT(0)
> +#define DEBUGFS_ALLOW_FS	BIT(1)

#define DEBUGFS_ALLOW_API	BIT(0)
#define DEBUGFS_ALLOW_MOUNT	BIT(1)

> +#ifdef CONFIG_DEBUG_FS_ACCESS_ALL
> +#define DEFAULT_DEBUGFS_ACCESS_BITS (DEBUGFS_ALLOW_FS | DEBUGFS_ALLOW_API)
> +#endif
> +#ifdef CONFIG_DEBUG_FS_ACCESS_NO_FS
> +#define DEFAULT_DEBUGFS_ACCESS_BITS (DEBUGFS_ALLOW_API)
> +#endif
> +#ifdef CONFIG_DEBUG_FS_ACCESS_NONE
> +#define DEFAULT_DEBUGFS_ACCESS_BITS (0)
> +#endif
> +
>  #endif /* _DEBUGFS_INTERNAL_H_ */
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 9ad9210d70a1..b609ad7c1343 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -476,6 +476,38 @@ config DEBUG_FS
>  
>  	  If unsure, say N.
>  
> +choice
> +	prompt "Debugfs default access"
> +	depends on DEBUG_FS
> +	default DEBUG_FS_ACCESS_ALL

default DEBUGFS_FS_ALLOW_ALL

> +	help
> +	  This select the default access restricions for debugfs.
> +	  It can be overridden with kernel command line option
> +	  debugfs=[on,no-fs,off] The restrictions apply for API access
> +	  and filesystem registration. .
> +
> +config DEBUG_FS_ACCESS_ALL

config DEBUG_FS_ALLOW_ALL

> +       bool "Access normal"
> +       help
> +	  No restrictions applies. Both API and filesystem registration
> +	  is on. This is the normal default operation.
> +
> +config DEBUG_FS_ACCESS_NO_FS

config DEBUG_FS_DISALLOW_MOUNT

> +       bool "Do not register debugfs as filesystem"
> +       help
> +	 The API is open but filesystem not loaded. Client can still do
> +	 their work and readed with debug tools that does not need
> +	 debugfs filesystem.
> +
> +config DEBUG_FS_ACCESS_NONE

config DEBUG_FS_ALLOW_NONE

Does that sound better?

I'm not trying to be a pain, just trying to name this all correctly as
it's messy with different config options and bits and mapping that to
checks in the code without everything called the same.

thanks,

greg k-h