From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753202AbbCQS2K (ORCPT ); Tue, 17 Mar 2015 14:28:10 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:50896 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752574AbbCQS2H (ORCPT ); Tue, 17 Mar 2015 14:28:07 -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, "Serge E. Hallyn" References: <20150316230221.DA32D9BE@viggo.jf.intel.com> <87k2yflqqf.fsf@x220.int.ebiederm.org> <55083F8C.3060601@sr71.net> Date: Tue, 17 Mar 2015 13:24:21 -0500 In-Reply-To: <55083F8C.3060601@sr71.net> (Dave Hansen's message of "Tue, 17 Mar 2015 07:51:56 -0700") Message-ID: <878uevjxd6.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+JYPrnC8NtjHxaYFrsgassSbV10GQNUg0= 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 * 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 TVD_RCVD_IP Message was received from an IP address * 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 * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Dave Hansen X-Spam-Relay-Country: X-Spam-Timing: total 535 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.9 (0.5%), b_tie_ro: 2.0 (0.4%), parse: 1.14 (0.2%), extract_message_metadata: 28 (5.3%), get_uri_detail_list: 4.5 (0.8%), tests_pri_-1000: 13 (2.5%), tests_pri_-950: 1.67 (0.3%), tests_pri_-900: 1.48 (0.3%), tests_pri_-400: 33 (6.3%), check_bayes: 32 (6.0%), b_tokenize: 10 (2.0%), b_tok_get_all: 12 (2.3%), b_comp_prob: 3.4 (0.6%), b_tok_touch_all: 3.0 (0.6%), b_finish: 0.67 (0.1%), tests_pri_0: 442 (82.6%), tests_pri_500: 7 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFCv2][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: > On 03/17/2015 06:04 AM, Eric W. Biederman wrote: >> Dave Hansen writes: >> >>> From: Dave Hansen >>> >>> Changes from v1: >>> * Do not allow a child pid namespace to unset paranoid >>> when its parent had it set. >>> * Update description text to clarify the options we >>> have to solve this problem. >> >> Again. >> >> Nacked-by: "Eric W. Biederman" >> >> The option name "paranoid" is entirely too general. Who knows what >> it referrs to. > > /proc exposes a lot of sensitive information that could be used to > determine physical memory ordering (not as bad as actual physical > addresses, but still). My hope was that instead of adding an option for > every single proc file, we'd have a single one that folks could turn on. > > In the end, I'm perfectly fine doing a s/paranoid/pidpagemap/g, I just > wanted to point out that there will may be more patches like this down > the line. > >> A mount option is not an appropriate place to control one small bit of >> policy like this. Proc mount options are a real pain in the butt to >> deal with and to maintain. > > It sounds like you are of the opinion that this commit: > >> commit 0499680a42141d86417a8fbaa8c8db806bea1201 >> Author: Vasiliy Kulikov >> Date: Tue Jan 10 15:11:31 2012 -0800 >> >> procfs: add hidepid= and gid= mount options > > was inappropriate. Actually I am. It is a bloody nightmare to maintain. But at least it deals with the core business of proc. That of displaying processes. >> Further a per pid namespace decision does not actually work, for having >> restricted policy only for a small set of processes because it is only >> with very careful container setup that you would expose this policy. > > I would hope that the folks doing the fancy container setup tools would > add this when they mount the container /proc and care about exposing > physical addresses to it. > > I did model this after the _existing_ /proc options (introduced in the > commit referenced above). Those also use the pid namespace to store > mount options. I assumed they are used out in the real world and that > they do not require any kind of careful container setup. The use cases are enough different it is different. For the hidepid non-sense a small leak doesn't give you much. For the case of restricting pagemap. In many cases even a single leak of a single value means you can infer everything else you want to know. Since a single leak of pagemap gives the game away something that does not restrict on a large basis is a problem. >> If you really need a subset of processes with a restricted policy make >> it a prctl, and bloat struct task. Then disallow a process with the >> prctl set from reading the file. > > Let's say we add the prctl(), and we set it up to block > /proc/$pid/pagemap by default at boot. We run for a couple of weeks and > an (unprivileged) app breaks. With the mount option, an administrator > at least has the option to fall back to a less secure mode for the whole > system with a remount. > > With a prctl(), don't think that would be feasible, short of a reboot. > > Would such a prctl() also have the feature that it could never be set to > a less-restrictive policy? Your choice. For system wide behavior a sysctl or a boot option are likely better. For the case of just enabling this for a pid namespace or a container prctl() seems reasonable. I am a bit puzzled though. I though as part of the kernel virtual address randomization effort we had a bunch of similar patches come through that I could refer you to. But for whatever reason I am not seeing them in the source tree now. If those kinds of changes actually exist that class of blinding might be useful for your changes as well. Eric