GNU bug report logs - #17103
cp: "cp -al" doesn't copy symlinks, tries to link to them

Previous Next

Full log

Message #95 received at 17103 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Kees Cook <keescook <at> google.com>
Cc: 17103 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: Re: bug#17103: regression: cp -al doesn't copy symlinks,
 but tries to link to them (fail)
Date: Tue, 01 Apr 2014 20:48:28 -0700

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


(had already read that though not from that source)...


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

    OK, then why restrict hardlinks to symlinks -- they can't
be setXID.  Same with anything other than a file.  They can't be used
in the same way.  The restrictions on 'non-files' became worse -- in that
the DACL(incl mode) is ignored.

   For files... disallow linking to setXid (or setcap) files, and
for 'icing' disallow hardlinks to/from files in world readable sticky dirs.

   Wouldn't those restrictions have given the same benefit...(focusing,
BTW, on the restrictions on hardlinks).


> 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.
---
	In that case, should 'root's DACL override ability trump the
protections setup by the sticky-bit.  If root programs are going
to insist on using the same world-writeable sticky bits as all other
users, it seems only prudent that increased restrictions apply -- not
only to protect root, but other users --- If root can just overwrite
any file -- if that was a tmp file that is being read for final
saving in the user dir of an important file -- wouldn't that be equally
bad?

I.e. maybe root shouldn't be able to open an existing file (not owned
by root) in a sticky-dir -- but would need to move or remove it first.

Wouldn't the above restrictions accomplish the same security goals with
less impact to compatibility w/existing features?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.