On 21/02/2014 16:15, hasufell wrote: > Alan McKinnon: >> On 20/02/2014 22:41, Nicolas Sebrecht wrote: >>> On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko >>> wrote: >>> >>>> And this point is one of the highest security benefits in real >>>> world: one have non-standard binaries, not available in the >>>> wild. Most exploits will fail on such binaries even if >>>> vulnerability is still there. >>> >>> While excluding few security issues by compiling less code is >>> possible, believing that "non-standard binaries" (in the sense of >>> "compiled for with local compilation flags") gives more security >>> is a dangerous dream. >>> > > >> +1 > >> "non-standard binaries" is really just a special form of security >> by obscurity. > > So you are saying compiling a minimal kernel to minimize exposure to > subsystem bugs is only obscurity? (I really wonder what Greg would say > to this)
No, I'm saying that I pay RedHat large sums of money to look after this on my behalf and that money is wasted if I build a custom kernel on that machine. RedHat has a vested interest in doing this right (it's the product they sell) and they have more engineering resources to apply to the problem than I can ever raise. The odds favour RedHat often getting this right and me often getting it wrong, simply because I don't have the unit testing facilities required and my employer doesn't employ OS builders. I won't permit Gentoo to be used in production here for precisely that reason - I can't provide the test guarantees the business and shareholders demand. > The argument that this particular setup may be less tested is a valid > one. But less tested also means less commonly known exploits and > testing these setups is a win-win for users and upstream. > > Whether you like it or not... whenever you install software on a > server, you become a tester at the same point. Proper testing carries a onerous burden. I've yet to find a enterprise anywhere in the world that does it right outside of their core business. Instead, they pay someone else to do it. -- Alan McKinnon [email protected]
