bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Linda Walsh
Subject: bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)
Date: Fri, 28 Mar 2014 17:41:24 -0700
User-agent: Thunderbird



Kees Cook wrote:
So, allowing a hardlink to a symlink means that symlinks owned by the
target user could be hardlinked to in /tmp.
---
        How would that be different than the user creating
a symlink in tmp?  I.e. Theoretically, they can already create
a symlink in tmp.
---
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.

        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?

BTW -- you said:

Though this case of hardlink-copying a writable unowned tree is pretty unusual already! :)
----
   The business of using "groups" for access control is being
increasingly ignored in many system utils -- something I find
very annoying.  Maybe, with increasing use of user and group
specific ACL's, someone might realize that group access can
also be used selectively.  Too many system utils are checking
to see that they are root-user-only writeable which supersedes
a local site's security policy.


Regardless, if your system isn't at risk for such attacks, makes sense
to turn if off if it's getting in your way. :)
---
I wasn't are of the problem until just recently and I think
the hardlink part of it is 'not well considered' given the current
evidence, but I'd really like to know better what made it a problem.

At least, we are agreed on 'cp' doing the most good for the most users.
That principle seems increasingly lost amongst the legalistically
inclined (c.f. shoveling snow off the sidewalk in front of your house,
where owners were held liable if they had shoveled (i.e. took mitigating
action), but not if they didn't).  Sigh.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]