company_banner

KernelCare: патчим ядро «на лету»



    Сервер, на котором установлена и надлежащим образом настроена Linux-система, можно не выключать и не перезагружать месяцами. Однако рано или поздно это делать все равно приходится: например, для установки обновлений ядра. Эта процедура зачастую представляет собой отдельную головную боль для системного администратора. Для перезагрузки нужно выбрать время, когда пользовательская активность минимальна. Всем пользователям нужно предварительно разослать письма-предупреждения. Кроме того, всегда есть риск возникновения внештатной ситуации, из-за которой даунтайм серверов может затянуться.

    Существуют специальные программные решения, с помощью которых можно устанавливать патчи и обновления ядра без перезагрузок. В качестве примера нужно в первую очередь привести Ksplice — продукт компании Oracle, распространяемый под лицензией GPL v.2. Он поддерживает следующие дистрибутивы Linux: Oracle, Linux, RHEL, Ubuntu (только десктопные версии) и Fedora. В целом Ksplice вполне справляется с возлагаемыми на него задачами, но у него есть один минус: он может работать далеко не со всеми существующими патчами безопасности.

    В начале 2014 года разработчики RedHat Enterpise Linux предложили свое решение — Kpatch. Продукт распространяется под лицензией GPL2; его исходный ход размещен на GitHub. К сожалению, на сегодняшний день он находится в крайне «сыром» состоянии и не может быть рекомендован к использованию. То же самое пока что можно сказать и о kGraft — решении, разрабатываемом создателями SUSE.

    Совсем недавно наши партнеры из компании CloudLinux (об их главной разработке — одноименной операционной системе — мы уже писали) предложили свой инструмент, с помощью которого можно устанавливать в ядро патчи безопасности и обновления, связанные с критическими ошибками, «на лету», не перезагружая сервер. Он называется KernelCare.

    Разработчики CloudLinux внимательно отслеживают всю информацию об уязвимостях ядра. Как только обнаруживаются «слабые места» в любом из поддерживаемых ядер, они готовят патч, с помощью которого их можно устранить. Патчи (каждый из них специально «заточен» под ядро конкретного дистрибутива) размещаются на серверах распространения. Агент KernelCare, установленный на клиентском сервере, периодически связывается с серверами распространения, загружает и устанавливает все новые патчи. Все это происходит в фоновом режиме; сервер перезагружать не нужно.
    Первые статьи-анонсы о KernelCare появились в Интернете в начале 2014 года. Начиная с текущего месяца продукт распространяется по платной подписке, но любой желающий может бесплатно установить тестовую версию. Срок действия тестовой лицензии составляет 15 дней.

    В настоящее время поддерживаются следующие дистрибутивы Linux (KernelCare работает только с 64-битными ОС):
    • RedHat 6.x;
    • CentOS 6.x;
    • CloudLinux 6.x.


    С апреля этого года поддерживаются и ядра OpenVZ. К июлю запланировано реализовать поддержку Debian и Ubuntu.

    Тестируем KernelCare


    /Тестирование было проведено на ОС CentOS 6/

    Установим тестовую версию kernelcare при помощи следующей команды:

    # rpm -i http://patches.kernelcare.com/kernelcare-latest.el6.x86_64.rpm
    


    Сразу же после установки KernelCare автоматически загружает и применяет необходимые обновления. После этого на консоль выводится сообщение вида:

    Downloading updates
    Patch Level 9 applied
    Kernel is safe
    


    Просмотреть список примененных патчей можно при помощи команды:

    # /usr/bin/kcarectl --info
    
    kpatch-state: patch is applied
    kpatch-for: Linux version 2.6.32-358.23.2.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Wed Oct 16 18:37:12 UTC 2013
    kpatch-build-time: Mon May 12 23:50:58 2014
    kpatch-description: 9
    


    С подробной информацией обо всем, что делает KernelCare, можно также с помощью команды dmesg:

    # dmesg|grep 'kcare'
    
    kcare: registered device with node 10:57
    kcare: allocated 278112 bytes for patch at ffffc900005c4000
    kcare: verifying patch...
    kcare: verified successfully
    kcare: allocating memory in module space...
    kcare: allocated 278112 bytes at ffffffffa0207000
    kcare: 865 relocations to fixup...
    kcare: fixed 865 relocations
    kcare: jumping to ffffffffa020d9a0
    kcare: registered device with node 10:57
    kcare: allocated 278112 bytes for patch at ffffc900005c4000
    kcare: verifying patch...
    kcare: verified successfully
    kcare: allocating memory in module space...
    kcare: allocated 278112 bytes at ffffffffa0207000
    kcare: 865 relocations to fixup...
    kcare: fixed 865 relocations
    


    KernelCare проводит проверку на наличие новых патчей каждые 4 часа. Все патчи загружаются и применяются автоматически. Автоматическое обновление можно отключить. Для этого нужно открыть конфигурационный файл /etc/sysconfig/kcare. Файл содержит один-единственный параметр — AUTO_UPDATE. Его значение следует изменить с True на False:

    AUTO_UPDATE = False
    


    Когда автоматическое обновление отключено, загрузить и применить новый патч можно при помощи команды:

    /usr/bin/kcarectl --update
    
    Updates already downloaded
    Patch Level 9 applied
    Kernel is safe
    


    Все примененные изменения можно откатить назад с помощью команды:
    kcaretl --unload
    
    Updates already downloaded
    KernelCare protection disabled, kernel might not be safe
    


    Заключение


    KernelCare представляет собой действительно удобный и полезный инструмент. К числу его несомненных достоинств следует отнести:

    • простоту установки и настройки;
    • быстроту загрузки и применения патчей;
    • отсутствие какого-либо влияния на производительность системы;
    • возможность отката внесенных изменений назад.


    Разработчики CloudLinux улучшают и совершенствуют продукт, и есть все основания надеяться, что в ближайшее время он получит более широкое распространение и обретет вполне заслуженную популярность среди системных администраторов.

    Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем обсудить статью в нашем блоге.
    Selectel
    148.82
    ИТ-инфраструктура для бизнеса
    Share post

    Similar posts

    Comments 53

      +4
      Это, конечно, крутая штука. Но совершенно бессмысленная, если фикс сложнее полутора строк кода и связан со структурами ядра, а не с фиксом какой-либо проверки.

      Иными словами, KernelCare НЕ обновляет ядро до новой версии (то есть если в новом появился новый функционал или сильно исправлен старый), то вы НЕ получите все это. Максимум, что Вы получите — фикс связанный с безопасностью но тоже далеко не во всех случаях.

      Также это может вызвать проблемы с последующей отладкой дампов таких патченых ядер например силами kdump.
        +7
        Всё верно. Но и usecase подобных инструментов совсем иной. Представьте у вас крутится суперважная бизнескритикал БД. Она крутится вот уже год, никакое ПО и настройки там не меняются, все отлажено. И тут обнаруживается критичный баг в используемом ядре- маленький, но очень вредный, способный заставить ядро «паниковать». Что делать, обновляться с простоем? Вот тут то вам и пригодится KernelCare или иной подобный инструмент.
          0
          Как раз критический баг, от которого ядро будет паниковать оно вряд ли исправит, ибо скорее всего тут понадобятся большие фиксы. Но в целом, да, это актуально особенно на серверах, где пользователи имеют локальный доступ, так как локальные уязвимости находят чуть ли не каждый день.
            +3
            Нет, обычно паники из за маленьких проблем, потерянный указатель, переход в никуда… такое мы чиним легко. Также чиним всякие memory leaks, race conditions, и прочее… это не проблема.
            +1
            Суперкритикал БД может нехило подфризиться, пока обновляются вызовы. Даже если там обновление kgraft-подобное, все равно тормоза могут быть неприемлемо большими. На мой взгляд, все эти пляски могут быть применимы только как дальшейшее уменьшение даунтайма при апгрейде ядра, с бонусом в виде поднятых в память кешей, для критичных вещей существует HA/state replication :)
              +1
              А почему «суперважная бизнескритикал БД» не работает в кластере? Usecase вами представленный больше на костыль походит, все конечно ИМХО.
                0
                Почти ни одна из доступных открытых баз данных не кластеризуется. Даже oracle клстеризуется с кучей ограничений и условий. Да и легендарный VmWare для кластеризованных VPS (полностью реплицированные и работающие на двух узлах) такие огранчиения накладывает, что становится сомнительна целесообразность такого.
                  0
                  PostgreSQL?
                    0
                    С postgresql тоже не все просто. out-of-the-box идет только master-slave репликация, при том что при промоушинге слейва в мастер, старый мастер* придется полностью переинициализировать. Вобщем свои сложности тоже есть.

                    * в большинстве случаев, хотя есть и исключения.
              +1
              ИМХО:
              Обычно на сервере ведь не нужны новые возможности ядра, он расчитывается изначально на выполнение конкретных задач на стабильной основе, соответственно кроме обновлений безопасности потребностей нет. Если же вы хотите новый фичи ядра сразу на продакт выкатывать с клиентами, то это как минимум неправильно. Лучше развернуть новый сервер с новыми возможностями и мигрировать, но если это критичный сервис, если же нет, то можно и ребутнуться ведь…
                +1
                На самом деле проще ребутнутся с kexec, это сокращает время ребута раз в 5-20 в зависимости от железа и сводит его к почти минимуму. А еще с помощью виртуальной магии из патча openvz можно сохранить страничный кэш в прогретом состоянии :)
                  +2
                  Не спорю, вариатов полно, но для шаред-хостинга, для которого и позиционируется CloudLinux, подход с KernelCare вполне оптимален.
                    +1
                    Да, тут полностью согласен. Но имхо шаред отживает свои последние годы и будет вытеснен контейнерами, с которыми локальные уязвимости не будут настолько страшны.
                      +2
                      Боюсь, что вы недооцениваете коммерческую жилку некоторых предпринимателей… ;)
                    +2
                    kexec кончено очень крут, и делает больше — и делает лучше. Всё же новое ядро. KernelCare не для всех. Но kexec это явно не проще чем сервис который поставил и забыл, и даже не задумываешься когда это сделает. Он себе где то на фоне калупается, без какой либо помощи админов.
                      +3
                      вот сейчас как раз пример когда kexec не поможет. Ядер новых от CentOS и RHEL ещё просто нет. А мы уже закрыли уязвимость. Ну это такой, довольно редкий пример.
                      www.cloudlinux.com/blog/clnews/kernelcare-cve20143153.php
                    +1
                    Вы совершенно правы — это не для полного обновления ядра, а для устранения проблем с безопасностью и критических багов.

                    Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
                    И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)
                      0
                      Игорь, очень рад видеть Вас здесь! :) Спасибо за комментарии, очень полезная информация. Есть ли у Вас планы реализации критичных к стабильности фиксов для OpenVZ? Там тоже много фич не связанных с безопасностью, но легко заваливающих серверы в определенных условиях. Будь у Вас такая фишка, мы бы с радостью купили подписку на сотни машин, ибо их (ядер) обновление — задача крайне долгая и сложная :)
                        +2
                        Есть, мы обсуждаем это с Parallels & OpenVZ командами. Мы хотим чтоб они нам давали патчи которые они считают 'критичными', и мы их тоже будем вставлять. Но пока это в стадии обсуждения/рассуждения. Нам в этом очень важно партнёрство с вендорами, ибо без них нам очень трудно понять что важно, а что нет.
                          0
                          Да, это было бы офигенное партнерство! Надеюсь, оно будет не только для PCS, но и для открытого OpenVZ.
                            0
                            Игорь, а реально ли получить по KernelCare пару критичных фиксов стабильности OpenVZ имеющих место в ядрах 1-2 релиза назад?

                            В частности отсюда wiki.openvz.org/Download/kernel/rhel6-testing/042stab090.2 вот этот «fix for netconsole over bonding (PSBM-26668, RH #1095252, possibly #2231, #2338)». Уверен, он очень простой, но растет аж с RHEL (и не факт, что там исправлен).

                            А также отсюда openvz.org/Download/kernel/rhel6/042stab088.4 вот этот «ms ext4: fix online resize with a non-standard blocks per group setting (#2911, PSBM-24924)».

                            Также очень хотелось бы более-менее подробную информацию об организации наложения патчей, чтобы быть совсем совсем уверенными в том, что в очередном апгрейде не придет rm -rf.

                            Кроме этого, у нас есть большой интерес в предоставлении подобной услуги клиентам (тысячи выделенных машин), но тут есть нюансы, которые нужно обсуждать уже отдельно.
                    +2
                    Поставил плюс просто за картинку :). Очень жизненно :).
                    А что касается обновления ядра «на лету», ИМХО, обычно оно всё-таки неоправданно и слишком рискованно :). Программы, работающие на серверах, не должны быть единственным источником данных, поэтому временный downtime одного из серверов не должен приводить к отказу в обслуживании. Поэтому maintanenance перезагрузка сервера на момент обновления ядра, ИМХО, это нормально и терпимо даже в супер-highload-enterprise-production системах.
                      +1
                      на самом деле это менее рискованно чем перезагрузка. Тут конечно вопрос в доверии. Если вы считаете что компания делающая патчи левая -> то риск. А иначе риск очень маленький, ибо изменения очень сильно локализованны.
                      0
                      Исходинки поделки есть? Если нет — сразу в топку.
                      • UFO just landed and posted this here
                          +1
                          По этим исходникам можно сказать, что в них нет ничего, что раскрывало бы суть того, что они делают.
                          И забано доверять свои сервера за 3 бакса в месяц конторе, которая потом может запросто быть поломана и вот у нас ботнет из тучи серверов.
                            +2
                            пока мы не готовы открыть всё — ибо строим на этом коммерческий сервис, и не хотим лишних конкурентов.
                            Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
                        +1
                        Patch Level 9 applied
                        

                        Это очень энтерпрайзно, конечно, но вопрос есть: какие все-таки ограничения у продукта? Какого рода патчи он не сможет применить?

                        И еще, если говорить о «бизнес-критичных» серверах, то есть такие вопросы:
                        — Как перед применением отревьюить список патчей?
                        — Как откатить последний примененный банч патчей?
                        — История применения патчей?
                        — Возможна ли периодическиая проверка без фактического обновления, только нотификация?

                        Как-то так, наверно
                          +1
                          — их можно увидеть на patches.kernelcare.com нажмите на ядро, там будет что патчается, и какими патчами.
                          — мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
                          — там система такая что старые патчи сносятся, новые накладываются, каждый раз.
                          — проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com

                          Спасибо за вопросы — очень классные.
                            +1
                            Ага, понял. Пара мнений:
                            1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
                            2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
                            3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)
                              +1
                              1. Там всё что есть для каждого ядра. Что мы пока не делаем, это не разделяем, что в этот раз «CVE-2222», а в прошлый CVE-2232. Сейчас над этим работаем.
                              2. Хорошая идея, и очень просто сделать. Добавим.
                              3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
                                +1
                                А есть какая-либо защита и rollback на лету, если не важно по какой причине (невозможной и тд) но патч не хочет накладываться?
                                  +1
                                  Конечно, часто бывает что ядро в критической секции и мы просто не можем наложить в этот момент патч, мы это узнаём ждём, пробуем ещё раз пару раз… если за пол минуты не находим, вылетаем с ошибкой (но это редко)
                                  Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
                                  Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
                                    +1
                                    Нет, речь идёт о любой ошибке в модуле, или стечении обстоятельств, или криптомагии, когда сигнатура ядра та же, хеш тот же, а ядро другое.
                                    Или конфликт двух патчилок (или какие-либо модули, модифицирующие ядро, либо еще чего) — проверка накладываемости патча успешно прошла, вы накладываете свой патч и внезапно нарываетесь на то, что код который патчите не тот.
                                    будет ли откат уже наложенной части, перезапишется патч поверх без проверок, или будет упс ожиданный?
                                      +2
                                      Нет, такие вещи мы просто не знаем как обнаружат. И конфликт двух патчилок тоже не сможем обнаружить. Например если поставить KernelCare на ядро с ksplice --> можно быть уверенным что ядро крашанётся. С ksplice мы это обнаруживаем в userland программе. Если же какой руткит (а они часто подобным образом меняют код) — и он сменил туже/соседнюю секцию --> то мы этого не увидим, и крашанёмся.

                                      На самом деле интересная идея -> сверять эти куски кода, и ставить патч только если таже сигнатура этих кусков. Я спрошу наших разработчиков. Это на данный момент не критично (ибо не случается), но такая защита не повредит.

                                  0
                                  Кстати, как пример крутой статы по ядрам предлагаю: stats.openvz.org :)
                                    +1
                                    Спасибо!
                            +1
                            Надеюсь патчи подписаны паблик ключем с последующей проверкой его в ядре? А то теперь руткиты станет ставить еще проще…
                              +1
                              Патчи подписаны, но проверяются на уровне userland, а не в ядре. Мы знаем что это проблема, и работаем над ней (ещё не успели просто дописать).
                              Она не очень актуальна для многих, ибо у большинства разрешена загрузка модулей, через которые ставить руткиты сподручнее.
                              +4
                              Честно говоря, в контексте появления аж ДВУХ ОТКРЫТЫХ (kpatch, kGraft ) средств для реализации той же самой задачи не вижу смысла в Kernel Care в принципе, хотя он работает хорошо (даже на OpenVZ), мы его тестировали и весьма успешно.

                              Зачем платить, ловить баги закрытого продукта, когда в ближайшее время появятся надежные и стабильные реализации данной задачи от открытых продуктов? А RHEL скорее всего так вообще получит эту функцию в стандартной поставке (ну не зря же они делали kpatch?).
                                +1
                                подозреваю, что на регулярной основе выпуск патчей бесплатно получить сложно.
                                  +1
                                  kGraph не будет работать с текущими ядрами, только со специфично проопатченными. Ну и там очень сыро.
                                  kpatch -> там интересно, но тоже только последние ядра.
                                  Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
                                    0
                                    Игорь, а Вы случайно не хотите написать красивую статью с обзором текущих средств обновления ядра и кратким экскурсом в особенности каждой технологии? Это же бесценная информация :)
                                      +3
                                      Двоякое чувство. С одной стороны хочется, ибо то как мы создаём патчи — это очень интересно, у нас технология сильно улучшена по сравнению с ksplice. Они у нас меньше по размеру, легче 'вырезается' именно нужный бинарный кусок. И при этом куда более точно. И мы видим что пока не SuSe не RHEL так не делают.
                                      И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
                                      И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
                                      Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
                                        0
                                        Игорь, а сделайте тоже самое, что для ядра, но для user space приложений? Ведь тот же OpenSSL можно было исправить находу даже без ребута приложений, просто поправив в памяти один байт буквально.

                                        Даже если не находу, то универсальное решение умеющее обновлять систему просто через apt/yum (и также не забывающее перезапускать приложения зависящие от данного бинарика, но уже находящиеся в памяти) без привлечения администраторы я бы с чистой совестью выкупил вдвое дороже KernelCare на сотни машинок :)
                                          +1
                                          Можно, технология позволяет, вот в полезности у неё куда меньше, ведь тот же:
                                          yum update openssl
                                          service httpd graceful
                                          etc… вообще не даст downtime
                                          ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.

                                          А создавать эти патчи, при всей автоматизации — дорого. Кто то должен их просмотреть, убедится что он ничего не сломает, и его не надо переделывать. Ну или переделать — что вообще трудно, ибо надо иметь специалиста для данного софта.
                                          Собрать, протестировать, подписать, выпустить.

                                          То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
                                            0
                                            Почему не понятна? Вся суть KernelCare (да и других подобных систем) в том, чтобы запатчить ядро (= закрыть потенциальные дыры в системе) как можно быстрее без привлечения системного администратора, отсутствие даунатайма при этом скорее бесплатная приятность, чем самоцель.

                                            Но если задачу апгрейда ядра/слежения за уязвимостями в ядре Вы снимаете с администратора, чем, безусловно, закрываете по моим оценкам где-то 1/5 число потенциальных проблем с безопасность и стабильностью. На практике (чуточку больше ее здесь) взломы через локальные уязвимости — вещь веееесьма экзотическая.

                                            Но вот чтобы закрыть оставшиеся 4/5 требуется лезть в ПО, к счастью, обычно это стандартное системное ПО из репозитариев — nginx, exim, apache, openssl, gnutls, lighttpd и прочие. И если будет возможность их также CareFree обновить/запатчить без привлечения системного администратора — Вы перевернете системное администрирование.
                                              0
                                              Спасибо! Очень интересная идея.
                                  0
                                  Кстати, да, очень ждем поддержки Debian 6 и 7. Ну очень очень прямо :)

                                  Only users with full accounts can post comments. Log in, please.