Re: symlink creation (and sudo)

[Valdis.Kletnieks () vt edu]

On Thu, 27 May 2010 11:41:20 EDT, Damian Gerow said:

> But perhaps more importantly, I don't understand why I'd be allowed to do
> this in the first place.  Why should a generic user be allowed to create
> symlinks to protected system files?

Because you're even allowed to create a dangling symlink that points to a
totally nonexistent file on a bogus filesystem. In general, this shouldn't
be a problem, because if the symlink *is* dereferenced, the kernel will apply
the current permission set to opening the target file.  The problem only starts
when you create a symlink and convince a program in a different security
context to follow it.

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).

And yes, implementing a usable 'sudo' scheme under a strict MAC system *is* a
royal pain.

Attachment: _bin
Description:

_______________________________________________
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.