[lkml]   [2017]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down
Ethan Zhao <> 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/", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/", 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).


 \ /
  Last update: 2017-10-24 16:57    [W:0.340 / U:0.796 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site