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

[David Howells]

Ethan Zhao <ethan.kernel@xxxxxxxxx> 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@andromeda ~]# 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