linux-kernel - Re: [PATCH 2/3] Add dev.mem.restricted sysctl

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]

Message-ID: <20081116150756.GA24654@1wt.eu>
Date:	Sun, 16 Nov 2008 16:07:56 +0100
From:	Willy Tarreau <w@....eu>
To:	Bernhard Walle <bwalle@...e.de>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, crash-utility@...hat.com
Subject: Re: [PATCH 2/3] Add dev.mem.restricted sysctl

On Sun, Nov 16, 2008 at 03:47:47PM +0100, Bernhard Walle wrote:
> When CONFIG_STRICT_DEVMEM is set, live debugging is not possible with the
> crash utility (see http://people.redhat.com/~anderson). For distributors
> who ship a generic kernel it's difficult: Disabling CONFIG_STRICT_DEVMEM
> is possible, but in general the protection provided by CONFIG_STRICT_DEVMEM
> is useful. However, live debugging should be still neceessary.
> 
> This patch now adds a dev.mem.restricted sysctl that defaults to 0 (off).
> When set to 1 (on), /dev/mem access is unrestricted and crash can be used.

I like your approach. I use /dev/mem a lot for debugging purposes, and
even sometimes to recover important data from memory after a crash has
occurred. Having the ability to inspect memory again by setting a sysctl
seems very appealing to me.

> >From a security point of view the sysctl should be no problem. It's already
> possible to circumvent that restriction if you have root access by loading
> a kernel module that installs a kretprobe that returns 1 for the check function.

I agree.

> I thought of a command line parameter first, but we already have lots of
> command line parameters and rebooting the machine is more difficult than
> just setting a sysctl to 1. It may be possible to implement setting that
> variable in the tools automatically, but that's out of the scope of that
> patch for the kernel and should also not be discussed on LKML.

Rebooting the machine voids any ability to debug or recover data, so the
sysctl is the way to go IMHO.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/