[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1507163355.1273.63.camel@gmail.com>
Date: Wed, 04 Oct 2017 20:29:15 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>, "Roberts, William C"
<william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>
Cc: 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
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.
They only allow dmesg access for core system services so I think their
concern is with formatted strings leaking it elsewhere, not to dmesg.
These are the only services they allow to read dmesg:
private/system_server.te: allow system_server kernel:system syslog_read;
public/dumpstate.te:allow dumpstate kernel:system syslog_read;
public/init.te:allow init kernel:system syslog_read;
public/logd.te:allow logd kernel:system syslog_read;
public/recovery.te: allow recovery kernel:system syslog_read;
logd doesn't read it in production builds, but even when it does in
engineering builds it only gives out access to privileged apps with
READ_LOGS which isn't something a third party app can obtain.
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.
