funsec mailing list archives
Re: symlink creation (and sudo)
From: Damian Gerow <dgerow () afflictions org>
Date: Thu, 27 May 2010 13:28:37 -0400
Valdis.Kletnieks () vt edu wrote: : If the program then fails to sanity check that following the symlink is a safe : thing to do, bad things can happen. However, getting this right, under all : TOCTOU races, is really hard. A *lot* of programs have had similar bugs - about : all you can do is go ahead and blindly open() the file, then fstat() the : now-open file descriptor, check it's permissions/ownership/etc, and then stat() : and lstat() the file to make sure you ended up where you intended to. : : There's been plenty of patches that try to restrict the use of symlinks. One : popular one showed up in the OWL and GRSec patches that basically said "do not : follow unless the owner of the symlink matches the owner of the directory it's : in". This fixes most "create a symlink in /tmp to redirect a temp file" races : (since /tmp is usually owned by root). However, this approach has been : criticized by many as being "voodoo security" - it papers over one specific : cause of trouble, when what is *really* needed is a more complete security : framework (such as SELinux, AppArmor, and other similar systems). There's : a big difference between traditional Unix security semantics (which are : strictly DAC), and what you need to do to implement MAC (which is what's : *really* needed instead of voodoo "don't follow symlinks" patches). Okay, that's probably where I'm pulling this from, then. I'll admit, I'm not really sure how it's 'voodoo security'; sure, it just solves/papers over one specific problem, but at least it does so consistantly and in one location, instead of every application needing to be aware of the issue. And I think that's my fundamental lack of understanding: in a DAC system, it seems the patch isn't really a bad idea, even if a more proper solution can be found in MAC/RBAC. (Then again, I haven't work on a security team in years, and I'm by no means attempting to resurrect what sounds like a long and storied debate.) : And yes, implementing a usable 'sudo' scheme under a strict MAC system *is* a : royal pain. I've been trying to convince our security team to at least evaluate RBAC and do away with DAC/MAC + sudo, but they will neither entertain the idea, nor tell me why they think it's a bad fit. And my team is very resistant to MAC -- or, for that matter, any change in how security is handled (Kerberos? Sure! What, I have to type 'kinit', and not use SSH keys? No way!). Thanks. The history lesson and summary was exactly what I was looking for. _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
Current thread:
- symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) Bill Weiss (May 27)
- Re: symlink creation (and sudo) Valdis . Kletnieks (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) Valdis . Kletnieks (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)
- Re: symlink creation (and sudo) der Mouse (May 27)
- Re: symlink creation (and sudo) Damian Gerow (May 27)