| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
Alan McKinnon: |
| 5 |
> On 21/02/2014 16:15, hasufell wrote: |
| 6 |
>> Alan McKinnon: |
| 7 |
>>> On 20/02/2014 22:41, Nicolas Sebrecht wrote: |
| 8 |
>>>> On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko |
| 9 |
>>>> wrote: |
| 10 |
>>>> |
| 11 |
>>>>> And this point is one of the highest security benefits in |
| 12 |
>>>>> real world: one have non-standard binaries, not available |
| 13 |
>>>>> in the wild. Most exploits will fail on such binaries even |
| 14 |
>>>>> if vulnerability is still there. |
| 15 |
>>>> |
| 16 |
>>>> While excluding few security issues by compiling less code |
| 17 |
>>>> is possible, believing that "non-standard binaries" (in the |
| 18 |
>>>> sense of "compiled for with local compilation flags") gives |
| 19 |
>>>> more security is a dangerous dream. |
| 20 |
>>>> |
| 21 |
>> |
| 22 |
>> |
| 23 |
>>> +1 |
| 24 |
>> |
| 25 |
>>> "non-standard binaries" is really just a special form of |
| 26 |
>>> security by obscurity. |
| 27 |
>> |
| 28 |
>> So you are saying compiling a minimal kernel to minimize exposure |
| 29 |
>> to subsystem bugs is only obscurity? (I really wonder what Greg |
| 30 |
>> would say to this) |
| 31 |
> |
| 32 |
> No, I'm saying that I pay RedHat large sums of money to look after |
| 33 |
> this on my behalf and that money is wasted if I build a custom |
| 34 |
> kernel on that machine. |
| 35 |
> |
| 36 |
> RedHat has a vested interest in doing this right (it's the product |
| 37 |
> they sell) and they have more engineering resources to apply to the |
| 38 |
> problem than I can ever raise. The odds favour RedHat often getting |
| 39 |
> this right and me often getting it wrong, simply because I don't |
| 40 |
> have the unit testing facilities required and my employer doesn't |
| 41 |
> employ OS builders. |
| 42 |
> |
| 43 |
> I won't permit Gentoo to be used in production here for precisely |
| 44 |
> that reason - I can't provide the test guarantees the business and |
| 45 |
> shareholders demand. |
| 46 |
> |
| 47 |
> |
| 48 |
|
| 49 |
Yes, I agree that RedHat might be a better choice, if you can afford |
| 50 |
it (although there are some counter-arguments since they practically |
| 51 |
maintain kernel-forks because of heavy backporting, but I am unable to |
| 52 |
make a definite opinion on this). But that was not the point of my |
| 53 |
claims, so I don't see an argument. |
| 54 |
|
| 55 |
>> The argument that this particular setup may be less tested is a |
| 56 |
>> valid one. But less tested also means less commonly known |
| 57 |
>> exploits and testing these setups is a win-win for users and |
| 58 |
>> upstream. |
| 59 |
>> |
| 60 |
>> Whether you like it or not... whenever you install software on a |
| 61 |
>> server, you become a tester at the same point. |
| 62 |
> |
| 63 |
> Proper testing carries a onerous burden. I've yet to find a |
| 64 |
> enterprise anywhere in the world that does it right outside of |
| 65 |
> their core business. Instead, they pay someone else to do it. |
| 66 |
> |
| 67 |
|
| 68 |
Yeah, the kernel has _zero_ "proper" testing in the sense of software |
| 69 |
engineering. RedHat does not really improve that (e.g. unit tests and |
| 70 |
whatnot). Greg said why that's almost impossible, especially because |
| 71 |
the internal API changes way too frequently. |
| 72 |
|
| 73 |
Still unable to find a real counter-argument. This was about disabling |
| 74 |
codepaths/subsystems, not about RedHat vs Gentoo which is quite an |
| 75 |
uneven fight. |
| 76 |
-----BEGIN PGP SIGNATURE----- |
| 77 |
|
| 78 |
iQEcBAEBCgAGBQJTDgH2AAoJEFpvPKfnPDWzhZUIAIyT9nUPXYAOigXnb6M+OB4x |
| 79 |
/KmYDZ59Fyuz0D0SoMn1pZCNWPrS8UPjAOzUIr4E0DT0uzh0348+1xHDYDv4ph/n |
| 80 |
C9+0jqd9yPQ9kw5rX3zefmjC7wVpJFtLQIiOxaIo6wOqtxfjdVNZdVDEVKU/QJ7G |
| 81 |
n2fOdAccuTFOHCiB2cV8LlF997GfuzJ9nNdXGev3tA8l46wV9/q3gp1HdbkhyAJV |
| 82 |
61QGv8blsPHbXsC8G2fnz/YcNaa0iH6rRcboRHcpMa2Gk1Ui8UrTmiYC/NJO02bN |
| 83 |
TSV8mb/VWow5vVyQSYmpCO4xcylQFVwwWOh14IXcl+mC+CQG4rxPTyUcDUhbewo= |
| 84 |
=2JhD |
| 85 |
-----END PGP SIGNATURE----- |
Archives