linux-kernel - Re: [PATCH v2011.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:	Wed, 7 Dec 2011 10:41:59 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kees Cook <keescook@...omium.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 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.

                    Linus
--
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/