From: Dave Hansen <dave@sr71.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
tytso@mit.edu, Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface
Date: Fri, 13 Mar 2015 08:56:15 -0700 [thread overview]
Message-ID: <5503089F.9000405@sr71.net> (raw)
In-Reply-To: <20150312153533.d1c6083e4a9e7825b1a4bc64@linux-foundation.org>
On 03/12/2015 03:35 PM, Andrew Morton wrote:
> On Mon, 09 Mar 2015 13:43:21 -0700 Dave Hansen <dave@sr71.net> wrote:
>> From: Dave Hansen <dave.hansen@linux.intel.com>
>>
>> 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?
>> 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.
next prev parent reply other threads:[~2015-03-13 15:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150309204321.AAF412E0@viggo.jf.intel.com>
2015-03-09 21:31 ` [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface Kees Cook
[not found] ` <20150309204322.50DA6B5D@viggo.jf.intel.com>
2015-03-09 21:32 ` [RFC][PATCH 2/2] proc: config options for making privileged /proc the default Kees Cook
2015-03-09 22:13 ` [RFC][PATCH 1/2] fs proc: make pagemap a privileged interface Eric W. Biederman
2015-03-09 22:22 ` Kees Cook
2015-03-09 23:08 ` Eric W. Biederman
2015-03-09 23:40 ` Kees Cook
2015-03-09 23:43 ` Eric W. Biederman
2015-03-10 0:03 ` Kees Cook
2015-03-10 2:51 ` Dave Hansen
2015-03-10 4:49 ` Eric W. Biederman
2015-03-10 2:28 ` Dave Hansen
2015-03-12 22:35 ` Andrew Morton
2015-03-13 15:56 ` Dave Hansen [this message]
2015-03-13 17:16 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5503089F.9000405@sr71.net \
--to=dave@sr71.net \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).