Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Kees Cook]

On Sun, Mar 17, 2013 at 10:07:48PM +0100, Kevin Kofler wrote:
> Kees Cook wrote:
> > AFD was a single specific program doing a very specific task and hardly
> > represents an "average workload". I remain extremely disappointed that the
> > default-on state was reverted. Ubuntu has had this feature enabled for
> > YEARS now, and it stopped quite a few exploits cold.
> 
> Who knows what other applications this extremely surprising and incompatible 
> change breaks? (IMHO, even private /tmp is a better solution. It's also an 
> incompatible change, but at least it has semantics a normal user can 
> understand, whereas your solution layers really complicated hidden rules on 
> top of something as basic as file permissions.)
> 
> I'm with Linus when he says "Breaking applications is unacceptable. End of 
> story. It's broken them. Get over it." We aren't ready to enable private 
> /tmp for the same reason, so why is this hack any more acceptable?
> 
> IMHO the initscripts change should be reverted and we should stick to 
> Linus's defaults. He said "no" for a reason.

https://lwn.net/Articles/543273/
"On a vanilla kernel, protected_hardlinks unfortunately has the default
value zero" That's what Linus's defaults get: vulnerable-by-default.

Specialized applications are the exception, and if you use them, it's your
responsibility to tune your system as needed. Why leave your system
vulnerable to script-kiddie attacks by default?

The semantics of both world-writable sticky directories and hardlink
access are undefined by POSIX. This fix was not a "hack", it corrects a
bad decision made over a decade ago that was overwhelming more commonly
used for vulnerability exploitation purposes.

-Kees

-- 
Kees Cook                                            @outflux.net