From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755560AbbCMRUt (ORCPT ); Fri, 13 Mar 2015 13:20:49 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:38526 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbbCMRUo (ORCPT ); Fri, 13 Mar 2015 13:20:44 -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 References: <20150309204321.AAF412E0@viggo.jf.intel.com> <20150312153533.d1c6083e4a9e7825b1a4bc64@linux-foundation.org> <5503089F.9000405@sr71.net> Date: Fri, 13 Mar 2015 12:16:48 -0500 In-Reply-To: <5503089F.9000405@sr71.net> (Dave Hansen's message of "Fri, 13 Mar 2015 08:56:15 -0700") Message-ID: <87a8zgu8an.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+Jfhq/dmxieRaCnemqeVa1zfKfoQkAdqo= 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 * 0.7 XMSubLong Long Subject * 1.5 TR_Symld_Words too many words that have symbols inside * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Dave Hansen X-Spam-Relay-Country: X-Spam-Timing: total 14664 ms - load_scoreonly_sql: 0.10 (0.0%), signal_user_changed: 4.0 (0.0%), b_tie_ro: 2.8 (0.0%), parse: 0.96 (0.0%), extract_message_metadata: 37 (0.3%), get_uri_detail_list: 3.2 (0.0%), tests_pri_-1000: 8 (0.1%), tests_pri_-950: 1.81 (0.0%), tests_pri_-900: 1.42 (0.0%), tests_pri_-400: 27 (0.2%), check_bayes: 26 (0.2%), b_tokenize: 8 (0.1%), b_tok_get_all: 8 (0.1%), b_comp_prob: 3.6 (0.0%), b_tok_touch_all: 3.2 (0.0%), b_finish: 0.93 (0.0%), tests_pri_0: 268 (1.8%), tests_pri_500: 14310 (97.6%), poll_dns_idle: 14286 (97.4%), 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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen writes: > On 03/12/2015 03:35 PM, Andrew Morton wrote: >> On Mon, 09 Mar 2015 13:43:21 -0700 Dave Hansen wrote: >>> 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 >> Do we really need to disable pagemap entirely? What happens if we just >> obscure the addresses (ie: zero them)? > > I think we have 3 basic options: > > 1. Disable it entirely (-EPERM or whatever). Apps using it break > quickly and fairly obviously (diagnosable with an strace) > 2. Zero it, or return some nonsensical thing for the physical address > portion, but maintain exporting the PTE flags. Apps only caring > about PTE flags work, but anything trying to do lookups in > /proc/kpageflags break. If we zero it, apps pay get confused > thinking they have the _actual_ pfn=0. > 3. Scramble it in some way obscuring the physical address. Unscramble > it upon access to /proc/kpageflags. > > I think you're suggesting (2). Doesn't that risk silently breaking > apps? I think 3 where the scramble is something like AES crypto is likely to scramble this well and still protect us from plain text attacks. >>> 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. >> >> Confused. If you have root, you can do mount -o notparanoid. > > Good point. I guess it doesn't protect us much here unless we also > restrict the ability to remount. And the ability to unmount... A write-once sysctl or a boot time only parameter is much more likely to be useful in the scenario where you are concerned about root. Eric