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: