[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzRz6DcmP8uYaeYAUkpBfePZTYQg-hvERnA9huCQu4X3g@mail.gmail.com>
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
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.
