Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nicolas Sebrecht: > The 26/02/14, hasufell wrote: > >> I wasn't only talking about modules and yes... loading them on >> demand actually proves my point. > > No. We are talking about servers. > I am aware of that. Please read the whole discussion. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDo9PAAoJEFpvPKfnPDWzbVYH/2O8ILmj6D2BmA+NUWwLxbMK hEyx7t+jZ1oVEnQAVjmnj4n4ylLKAH0qawl7fI2tBjfyXmw68pxItyqw0V3FdHl8 Zf6l/v7hVxTcJpMbF8Lk27BPMIBh8PpOm1A/A1G5eb3NGlMQht3zZa4QhUZkoU+U rVHXVFfSeKyzNYFiRIfdD/dsGXHfqj5Z2PKAqxrjRYo7EdLcHhrJJ/3X1MczOOcf n04vNbPSVCaer4WN5cqLG9bgJVnjVjhzF7bKwkjTjezwedEI969PCBHT0SZWN0mg 7vTEJzfykglcQ7PDJ/PPRgt8gwoFQCU1U7x/NAaANOQfoiCTHoffpwtVOf7XyUQ= =LwNB -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Nicolas Sebrecht: > The 21/02/14, hasufell wrote: > >> 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) > > Developers made the kernel to rely on modules. Distributions relies > on them. Since they are almost always loaded on demand, Gentoo does > not make things better in this area, either. > I wasn't only talking about modules and yes... loading them on demand actually proves my point. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDgJIAAoJEFpvPKfnPDWz7a8IAKwtA+Ab7ETdaJ+nw0mGJcXg Cq1QLQLlXheDoqNLDP63lKgePx82nenT9HxWRovpao1lzhr/y8AU0ZFLJhYTxAAC sLc1Fbf2CHV1XqoPPwdJgK5AWI60jf2v5HTsCLNr57NK9VhpZGAwRvWf2M3DnOA+ VRrMnB0kzm4BolTvM1pVLvgx1CM2CSyRZBQjhd948aEUsCkVslNbb5Ad5/BYfA53 z+gxY7H+0r/an0xcc4LMdIHvE5ztCBhX+M5gkEhqNtI9IG7rXJTWmjQb69WA0ZYO UpPPUzd+dNmyfd2w/lQoZFirPLMtEbgrFuzvu8OJHfDs02oyH6oLJ4eGjx4bXwo= =fSvm -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alan McKinnon: > 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. > > Yes, I agree that RedHat might be a better choice, if you can afford it (although there are some counter-arguments since they practically maintain kernel-forks because of heavy backporting, but I am unable to make a definite opinion on this). But that was not the point of my claims, so I don't see an argument. >> 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. > Yeah, the kernel has _zero_ "proper" testing in the sense of software engineering. RedHat does not really improve that (e.g. unit tests and whatnot). Greg said why that's almost impossible, especially because the internal API changes way too frequently. Still unable to find a real counter-argument. This was about disabling codepaths/subsystems, not about RedHat vs Gentoo which is quite an uneven fight. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDgH2AAoJEFpvPKfnPDWzhZUIAIyT9nUPXYAOigXnb6M+OB4x /KmYDZ59Fyuz0D0SoMn1pZCNWPrS8UPjAOzUIr4E0DT0uzh0348+1xHDYDv4ph/n C9+0jqd9yPQ9kw5rX3zefmjC7wVpJFtLQIiOxaIo6wOqtxfjdVNZdVDEVKU/QJ7G n2fOdAccuTFOHCiB2cV8LlF997GfuzJ9nNdXGev3tA8l46wV9/q3gp1HdbkhyAJV 61QGv8blsPHbXsC8G2fnz/YcNaa0iH6rRcboRHcpMa2Gk1Ui8UrTmiYC/NJO02bN TSV8mb/VWow5vVyQSYmpCO4xcylQFVwwWOh14IXcl+mC+CQG4rxPTyUcDUhbewo= =2JhD -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Wed, Feb 26, 2014 at 5:55 AM, Nicolas Sebrecht wrote: > The 21/02/14, hasufell wrote: > >> 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) > > Developers made the kernel to rely on modules. Distributions relies on > them. Since they are almost always loaded on demand, Gentoo does not > make things better in this area, either. > > -- > Nicolas Sebrecht > Actually, they're loaded on demand when they: a) Are enabled (the kernel doesn't rely on modules, it offers them for versatility, though some user space code does rely on them, i.e. virtualbox, a few drivers for X, etc) b) Are built for that particular kernel c) That kernel has all the dependencies in place to support them d) The tools to load them exist in user space e) They're not specifically blacklisted in user space (assuming a loading mechanism that honors that) Unless it's changed when I wasn't looking, it's entirely possible to build a kernel with module loading disabled entirely and restrict the set of code to be run in kernel space to an explicitly defined series of kernel options. I say "when I wasn't looking" because I use modules to trim down how much of iptables is constantly loaded on my router for rules there I don't use and the only other places I have Gentoo are my multitude of laptops, where the versatility of building and loading a module to test out yet another toy someone has on hand around me, without a reboot in many cases, is incredibly handy. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
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 alan.mckin...@gmail.com
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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) 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. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTB19lAAoJEFpvPKfnPDWzxR0H/1sz9v/yvAS/EvdCUgo6MBYW 0+A1yJPNfDK3eNMtcipcfBLIs2PbxjamtXKI/Ysjbog3oJxrt1cczDlLByGgG2kW PM0buUKsId6eLM/X3X9UJ06ZCVIK4JN4Baf9OAaBdJrquwL1Ja7rfzjTbC7vEOWj 9H0UqHuVL6qgvUvyVodMJWVXjc8Deda5w+Z9bWAbeBncf/pDukOO0JWr/6/wUsNe fhdcDqijB+qZ3auHA7YYwpwIYTBIGdlHRUwqm9zVDbSnOQm79FLE/3+dsaAjTqv/ NmXvsAmggHb1Q6FpMwZmaXHCtTMN67zWRaE+Oi36p7p7gZK/1DyW8lwgqBsq5/M= =ZQID -END PGP SIGNATURE-
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 22:59:59 +0200 Alan McKinnon wrote: > 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. Or alternatively a special form of "no-one will eva figure > out my l33t skillz! Mwahahaha!" Exactly. This is security trough obscurity. I never claimed this is an ultimate or a sufficient way to protect a system. But this is just a single of many multiple layers which can be used to provide acceptable security level. > Which is a very poor stance to take. > > The total amount of code not compiled by setting some USE flags off is > on the whole not likely to be very much, and hoping with finger crossed > that the next weakness in a package will just happen to fall within a > code path that got left out by USE flags is a fools dream. You mare compare binary sizes for e.g. openldap (and all its libraries) with minimal and full (USE="-minimal *") setup. Quite impressive, not to count all external so libraries involved. > I'm glad you mentioned this Andrew, because the internets are full of > stupid advice like this "non-standard binary" nonsense. Are you considering Bruce Schneier's advice as a stupid nonsense? In his "Applied cryptography" he recommended one of the ways to straighten a system: to use not so frequently used algorithms instead of selected standards because less frequently used algorithms has no better math but are less targeted, have less specialized hardware built to crack them and so on. > Yes, the > arguments at face value are difficult to refute with hard facts, but > those that do not known it is stupid are easily led into a sense of > false security, doesn't matter how many disclaimers are tagged on the end. > > I reckon it's the duty of all knowledgeable sysadmins to stamp out this > crap HARD every time it raises it's head. To the user who brought it up > - this might seem overly harsh but I've yet to find a better method that > actually works and gets through to people. I never talked about a sense of security just because system has non-standard binaries. I talked about high variance which brings a _bit_ more security. And I'm talking not from some theorizing, but from practical experience on both ends (data protection and legitimate system forensics). Have you ever considered how systems became broken in the wild? The most common way (in numbers of hosts, not significance) are automated robots and botnets. They just scan the net, try to bruteforce any login service they found and try to apply any exploit appropriate from their database. If one have a widely used and improperly configured (or not timely updated) setup, it will be hacked this way. The key point of any attack is *cost*, is *money* one needs to spend for an attack. Automated attacks are cheap and such _simple and cheap_ measures as obscured binaries and non-standard (e.g. ssh) ports will stop most of these attacks. This way it will cost _more_ for the attacker to break into protected system and with raise of an attack cost system protection level also rises. Of course, obfuscation is _not_ sufficient for system protection. This is just one small step forward. I don't want to discuss full scope of server protection issues, because this is far out of the topic of this discussion and because measures needed are task- dependent. However I want to notice one critical security issue quite common for production servers: an old software. It doesn't matter how many protection layers system have, how skilled person configured it was. When software is old it is quite trivial to look up for CVEs and break the system. Quite practical encounter from my own experience: I was asked to legitimately obtain root on the box (admin forgot password, reboot (with init=/bin/bash) was not an option and root access was needed for reconfiguration); a box was a year old RHEL with SELinux enforced. Third kernel exploit worked perfectly (I just found them on the net, not bothered to code myself). Such trivia with Gentoo and its custom binaries is not possible. And Gentoo is quite good with recent software updates (RH sometimes is too slow with critical kernel/libc issues). Old software is evil. It doesn't matter how good and tested it _was_. Variety and diversity are quite important for real word systems protection. Of course, it is possible to break _any_ box on the Earth, the only question is how high th
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 21:41:03 +0100 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. Any decent security setup contains multiple layers of protection. Use of non-standard binaries, algorithms or implementations is just one of them and it is the simplest math to prove that security is _improved_ this way. Nobody says that system became _acceptably_ secure _only_ by using this techniques. Best regards, Andrew Savchenko pgpRPR7k1tXEj.pgp Description: PGP signature
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
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. Or alternatively a special form of "no-one will eva figure out my l33t skillz! Mwahahaha!" Which is a very poor stance to take. The total amount of code not compiled by setting some USE flags off is on the whole not likely to be very much, and hoping with finger crossed that the next weakness in a package will just happen to fall within a code path that got left out by USE flags is a fools dream. I'm glad you mentioned this Andrew, because the internets are full of stupid advice like this "non-standard binary" nonsense. Yes, the arguments at face value are difficult to refute with hard facts, but those that do not known it is stupid are easily led into a sense of false security, doesn't matter how many disclaimers are tagged on the end. I reckon it's the duty of all knowledgeable sysadmins to stamp out this crap HARD every time it raises it's head. To the user who brought it up - this might seem overly harsh but I've yet to find a better method that actually works and gets through to people. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 11:29:52 +0100 Nicolas Sebrecht wrote: > The 20/02/14, Nilesh Govindrajan wrote: > > >Gentoo makes the best server os because it's a custom built os where the > >admin knows each and every aspect of the os. Security wise, there are no > >unwanted or unused stuff, so lesser bugs to deal with. > > While I agree with the "less code is less bug" argument, I disagree with > your point. > > Tuning softwares mean that the binaries compiled on a machine are less > used in the wild (other Gentoo systems have other hardware, enabled use > flags, etc). Hence, the binaries executed on you local server are likely > much less tested by others. 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. This will cut-off most off automatic botnet attacks even without additional security measures like hardened setup, PaX or GRSecurity (yeah, I never trusted SELinux because of its main author: sane agency will never release a security tool which can be a hinder to this agency). Of course, if system is specifically targeted by qualified professionals, this will only hinder their approach, but binary based distributions will not provide any advantage here either. Best regards, Andrew Savchenko pgpdyWR4NlZ8L.pgp Description: PGP signature
