Date:	Wed, 7 Dec 2011 10:54:55 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-doc@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	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>,
	Dan Rosenberg <drosenberg@...curity.com>,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2011.1] fs: symlink restrictions on sticky directories

On Wed, Dec 7, 2011 at 10:41 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Dec 6, 2011 at 3:58 PM, 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.
>
> Ugh. I really dislike the implementation.
>
> Wouldn't it be much nicer to instead actually use the symlink
> protection fields, and make the rules be:
>
>  - creating a symlink as root does the traditional "lrwxrwxrwx" thing
>  - creating a symlink in a directory you own similarly does "lrwxrwxrwx"
>  - creating a symlink anywhere else (which implies either sticky or
> world-writable directory) does "lrwx------", so only you can use it.
>
> That seems to be much nicer semantics, and makes the protection
> *visible* instead of some kind of hacky run-time random behavior
> depending on some invisible config option that people aren't even
> aware of.
>
> Of course, it needs to handle renames too (and maybe lchown?), and it
> would still need to be an option you enable explicitly, but it seems
> much more polite to make things like this something you can actually
> see.
>
> No, I have not thought this through deeply, but I really dislike your
> kind of "change random semantics in ways that are very hidden and
> subtle". The symlink protection approach seems to be much less hidden
> and subtle, and should result in largely the same result.
>
> Notably, you can install a system without it on, and turn it on even
> after install - who cares if there are *long-term* symlinks with
> lrwxrwxrwx and that thus allow all access, it's the racily-created
> ones we need to worry about, so it should actually be perfectly ok to
> enable the symlink creation protection dynamically. In fact, it could
> be a inheritable per-*process* (or per-container) flag rather than a
> global flag that says how symlink creation acts.
>
> I dunno.

This seems like a much deeper and wider change. This would expand it
to non-sticky, non-world-writable directories as well, meaning
symlinks on fileservers couldn't be managed by non-directory owners
any more, etc. I think there would be a lot of negative fall-out from
that.

Also it wouldn't track the state of a potentially dangerous
environment. Creation isn't the problem; existing is the problem. As
an attacker, I could: "mkdir /tmp/foo; ln -s /etc/shadow
/tmp/foo/evil-symlink; mv /tmp/foo/evil-symlink /tmp" and suddenly the
lrwxrwxrwx would follow the mv. To fix this we'd have to change the
permissions across a move, or other weird hidden behaviors.

Given that the patch is tweaking what "sticky directory" means, I
don't think it's impolite. Only attackers have ever depended on this
behavior, so let's just eliminate it.

-Kees

-- 
Kees Cook
ChromeOS Security
--
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/

Powered by blists - more mailing lists