On 07/11/14 14:00, Balint Szente wrote:
Hello!
On Fri, 11 Jul 2014 20:31:11 +0300
Alex Efros <[email protected]> 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 : [email protected]
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
