Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752438AbdCOMdq (ORCPT ); Wed, 15 Mar 2017 08:33:46 -0400 Received: from smtp.math.uni-bielefeld.de ([129.70.45.10]:38946 "EHLO smtp.math.uni-bielefeld.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbdCOMdV (ORCPT ); Wed, 15 Mar 2017 08:33:21 -0400 Subject: Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form To: Andrzej Hajda , Krzysztof Kozlowski Cc: Inki Dae , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , David Airlie , Kukjin Kim , Javier Martinez Canillas , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20170314183804.13788-1-krzk@kernel.org> <20170314190859.y55wlc4z7xdsbbxg@kozik-lap> <20170314195240.gj7jbgql7hfziw42@kozik-lap> From: Tobias Jakobi Message-ID: Date: Wed, 15 Mar 2017 13:33:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3167 Lines: 82 Hello Andrzej, note that i had already pointed Krzysztof to that documentation in my previous mail. - Tobias Andrzej Hajda wrote: > Hi Tobias, > > On 14.03.2017 21:41, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >>>> Krzysztof Kozlowski wrote: >>>>> On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >>>>>> Hello Krzysztof, >>>>>> >>>>>> I was wondering about the benefit of this. From a quick look these are >>>>>> all messages that end up in the kernel log / dmesg. >>>>>> >>>>>> IIRC %pK does nothing there, since dmest_restrict is supposed to be used >>>>>> to deny an unpriviliged user the access to the kernel log. >>>>>> >>>>>> Or am I missing something here? >>>>> These are regular printks so depending on kernel options (e.g. dynamic >>>>> debug, drm.debug) these might be printed also in the console. Of course >>>>> we could argue then if access to one of the consoles is worth >>>>> securing. >>>> This here suggests otherwise. >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 >>>> >>>> I have not tested this, but IIRC %pK is not honored by the kernel >>>> logging infrastucture. That's why dmesg_restrict is there. >>>> >>>> Correct me if I'm wrong. >>> The %pK will not help for dmesg or /proc/kmsg but it will help for >>> console (/dev/ttySACN, ttySN etc) because effectively it uses the same >>> vsprintf()/pointer() functions. >> Thanks for the explanation, I didn't know that there was a difference >> there. In that case, looks good to me. >> >> > > Just to clarify %pK: > > Documentation/printk-formats.txt: > %pK 0x01234567 or 0x0123456789abcdef > > For printing kernel pointers which should be hidden from > unprivileged > users. The behaviour of %pK depends on the kptr_restrict sysctl > - see > Documentation/sysctl/kernel.txt for more details. > > Documentation/sysctl/kernel.txt: > > kptr_restrict: > > This toggle indicates whether restrictions are placed on > exposing kernel addresses via /proc and other interfaces. > > When kptr_restrict is set to (0), the default, there are no restrictions. > > When kptr_restrict is set to (1), kernel pointers printed using the %pK > format specifier will be replaced with 0's unless the user has CAP_SYSLOG > and effective user and group ids are equal to the real ids. This is > because %pK checks are done at read() time rather than open() time, so > if permissions are elevated between the open() and the read() (e.g via > a setuid binary) then %pK will not leak kernel pointers to unprivileged > users. Note, this is a temporary solution only. The correct long-term > solution is to do the permission checks at open() time. Consider removing > world read permissions from files that use %pK, and using dmesg_restrict > to protect against uses of %pK in dmesg(8) if leaking kernel pointer > values to unprivileged users is a concern. > > When kptr_restrict is set to (2), kernel pointers printed using > %pK will be replaced with 0's regardless of privileges. > --- > > Regards > Andrzej >