linux-kernel - Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

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: <21927.1508857001@warthog.procyon.org.uk>
Date:   Tue, 24 Oct 2017 15:56:41 +0100
From:   David Howells <dhowells@...hat.com>
To:     Ethan Zhao <ethan.kernel@...il.com>
Cc:     dhowells@...hat.com, joeyli <jlee@...e.com>,
        linux-security-module@...r.kernel.org, gnomes@...rguk.ukuu.org.uk,
        linux-efi@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>, jforbes@...hat.com
Subject: Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Ethan Zhao <ethan.kernel@...il.com> wrote:

>     May I ask a question here -- Is it intentionally enabling the
> read-only mode, so userspace
> tools like dmidecode could work with kernel_is_locked_down ?  while it
> was impossible to work
> with the attached patch applied. Is it a security policy change with
> secure boot ?

I removed readability on /dev/mem, /dev/kmem and /proc/kcore so that userspace
can't use this to gain access to cryptographic material in use by the kernel.

Readability was removed on /dev/port because reading from an I/O port register
might have a side effect or might allow you to snoop h/w interactions, such as
keyboard input.

I can provide an additional config option to allow /dev/mem and similar to
remain readable - but it needs to be a temporary affair.

I can also log accesses to these interfaces so that we can find out what
breaks and fix it.

Note that dmidecode doesn't necessarily use /dev/mem:

	[root@...romeda ~]# strace -f -eopen dmidecode  >/dev/null
	open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
	open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
	open("/sys/firmware/dmi/tables/smbios_entry_point", O_RDONLY) = 3
	open("/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
	+++ exited with 0 +++

Indeed, my Fedora 24 test system boots without a /dev/mem file being present
(I'm not sure *why* /dev/mem isn't present, but I hadn't noticed till now).

David