From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932346AbdJXO4x (ORCPT ); Tue, 24 Oct 2017 10:56:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37352 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751743AbdJXO4t (ORCPT ); Tue, 24 Oct 2017 10:56:49 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5A2BA61D20 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <150842463163.7923.11081723749106843698.stgit@warthog.procyon.org.uk> <150842466261.7923.14359746674406637357.stgit@warthog.procyon.org.uk> <18778.1508769258@warthog.procyon.org.uk> To: Ethan Zhao Cc: dhowells@redhat.com, joeyli , linux-security-module@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, linux-efi@vger.kernel.org, Greg KH , LKML , jforbes@redhat.com Subject: Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21926.1508857001.1@warthog.procyon.org.uk> Date: Tue, 24 Oct 2017 15:56:41 +0100 Message-ID: <21927.1508857001@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 24 Oct 2017 14:56:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/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