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

[Linda Walsh]

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?