[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEiveUeLExH1R+TVO1TRCEVc4RasuPeOFJzg3Kp-rzjit3szPg@mail.gmail.com>
Date: Fri, 6 Oct 2017 09:33:14 +0100
From: Djalal Harouni <tixxdz@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Daniel Micay <danielmicay@...il.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
"Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>,
Jordan Glover <Golden_Miller83@...tonmail.ch>, "Tobin C. Harding" <me@...in.cc>,
Greg KH <gregkh@...uxfoundation.org>, Petr Mladek <pmladek@...e.com>,
Joe Perches <joe@...ches.com>, Ian Campbell <ijc@...lion.org.uk>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>,
Steven Rostedt <rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>,
Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter options
Hi Kees,
On Thu, Oct 5, 2017 at 1:35 AM, Kees Cook <keescook@...omium.org> wrote:
> On Wed, Oct 4, 2017 at 5:29 PM, Daniel Micay <danielmicay@...il.com> wrote:
>> On Wed, 2017-10-04 at 16:52 -0700, Linus Torvalds wrote:
>>> On Wed, Oct 4, 2017 at 2:58 PM, Roberts, William C
>>> <william.c.roberts@...el.com> wrote:
>>> >
>>> > I agree with you 100% kptr restrict is odd, and I don't think anyone
>>> > should have had to opt in to be
>>> > cleansed via kptr_restrict value via %pK. Opt-in never works. One
>>> > nice thing now, is that checkpatch
>>> > has checking of %p usages and warns.
>>>
>>> Yeah, the checkpatch thing may help for future patches.
>>>
>>> > As far as broken things, I can't comment on desktop systems where I
>>> > think it's harder to make that claim.
>>> > I see value in embedded systems where I am shipping the whole image,
>>> > So I know when/what will
>>> > break.
>>> >
>>> > If this was in-tree, Android would be setting this to 4 immediately
>>> > FWIW.
>>>
>>> Does android set it to 2 right now?
>>
>> Yes, as the universal baseline.
>>
>> On Google Pixels it's set to this 4 level since August (Android 8.0)
>> which indicates they plan on moving to that universally.
>
> Yup, which is what triggered working to upstream a solution. (As
> mentioned in the changelogs, this series has gone through a number of
> hands including Intel and Google folks.)
>
>> They only allow dmesg access for core system services so I think their
>> concern is with formatted strings leaking it elsewhere, not to dmesg.
>
> One of the paths is via seq_file and it's many outputs in procfs,
> debugfs, etc etc. The %x issue exists there too, but it's relatively
> rare compared to %p and family.
I think the kptr_restrict solution is not enough since you will have
to continue to track all call sites.
Anyway for procfs as you know Kees, we have patches to modernize it
based on Andy Lutomirski suggestions.
There is this branch [1] that allows only to access pids in
/proc/<pids>/ and block the rest that is kernel data.
It can be used by any sandbox solution to allow glibc and others work
on /proc/self/ access and block the rest, or for other embedded
systems sandboxes.
I updated the patches to post them but there is a bug with some other
kernel changes + dracut that I am still tracking.
[1] https://github.com/legionus/linux/commits/pidfs-v4
--
tixxdz
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
