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.