Date: Thu, 5 Jan 2012 12:55:25 -0800 From: Kees Cook <keescook@...omium.org> To: Nick Bowler <nbowler@...iptictech.com> Cc: linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...ux-foundation.org>, Rik van Riel <riel@...hat.com>, Federica Teodori <federica.teodori@...glemail.com>, Lucian Adrian Grijincu <lucian.grijincu@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Eric Paris <eparis@...hat.com>, Randy Dunlap <rdunlap@...otime.net>, Dan Rosenberg <drosenberg@...curity.com>, linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH v2012.1] fs: symlink restrictions on sticky directories On Thu, Jan 5, 2012 at 12:08 PM, Nick Bowler <nbowler@...iptictech.com> wrote: > On 2012-01-05 11:34 -0800, Kees Cook wrote: >> On Thu, Jan 5, 2012 at 6:30 AM, Nick Bowler <nbowler@...iptictech.com> wrote: >> > On 2012-01-04 12:18 -0800, Kees Cook wrote: >> >> diff --git a/fs/Kconfig b/fs/Kconfig >> >> index 5f4c45d..26ede24 100644 >> >> --- a/fs/Kconfig >> >> +++ b/fs/Kconfig >> >> @@ -278,3 +278,19 @@ source "fs/nls/Kconfig" >> >> source "fs/dlm/Kconfig" >> >> >> >> endmenu >> >> + >> >> +config PROTECTED_STICKY_SYMLINKS >> >> + bool "Protect symlink following in sticky world-writable directories" >> >> + default y >> > [...] >> > >> > Why do we need a config option for this? What's wrong with just using >> > the sysctl? >> >> This way the sysctl can configured directly without needing to have a >> distro add a new item to sysctl.conf. > > This seems totally pointless to me. There are tons of sysctls that > don't have Kconfig options: what makes this one special? Most are system tuning; this is directly related to vulnerability mitigation. Besides, I like having CONFIGs for sysctls because then I can build my kernel the way I want it without having to worry about tweaking my userspace sysctl.conf file, or run newer kernels on older userspaces, etc etc. >> > Why have you made this option "default y", when enabling it clearly >> > makes user-visible changes to kernel behaviour? >> >> Ingo specifically asked me to make it "default y". > > But this is a brand new feature that changes longstanding behaviour of > various syscalls. Making it default to enabled is rather mean to users > (since it will tend to get enabled by "oldconfig") and seems almost > guaranteed to cause regressions. I couldn't disagree more. There has been zero evidence of this change causing anything but regressions in _attacks_. :P If anything, I think there should be no CONFIG and no sysctl, and it should be entirely non-optional. But since this patch needs consensus, I have provided knobs to control it. This is the way of security features. For example, years back I added a knob for /proc/$pid/maps protection being optional (and defaulted it to insecure because of people's fear of regression), and eventually it changed to secure-by-default, and then the knob went away completely because it didn't actually cause problems. -Kees -- Kees Cook ChromeOS Security
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.