[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJ629rrEuQX1MSiqM2SvhCSmZYuNZdOA4zBr5GZHtFcuw@mail.gmail.com>
Date: Fri, 17 Feb 2012 15:36:09 -0800
From: Kees Cook <keescook@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>,
Rik van Riel <riel@...hat.com>, Federica Teodori <federica.teodori@...glemail.com>,
Lucian Adrian Grijincu <lucian.grijincu@...il.com>, Ingo Molnar <mingo@...e.hu>,
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.2] fs: symlink restrictions on sticky directories
On Fri, Feb 17, 2012 at 3:24 PM, Andrew Morton
<akpm@...ux-foundation.org> wrote:
> On Sat, 7 Jan 2012 10:55:48 -0800
> Kees Cook <keescook@...omium.org> wrote:
>
>> A long-standing class of security issues is the symlink-based
>> time-of-check-time-of-use race, most commonly seen in world-writable
>> directories like /tmp. The common method of exploitation of this flaw
>> is to cross privilege boundaries when following a given symlink (i.e. a
>> root process follows a symlink belonging to another user). For a likely
>> incomplete list of hundreds of examples across the years, please see:
>> http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
>>
>> The solution is to permit symlinks to only be followed when outside
>> a sticky world-writable directory, or when the uid of the symlink and
>> follower match, or when the directory owner matches the symlink's owner.
>>
>> Some pointers to the history of earlier discussion that I could find:
>>
>> 1996 Aug, Zygo Blaxell
>> http://marc.info/?l=bugtraq&m=87602167419830&w=2
>> 1996 Oct, Andrew Tridgell
>> http://lkml.indiana.edu/hypermail/linux/kernel/9610.2/0086.html
>> 1997 Dec, Albert D Cahalan
>> http://lkml.org/lkml/1997/12/16/4
>> 2005 Feb, Lorenzo Hern__ndez Garc__a-Hierro
>> http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1896.html
>> 2010 May, Kees Cook
>> https://lkml.org/lkml/2010/5/30/144
>>
>> Past objections and rebuttals could be summarized as:
>>
>> - Violates POSIX.
>> - POSIX didn't consider this situation and it's not useful to follow
>> a broken specification at the cost of security.
>> - Might break unknown applications that use this feature.
>> - Applications that break because of the change are easy to spot and
>> fix. Applications that are vulnerable to symlink ToCToU by not having
>> the change aren't. Additionally, no applications have yet been found
>> that rely on this behavior.
>> - Applications should just use mkstemp() or O_CREATE|O_EXCL.
>> - True, but applications are not perfect, and new software is written
>> all the time that makes these mistakes; blocking this flaw at the
>> kernel is a single solution to the entire class of vulnerability.
>> - This should live in the core VFS.
>> - This should live in an LSM. (https://lkml.org/lkml/2010/5/31/135)
>> - This should live in an LSM.
>> - This should live in the core VFS. (https://lkml.org/lkml/2010/8/2/188)
>>
>> This patch is based on the patch in Openwall and grsecurity, along with
>> suggestions from Al Viro. I have added a sysctl to enable the protected
>> behavior, documentation, and an audit notification.
>
> Looks reasonable to me.
>
> It's a viropatch. I shall merge it into 3.4-rc1 if nothing happens to
> prevent that.
Thanks!
>> +config PROTECTED_STICKY_SYMLINKS
>> + bool "Evaluate vulnerable symlink conditions"
>> + default y
>> + help
>> + A long-standing class of security issues is the symlink-based
>> + time-of-check-time-of-use race, most commonly seen in
>> + world-writable directories like /tmp. The common method of
>> + exploitation of this flaw is to cross privilege boundaries
>> + when following a given symlink (i.e. a root process follows
>> + a malicious symlink belonging to another user).
>> +
>> + Enabling this adds the logic to examine these dangerous symlink
>> + conditions. Whether or not the dangerous symlink situations are
>> + allowed is controlled by PROTECTED_STICKY_SYMLINKS_ENABLED.
>> +
>> +config PROTECTED_STICKY_SYMLINKS_ENABLED
>> + depends on PROTECTED_STICKY_SYMLINKS
>> + bool "Disallow symlink following in sticky world-writable dirs"
>> + default y
>> + help
>> + Solve ToCToU symlink race vulnerablities by permitting symlinks
>> + to be followed only when outside a sticky world-writable directory,
>> + or when the uid of the symlink and follower match, or when the
>> + directory and symlink owners match.
>> +
>> + When PROC_SYSCTL is enabled, this setting can also be controlled
>> + via /proc/sys/kernel/protected_sticky_symlinks.
>
> I think I disagree with this. If the person compiling the kernel
> includes the feature in his kernel via the time-honoured process of
> "wtf is that thing? Yeah, whatev", it gets turned on by default. This
> could easily result in weird failures which would take a *long* time
> for an unsuspecting person to debug.
>
> Would it not be kinder to our users to start this out as
> turned-off-at-runtime unless the kernel configurer has deliberately
> gone in and enabled it?
There was a fair bit of back-and-forth discussion about it.
Originally, I had it disabled, but, IIRC, Ingo urged me to have it be
the default. I can sent a patch to disable it if you want.
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -109,6 +109,9 @@ extern int sysctl_nr_trim_pages;
>> #ifdef CONFIG_BLOCK
>> extern int blk_iopoll_enabled;
>> #endif
>> +#ifdef CONFIG_PROTECTED_STICKY_SYMLINKS
>> +extern int sysctl_protected_sticky_symlinks;
>> +#endif
>>
>
> Grumble. Yes, it's a site of much badness. Let's not worsen things.
>
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: fs-symlink-restrictions-on-sticky-directories-fix
>
> move sysctl_protected_sticky_symlinks declaration into .h
>
> Cc: Kees Cook <keescook@...omium.org>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>
> --- a/kernel/sysctl.c~fs-symlink-restrictions-on-sticky-directories-fix
> +++ a/kernel/sysctl.c
> @@ -109,9 +109,6 @@ extern int sysctl_nr_trim_pages;
> #ifdef CONFIG_BLOCK
> extern int blk_iopoll_enabled;
> #endif
> -#ifdef CONFIG_PROTECTED_STICKY_SYMLINKS
> -extern int sysctl_protected_sticky_symlinks;
> -#endif
>
> /* Constants used for minimum and maximum */
> #ifdef CONFIG_LOCKUP_DETECTOR
> --- a/include/linux/fs.h~fs-symlink-restrictions-on-sticky-directories-fix
> +++ a/include/linux/fs.h
> @@ -422,6 +422,7 @@ extern unsigned long get_max_files(void)
> extern int sysctl_nr_open;
> extern struct inodes_stat_t inodes_stat;
> extern int leases_enable, lease_break_time;
> +extern int sysctl_protected_sticky_symlinks;
>
> struct buffer_head;
> typedef int (get_block_t)(struct inode *inode, sector_t iblock,
Ah, sure. That works for me. Thanks!
-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.
