bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)

[Kees Cook]

On Fri, Mar 28, 2014 at 5:41 PM, Linda Walsh <address@hidden> wrote:
> Kees Cook wrote:
>> The attack gets more and
>> more remote, but these kind of flaws are not unheard of.
>
> ----
>         If there's a URL for to explain why this is needed, I'd
> love to read more.  My background is computer science and have
> have worked in security, so I'm aware of theory, but logically,
> I am still not seeing the chain of events.  It seems like the
> protected symlink was designed for use in a world-writeable w/
> sticky bit set, so I'm not seeing the need for the extra
> check on hard-link in relation to that.

I outline some of it in the original commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=800179c9b8a1e796e441674776d11cd4c05d61d7

>
>         It seems more like use of a blunt instrument rather
> than making use of the mode bits (or DACL) on a symlink.
>
>         As far as the given reasoning for symlink control,
> I've not heard of any issues related to TOU on devices/pipes
> or other file system objects that couldn't be applied to files.
> I.e. Do you know why they'd blanket ban everything except
> files?

The best example of hardlink insanity is for a system were /usr/bin is
on the same partition as /tmp or /home. A local user can hardlink
/usr/bin/sudo to $HOME/sudo, and when a flaw is found in sudo, the
administrator will upgrade the sudo package. However, due to the
package manager deleting /usr/bin/sudo and replacing it, the original
sudo remains in $HOME/sudo, leaving the security flaw available for
exploitation by the local user.

ToCToU races for hardlinks (like symlinks) also exist. Say some local
root daemon writes to /tmp/bad-idea.log, a local user could hardlink
(or symlink) this to /etc/passwd and destroy the system.

-Kees

-- 
Kees Cook
Chrome OS Security