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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
