From: "Roberts, William C" <william.c.roberts@intel.com> To: Kees Cook <keescook@chromium.org> Cc: "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Jonathan Corbet <corbet@lwn.net>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Dave Weinstein <olorin@google.com> Subject: RE: [PATCH] printk: introduce kptr_restrict level 3 Date: Thu, 6 Oct 2016 13:17:11 +0000 [thread overview] Message-ID: <476DC76E7D1DF2438D32BFADF679FC561CD1458F@ORSMSX103.amr.corp.intel.com> (raw) In-Reply-To: <CAGXu5j+EtVPabrwPXU0W8yJ5Fg0H0Nc6aPjJqqNOSx+m+TBu2Q@mail.gmail.com> > -----Original Message----- > From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees > Cook > Sent: Wednesday, October 5, 2016 3:34 PM > To: Roberts, William C <william.c.roberts@intel.com> > Cc: kernel-hardening@lists.openwall.com; Jonathan Corbet <corbet@lwn.net>; > linux-doc@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Nick > Desaulniers <ndesaulniers@google.com>; Dave Weinstein <olorin@google.com> > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3 > > On Wed, Oct 5, 2016 at 11:04 AM, <william.c.roberts@intel.com> wrote: > > From: William Roberts <william.c.roberts@intel.com> > > > > Some out-of-tree modules do not use %pK and just use %p, as it's the > > common C paradigm for printing pointers. Because of this, > > kptr_restrict has no affect on the output and thus, no way to contain > > the kernel address leak. > > Solving this is certainly a good idea -- I'm all for finding a solid solution. > > > Introduce kptr_restrict level 3 that causes the kernel to treat %p as > > if it was %pK and thus always prints zeros. > > I'm worried that this could break kernel internals where %p is being used and not > exposed to userspace. Maybe those situations don't exist... Not saying they don't I didn't find any. > > Regardless, I would rather do what Grsecurity has done in this area, and whitelist > known-safe values instead. For example, they have %pP for approved pointers, > and %pX for approved > dereference_function_descriptor() output. Everything else is censored if it is a > value in kernel memory and destined for a user-space memory > buffer: > > if ((unsigned long)ptr > TASK_SIZE && *fmt != 'P' && *fmt != 'X' && *fmt != > 'K' && is_usercopy_object(buf)) { > printk(KERN_ALERT "grsec: kernel infoleak detected! > Please report this log to spender@grsecurity.net.\n"); > dump_stack(); > ptr = NULL; > } > > The "is_usercopy_object()" test is something we can add, which is testing for a > new SLAB flag that is used to mark slab caches as either used by user-space or > not, which is done also through whitelisting. > (For more details on this, see: > http://www.openwall.com/lists/kernel-hardening/2016/06/08/10) > > Would you have time/interest to add the slab flags and is_usercopy_object()? > The hardened usercopy part of the slab whitelisting can be separate, since it likely > needs a different usercopy interface to sanely integrate with upstream. I could likely take this on. I would need to read up on the links and have a better concept of what it is. > > -Kees > > -- > Kees Cook > Nexus Security
WARNING: multiple messages have this Message-ID (diff)
From: "Roberts, William C" <william.c.roberts@intel.com> To: Kees Cook <keescook@chromium.org> Cc: "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Jonathan Corbet <corbet@lwn.net>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Dave Weinstein <olorin@google.com> Subject: [kernel-hardening] RE: [PATCH] printk: introduce kptr_restrict level 3 Date: Thu, 6 Oct 2016 13:17:11 +0000 [thread overview] Message-ID: <476DC76E7D1DF2438D32BFADF679FC561CD1458F@ORSMSX103.amr.corp.intel.com> (raw) In-Reply-To: <CAGXu5j+EtVPabrwPXU0W8yJ5Fg0H0Nc6aPjJqqNOSx+m+TBu2Q@mail.gmail.com> > -----Original Message----- > From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees > Cook > Sent: Wednesday, October 5, 2016 3:34 PM > To: Roberts, William C <william.c.roberts@intel.com> > Cc: kernel-hardening@lists.openwall.com; Jonathan Corbet <corbet@lwn.net>; > linux-doc@vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Nick > Desaulniers <ndesaulniers@google.com>; Dave Weinstein <olorin@google.com> > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3 > > On Wed, Oct 5, 2016 at 11:04 AM, <william.c.roberts@intel.com> wrote: > > From: William Roberts <william.c.roberts@intel.com> > > > > Some out-of-tree modules do not use %pK and just use %p, as it's the > > common C paradigm for printing pointers. Because of this, > > kptr_restrict has no affect on the output and thus, no way to contain > > the kernel address leak. > > Solving this is certainly a good idea -- I'm all for finding a solid solution. > > > Introduce kptr_restrict level 3 that causes the kernel to treat %p as > > if it was %pK and thus always prints zeros. > > I'm worried that this could break kernel internals where %p is being used and not > exposed to userspace. Maybe those situations don't exist... Not saying they don't I didn't find any. > > Regardless, I would rather do what Grsecurity has done in this area, and whitelist > known-safe values instead. For example, they have %pP for approved pointers, > and %pX for approved > dereference_function_descriptor() output. Everything else is censored if it is a > value in kernel memory and destined for a user-space memory > buffer: > > if ((unsigned long)ptr > TASK_SIZE && *fmt != 'P' && *fmt != 'X' && *fmt != > 'K' && is_usercopy_object(buf)) { > printk(KERN_ALERT "grsec: kernel infoleak detected! > Please report this log to spender@grsecurity.net.\n"); > dump_stack(); > ptr = NULL; > } > > The "is_usercopy_object()" test is something we can add, which is testing for a > new SLAB flag that is used to mark slab caches as either used by user-space or > not, which is done also through whitelisting. > (For more details on this, see: > http://www.openwall.com/lists/kernel-hardening/2016/06/08/10) > > Would you have time/interest to add the slab flags and is_usercopy_object()? > The hardened usercopy part of the slab whitelisting can be separate, since it likely > needs a different usercopy interface to sanely integrate with upstream. I could likely take this on. I would need to read up on the links and have a better concept of what it is. > > -Kees > > -- > Kees Cook > Nexus Security
next prev parent reply other threads:[~2016-10-06 13:17 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-05 18:04 [PATCH] printk: introduce kptr_restrict level 3 william.c.roberts 2016-10-05 18:04 ` [kernel-hardening] " william.c.roberts 2016-10-05 19:34 ` Kees Cook 2016-10-05 19:34 ` [kernel-hardening] " Kees Cook 2016-10-06 13:17 ` Roberts, William C [this message] 2016-10-06 13:17 ` [kernel-hardening] " Roberts, William C 2016-10-06 15:18 ` Roberts, William C 2016-10-06 21:04 ` [kernel-hardening] " Kees Cook 2016-10-07 14:19 ` [kernel-hardening] " Roberts, William C 2016-10-07 14:29 ` Jann Horn 2016-10-07 15:05 ` Roberts, William C 2016-10-07 15:15 ` Jann Horn 2016-10-07 19:12 ` Kees Cook 2016-10-11 18:11 ` Roberts, William C 2016-10-05 20:52 ` Rasmus Villemoes 2016-10-05 20:52 ` [kernel-hardening] " Rasmus Villemoes 2016-10-06 13:23 ` Roberts, William C 2016-10-06 13:23 ` [kernel-hardening] " Roberts, William C 2016-10-06 13:31 ` Christoph Hellwig 2016-10-06 13:31 ` [kernel-hardening] " Christoph Hellwig 2016-10-06 13:47 ` Roberts, William C 2016-10-06 13:47 ` [kernel-hardening] " Roberts, William C 2016-10-06 13:56 ` Christoph Hellwig 2016-10-06 13:56 ` [kernel-hardening] " Christoph Hellwig 2016-10-06 14:59 ` Roberts, William C 2016-10-06 14:59 ` [kernel-hardening] " Roberts, William C 2016-10-06 21:00 ` Kees Cook 2016-10-06 21:00 ` [kernel-hardening] " Kees Cook 2016-10-06 21:19 ` Joe Perches 2016-10-06 21:19 ` [kernel-hardening] " Joe Perches 2016-10-06 21:25 ` Kees Cook 2016-10-06 21:25 ` [kernel-hardening] " Kees Cook 2016-10-07 14:21 ` Roberts, William C 2016-10-07 14:21 ` [kernel-hardening] " Roberts, William C 2016-10-06 14:05 ` Jann Horn 2016-10-06 14:05 ` Jann Horn 2016-10-06 14:46 ` Jann Horn 2016-10-06 14:46 ` Jann Horn 2016-10-07 11:52 ` Jann Horn 2016-10-07 11:52 ` Jann Horn
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=476DC76E7D1DF2438D32BFADF679FC561CD1458F@ORSMSX103.amr.corp.intel.com \ --to=william.c.roberts@intel.com \ --cc=corbet@lwn.net \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ndesaulniers@google.com \ --cc=olorin@google.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.