Re: [PATCH] security: Restrict unprivileged access to /proc/config.gz

[Vic B <linux@vicb.net>]

On Mon, Nov 09, 2026 at 03:38:16PM -0500, Greg KH wrote:
> On Sun, Nov 08, 2026 at 03:23:51PM +0100, Vic B wrote:
> > When using CONFIG_IKCONFIG_PROC, the built-in configuration is
> > world-readable through /proc/config.gz, which somewhat weakens existing
> > address hiding defences, as it allows an unprivileged user to simply
> > read built-in config from the running kernel and build their own copy
> > with identical System.map.
> > 
> > This patch adds a configuration option to restrict access to
> > /proc/config.gz to superuser only.
> > 
> > Signed-off-by: Vic B <linux@vicb.net>
> 
> Full name please.
> 
> But really, a .config file is not a secret, this isn't needed, sorry.

On all my systems (Debian + mainline kernel) the .config file actually
reveals System.map - all that's needed to get matching (fully identical)
System.map is to grab the config and build mainline kernel sources of
the running version under highly predictable build environment (i.e.,
under same distro, which is also strongly indicated by the fact
that the running kernels are installed as deb packages).

So the goal of hiding .config is to hide System.map, for same resons why
there's kptr_restrict in /proc/sys/kernel.

In particular, the problem I'm trying to avoid is that if an attacker
learns even one runtime address, with matching System.map (or just
.config in my case), they may calculate KASLR offset and derive
addresses of other symbols (more precisely, as I don't use
CONFIG_MODULES, all other symbols).

If access restrictitions on /proc/config.gz aren't needed, the only
solution probably is to disable CONFIG_IKCONFIG_PROC (which
actually is kind of access restriction anyway). May be feasible,
but I'm gonna miss /proc/config.gz...

Vic

> greg k-h
>