linux-kernel - Re: [RFCv2][PATCH 1/2] fs proc: make pagemap a privileged interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55083F8C.3060601@sr71.net>
Date:	Tue, 17 Mar 2015 07:51:56 -0700
From:	Dave Hansen <dave@...1.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>, tytso@....edu,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	dave.hansen@...ux.intel.com,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>
Subject: Re: [RFCv2][PATCH 1/2] fs proc: make pagemap a privileged interface

On 03/17/2015 06:04 AM, Eric W. Biederman wrote:
> Dave Hansen <dave@...1.net> writes:
> 
>> From: Dave Hansen <dave.hansen@...ux.intel.com>
>>
>> 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" <ebiederm@...ssion.com>
> 
> 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 <segooon@...il.com>
> Date:   Tue Jan 10 15:11:31 2012 -0800
> 
>     procfs: add hidepid= and gid= mount options

was inappropriate.

> 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.

> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/