Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 12:13 PM, Jann Horn wrote: > > Actually, /proc/kallsyms uses %pK, which hacks around this issue > by checking for `euid != uid` in addition to the capability check - so this > isn't exploitable through a typical setuid program. Fair enough, you'd have to

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 12:13 PM, Jann Horn wrote: > > Actually, /proc/kallsyms uses %pK, which hacks around this issue > by checking for `euid != uid` in addition to the capability check - so this > isn't exploitable through a typical setuid program. Fair enough, you'd have to be a pretty broken

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 7:28 PM, Linus Torvalds wrote: > On Wed, Oct 4, 2017 at 10:08 AM, Linus Torvalds > wrote: >> >> So I honestly doubt the value of kptr_restrict. Any *sane* policy >> pretty much has to be in the caller, and by

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 7:28 PM, Linus Torvalds wrote: > On Wed, Oct 4, 2017 at 10:08 AM, Linus Torvalds > wrote: >> >> So I honestly doubt the value of kptr_restrict. Any *sane* policy >> pretty much has to be in the caller, and by thinking about what you >> print out. IOW, things like

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 10:08 AM, Linus Torvalds wrote: > > So I honestly doubt the value of kptr_restrict. Any *sane* policy > pretty much has to be in the caller, and by thinking about what you > print out. IOW, things like proc_pid_wchan(). Looking at

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 10:08 AM, Linus Torvalds wrote: > > So I honestly doubt the value of kptr_restrict. Any *sane* policy > pretty much has to be in the caller, and by thinking about what you > print out. IOW, things like proc_pid_wchan(). Looking at /proc/kallsyms is actually a prime example

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 9:42 AM, Kees Cook wrote: > > I'd argue that a default of "1" would be a sensible starting place, > but that can be a separate patch, IMO. I agree that '1' is a much saner default for _some_ uses, in that it still gives root access to /proc file data

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Wed, Oct 4, 2017 at 9:42 AM, Kees Cook wrote: > > I'd argue that a default of "1" would be a sensible starting place, > but that can be a separate patch, IMO. I agree that '1' is a much saner default for _some_ uses, in that it still gives root access to /proc file data etc. However, the sad

RE: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

Deacon <will.dea...@arm.com>; > Steven Rostedt <rost...@goodmis.org>; Roberts, William C > <william.c.robe...@intel.com>; Chris Fries <cfr...@google.com>; Dave Weinstein > <olo...@google.com>; Linus Torvalds <torva...@linux-foundation.org> > Subject

RE: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

atsky ; kernel- > harden...@lists.openwall.com; LKML ; Catalin > Marinas ; Will Deacon ; > Steven Rostedt ; Roberts, William C > ; Chris Fries ; Dave Weinstein > ; Linus Torvalds > Subject: Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default > kptr_restrict to > the maximum val

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Sat, Sep 30, 2017 at 5:06 PM, Tobin C. Harding wrote: > Set the initial value of kptr_restrict to the maximum > setting rather than the minimum setting, to ensure that > early boot logging is not leaking information. > > Signed-off-by: Tobin C. Harding > --- >

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Sat, Sep 30, 2017 at 5:06 PM, Tobin C. Harding wrote: > Set the initial value of kptr_restrict to the maximum > setting rather than the minimum setting, to ensure that > early boot logging is not leaking information. > > Signed-off-by: Tobin C. Harding > --- > lib/vsprintf.c | 2 +- > 1 file

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Sun, Oct 01, 2017 at 11:06:48AM +1100, Tobin C. Harding wrote: > Set the initial value of kptr_restrict to the maximum > setting rather than the minimum setting, to ensure that > early boot logging is not leaking information. > > Signed-off-by: Tobin C. Harding Signed-off-by:

Re: [kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

On Sun, Oct 01, 2017 at 11:06:48AM +1100, Tobin C. Harding wrote: > Set the initial value of kptr_restrict to the maximum > setting rather than the minimum setting, to ensure that > early boot logging is not leaking information. > > Signed-off-by: Tobin C. Harding Signed-off-by: Greg

[kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Signed-off-by: Tobin C. Harding --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[kernel-hardening] [RFC V2 4/6] lib: vsprintf: default kptr_restrict to the maximum value

Set the initial value of kptr_restrict to the maximum setting rather than the minimum setting, to ensure that early boot logging is not leaking information. Signed-off-by: Tobin C. Harding --- lib/vsprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/vsprintf.c