User: Password:
|
|
Subscribe / Log in / New account

Re: [PATCH v2011.1] fs: symlink restrictions on sticky directories

From:  Linus Torvalds <torvalds-AT-linux-foundation.org>
To:  Kees Cook <keescook-AT-chromium.org>
Subject:  Re: [PATCH v2011.1] fs: symlink restrictions on sticky directories
Date:  Wed, 7 Dec 2011 10:41:59 -0800
Message-ID:  <CA+55aFzRz6DcmP8uYaeYAUkpBfePZTYQg-hvERnA9huCQu4X3g@mail.gmail.com>
Cc:  Andrew Morton <akpm-AT-linux-foundation.org>, Al Viro <viro-AT-zeniv.linux.org.uk>, linux-kernel-AT-vger.kernel.org, linux-fsdevel-AT-vger.kernel.org, linux-doc-AT-vger.kernel.org, Randy Dunlap <rdunlap-AT-xenotime.net>, Rik van Riel <riel-AT-redhat.com>, Federica Teodori <federica.teodori-AT-googlemail.com>, Lucian Adrian Grijincu <lucian.grijincu-AT-gmail.com>, Ingo Molnar <mingo-AT-elte.hu>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Eric Paris <eparis-AT-redhat.com>, Dan Rosenberg <drosenberg-AT-vsecurity.com>, kernel-hardening-AT-lists.openwall.com
Archive-link:  Article

On Tue, Dec 6, 2011 at 3:58 PM, Kees Cook <keescook@chromium.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-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



(Log in to post comments)


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds