On 07/11/14 14:00, Balint Szente wrote:
> Hello!
>
> On Fri, 11 Jul 2014 20:31:11 +0300
> Alex Efros <powerman@powerman.name> wrote:
>
>> There is a risk production won't boot or won't be stable with new
>> kernel. First one isn't risk at all, 'cos if it won't boot you'll
>> immediately notice this and just boot previous kernel instead - this
>> won't even result in noticeable interruption of your services (no
>> more than usual when you reboot to update kernel).
>
> It is not always possible to reboot with the previous kernel. There are
> datacenters (and not so few) who do not give you remote console access.
> So in case of boot issue or kernel panic you have to contact someone
> (who is not always available btw.) and ask nicely to reboot with the old
> kernel. It happened to me once with such a datacenter, that the new
> kernel version had some incompatibility with Hyper-V resulting in
> panic and the interruption was nasty.
>
Thank you for understanding. This is precisely why I don't just jump to
stabilizing even with major security bugs --- I don't believe in
securing your severs by locking them up. Let me describe how kernels go
from the grsec/pax patches to stable: 0. I have automatic scripts for
watching upstream when it pushesout new patchsets. 1. After downloading
a new grsec/pax patchset, I compare it to the old to see what's been
added. If its a minor fix, I will replace a previous hardened-sources
version on the gentoo tree with the latest. If its major, like when
upstream merges a new PaX patchset into grsec, I keep the previous
hardened-sources version around. 2. I do a test to make sure all the
patches apply and play nicely with the gentoo specific patches ---
hardened-sources includes genpatches and there are conflicts sometimes.
3. I do a compile test. 4. I do a boot/run test on amd64/i686
hardware. 5. It goes on the tree ~arch. 6. I wait for 4 weeks and if
there are no major bugs, I stabilize.
Rapid stabilization breaks this cycle. Because I cannot test on all
different hardware, I need community feedback whether some kernel which
is marked ~arch is breaking. We need time for this feedback. I don't
think it is wise securing people's servers by locking them up, so when I
stabilize, I'm sending a message that I've done everything reasonable to
make sure this kernel will work. I want datacenters to be confident in
these kernels.
>> Second is a real issue, of course, but chances are it will show itself
>> several days or even weeks later, and it's really questionable is it
>> good idea to spend so much time testing new kernel "just in case" in
>> this situation.
>>
It takes time before an exploit like this makes it to the wild.
>> At same time there is a FACT (i.e. risk with 100% chance to happens)
>> what your production is vulnerable, and any user (or even someone with
>> webshell) is able to crash it or even get root and own it.
>
> This is not a remote vulnerability. It is a local one
> (see <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4699>).
> Usually on production servers there is no local access anyway for
> arbitrary users. You do not let people to copy executables to your
> server and run it afterwards. So this vulnerability is not critical at
> all.
>
> You can any time unmask the newer kernel and use it if it fits better
> for you. There is no need to stabilize it blindly.
Correct.
>
> Regards,
> Balint
>
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA