By premature hardening, I mean hardening (of nontrivial complexity) performed "because we can" (or "because it generates papers")...
-
-
-
...rather than "because data indicated it might be the most effective or efficient method to mitigate likely vulns".
End of conversation
New conversation -
-
-
you mean hardening that hard for people to understand/work-with? if so, SELinux is good example,other MACs are easier (AppArmor)
-
Different people have different definitions of hardening I guess.
-
I use "hardening" to refer to measures that increase difficulty or entirely prevent exploitation of an otherwise-exploitable bug.
-
Things like ASLR, stack protector & other types of overflow checks, fortify, various ROP prevention measures, etc.
-
I was thinking on what may fit in "premature hardening" (as more examples), not aware of corresponding term
-
[Overly?] complex access control models, etc. are a related topic but not the one I was talking about.
End of conversation
New conversation -
-
-
all the ones I know of that are enabled by default in production have reasonable performance/security tradeoff
-
At toolchain level, yes. OTOH I think I've seen some source-level hardening hacks implemented with UB.
-
Things like aliasing violations to implement memory scrubbing or "pointer encryption".
End of conversation
New conversation -
-
-
“defense in depth”, and far less so :)
-
I'm not convinced it's the same as "defense in depth".
-
there was a good blog post a while back about "false defense in depth" and a bunch of speed bumps not making a wall
-
here it is: https://noncombatant.org/2016/01/28/against-security-nihilism/ …, but only slightly relevant to your original question
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.