|From:||Kees Cook <keescook-AT-chromium.org>|
|To:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|Subject:||Re: [PATCH v2011.1] fs: symlink restrictions on sticky directories|
|Date:||Wed, 7 Dec 2011 10:54:55 -0800|
|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|
On Wed, Dec 7, 2011 at 10:41 AM, Linus Torvalds <firstname.lastname@example.org> wrote: > On Tue, Dec 6, 2011 at 3:58 PM, Kees Cook <email@example.com> 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-fsdevel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds