Re: [PATCH v2] fs: block cross-uid sticky symlinks

[Kees Cook <kees.cook@canonical.com>]

Hi Al,

On Mon, May 31, 2010 at 08:52:30PM +0100, Al Viro wrote:
> On Mon, May 31, 2010 at 12:07:54PM -0700, Kees Cook wrote:
> > IIRC, screen, when setuid, allows users to share screen sessions (following
> > some system-defined ACLs) but it does it via the /tmp directory trees it
> > creates.  Per-user /tmp would break this (but yes, it's solvable using some
> > kind of /var/lib/screen which maybe even already exists).
> 
> screen(1) does *not* put directories in /tmp these days, TYVM.
> 
> al@duke:~/linux/trees/vfs-next$ ls -l /var/run/screen/
> total 1
> drwx------ 2 al al 1024 May 20 21:50 S-al

Okay, good; that's a relief.

> In any case, the suggested "improvement" breaks realistic use cases, AFAICS.
> In particular,
> 
> cd /tmp
> tar jxf foo-2.42.orig.tar.bz2
> <...>
> tar jxf foo-gtk-wank-wank-wank-2.69.orig.tar.bz2
> <...>
> ln -s foo-gtk-wank-wank-wank-2.69/docs/GNOME/design/ crap
> <...>
> lpr crap/taste-is-optional.ps
> lpr crap/why-options-are-wrong.ps
> 
> is going to break with that, isn't it?

Nope.  To be fair, it depends on the implementation of of LPR.  In the
case of CUPS, this is fine since lpr will run as the local user, follow
the symlink and read the file contents before POSTing the contents to
the CUPS server.  The privilege boundary is crossed at the network,
not the filesystem in this case.

I would note however that without the symlink following patch a hypothetical
attacker would be able to race you for the "foo-gtk-wank-wank-wank-2.69"
entry, or the "crap" entry, since either could be directed out from under
"tar" and "ln" to symlinks controlled by the attacker.  Unpacking archives
in a sticky world-writable directory is dangerous without this symlink
following patch.

-Kees

-- 
Kees Cook
Ubuntu Security Team