linux-kernel - Re: [PATCH v2012.1] fs: symlink restrictions on sticky directories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Jan 2012 10:43:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kees Cook <keescook@...omium.org>, 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>,
	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


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > +config PROTECTED_STICKY_SYMLINKS
> > +	bool "Protect symlink following in sticky world-writable directories"
> > +	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 solves the problem 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.
> 
> This is all quite misleading.  One would expect that 
> CONFIG_PROTECTED_STICKY_SYMLINKS turns the entire feature on 
> or off permanently.  ie, it controls whether the code is 
> generated into vmlinux in the usual fashion.  But it's not 
> that at all - the user gets the feature whether or not he 
> wants it, and this variable only sets the initial value.
> 
> Why are we forcing the user to have the feature if he doesn't 
> want it, btw?

Basing on the (not yet fully confirmed) assertion that no apps 
are broken by this change but exploits, I'd argue that this is 
actually the sane and correct semantics for symlinks - i.e. we 
want this to be the default Linux behavior - not just a 
'feature'.

That way the configuration knobs are compat settings in essence 
- in case some app cares.

If people disagree and want it default off and as a separate 
feature then it has to be modularized out some more. There's 
notable silence from VFS folks on all this so Kees made an 
educated guess. It might be wrong.

> And we appear to be enabling the feature if CONFIG_PROC_FS=n, 
> which might not be terribly useful?

It can still be useful if it's default on - just cannot be 
turned off via /proc/sys/, right?

The combination that is not so useful is when it's off and 
there's !PROC_FS. If it's a compat feature then i wouldnt bother 
about it. If it's a separated out modular feature in a separate 
.c file then it can all be properly shaped via Kconfig 
dependencies.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/