From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753337AbbCIWRj (ORCPT ); Mon, 9 Mar 2015 18:17:39 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:54596 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750933AbbCIWRf (ORCPT ); Mon, 9 Mar 2015 18:17:35 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Dave Hansen Cc: Andrew Morton , Kees Cook , tytso@mit.edu, Oleg Nesterov , linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com References: <20150309204321.AAF412E0@viggo.jf.intel.com> Date: Mon, 09 Mar 2015 17:13:55 -0500 In-Reply-To: <20150309204321.AAF412E0@viggo.jf.intel.com> (Dave Hansen's message of "Mon, 09 Mar 2015 13:43:21 -0700") Message-ID: <878uf5vmxo.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1/+zgdDGqFayoUhfsjQJ5q7WCi0qwvxNe4= X-SA-Exim-Connect-IP: 70.59.163.10 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Dave Hansen X-Spam-Relay-Country: X-Spam-Timing: total 370 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 7 (2.0%), b_tie_ro: 6 (1.7%), parse: 1.17 (0.3%), extract_message_metadata: 21 (5.6%), get_uri_detail_list: 2.6 (0.7%), tests_pri_-1000: 12 (3.4%), tests_pri_-950: 1.33 (0.4%), tests_pri_-900: 1.11 (0.3%), tests_pri_-400: 34 (9.3%), check_bayes: 33 (8.9%), b_tokenize: 7 (1.9%), b_tok_get_all: 12 (3.2%), b_comp_prob: 4.0 (1.1%), b_tok_touch_all: 6 (1.7%), b_finish: 0.74 (0.2%), tests_pri_0: 284 (76.8%), tests_pri_500: 3.7 (1.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen writes: > From: Dave Hansen > > Physical addresses are sensitive information. There are > existing, known exploits that are made easier if physical > information is available. Here is one example: > > http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf > > If you know the physical address of something you also know at > which kernel virtual address you can find something (modulo > highmem). It means that things that keep the kernel from > accessing user mappings (like SMAP/SMEP) can be worked around > because the _kernel_ mapping can get used instead. > > But, /proc/$pid/pagemap exposes the physical addresses of all > pages accessible to userspace. This works against all of the > efforts to keep kernel addresses out of places where unprivileged > apps can find them. > > This patch introduces a "paranoid" option for /proc. It can be > enabled like this: > > mount -o remount,paranoid /proc > > Or when /proc is mounted initially. When 'paranoid' mode is > active, opens to /proc/$pid/pagemap will return -EPERM for users > without CAP_SYS_RAWIO. It can be disabled like this: > > mount -o remount,notparanoid /proc > > The option is applied to the pid namespace, so an app that wanted > a separate policy from the rest of the system could get run in > its own pid namespace. > > I'm not really that stuck on the name. I'm not opposed to making > it apply only to pagemap or to giving it a pagemap-specific > name. > > pagemap is also the kind of feature that could be used to escalate > privileged from root in to the kernel. It probably needs to be > protected in the same way that /dev/mem or module loading is in > cases where the kernel needs to be protected from root, thus the > choice to use CAP_SYS_RAWIO. There is already a way to make pagemap go away. It is called CONFIG_PROC_PAGE_MONITOR. I suspect the right answer here is if you enable kernel address randomization you disable CONFIG_PROC_PAGE_MONTIOR. Aka you make the two options conflict with each other. That is a lot less code and a lot less to maintain. On the other hand if this is truly a valuable interface that you can't part with we need an alternative to pagemaps that does the same job with out the exploit potential. And I don't how to do that. Arguing in favor of just making the options conflict is the fact that kernel address randomization is pretty much snake oil. At least on x86_64 the address pool is so small it can be trivially brute forced. I think there are maybe 10 bits you can randomize within. As for a way to disable this I expect it would do better with something like a set once flag that prevents a process and all of it's children from accessing this file. *Blink* *Blink* Did you say you are worried about escalting privileges from root into the kernel space. That is non-sense. We give root the power to shot themselves in the foot and any proc option will be something that root will be able to get around. The pieces of the patch description don't add up. Nacked-by: "Eric W. Biederman" Eric