• KernelCare: патчим ядро «на лету»
  • KernelCare: патчим ядро «на лету»
    0
    Спасибо! Очень интересная идея.
  • KernelCare: патчим ядро «на лету»
    0
    Ребята обещали вставить оба эти патча --> должно выйти в течение пары дней.
  • KernelCare: патчим ядро «на лету»
    +1
    Спасибо!
  • KernelCare: патчим ядро «на лету»
    +1
    Можно, технология позволяет, вот в полезности у неё куда меньше, ведь тот же:
    yum update openssl
    service httpd graceful
    etc… вообще не даст downtime
    ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.

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

    То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
  • KernelCare: патчим ядро «на лету»
    +3
    вот сейчас как раз пример когда kexec не поможет. Ядер новых от CentOS и RHEL ещё просто нет. А мы уже закрыли уязвимость. Ну это такой, довольно редкий пример.
    www.cloudlinux.com/blog/clnews/kernelcare-cve20143153.php
  • KernelCare: патчим ядро «на лету»
    +2
    Нет, такие вещи мы просто не знаем как обнаружат. И конфликт двух патчилок тоже не сможем обнаружить. Например если поставить KernelCare на ядро с ksplice --> можно быть уверенным что ядро крашанётся. С ksplice мы это обнаруживаем в userland программе. Если же какой руткит (а они часто подобным образом меняют код) — и он сменил туже/соседнюю секцию --> то мы этого не увидим, и крашанёмся.

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

  • KernelCare: патчим ядро «на лету»
    +3
    Двоякое чувство. С одной стороны хочется, ибо то как мы создаём патчи — это очень интересно, у нас технология сильно улучшена по сравнению с ksplice. Они у нас меньше по размеру, легче 'вырезается' именно нужный бинарный кусок. И при этом куда более точно. И мы видим что пока не SuSe не RHEL так не делают.
    И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
    И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
    Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
  • KernelCare: патчим ядро «на лету»
    +1
    Конечно, часто бывает что ядро в критической секции и мы просто не можем наложить в этот момент патч, мы это узнаём ждём, пробуем ещё раз пару раз… если за пол минуты не находим, вылетаем с ошибкой (но это редко)
    Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
    Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
  • KernelCare: патчим ядро «на лету»
    +1
    1. Там всё что есть для каждого ядра. Что мы пока не делаем, это не разделяем, что в этот раз «CVE-2222», а в прошлый CVE-2232. Сейчас над этим работаем.
    2. Хорошая идея, и очень просто сделать. Добавим.
    3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
  • KernelCare: патчим ядро «на лету»
    +2
    Есть, мы обсуждаем это с Parallels & OpenVZ командами. Мы хотим чтоб они нам давали патчи которые они считают 'критичными', и мы их тоже будем вставлять. Но пока это в стадии обсуждения/рассуждения. Нам в этом очень важно партнёрство с вендорами, ибо без них нам очень трудно понять что важно, а что нет.
  • KernelCare: патчим ядро «на лету»
    +1
    kGraph не будет работать с текущими ядрами, только со специфично проопатченными. Ну и там очень сыро.
    kpatch -> там интересно, но тоже только последние ядра.
    Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
  • KernelCare: патчим ядро «на лету»
    +1
    Патчи подписаны, но проверяются на уровне userland, а не в ядре. Мы знаем что это проблема, и работаем над ней (ещё не успели просто дописать).
    Она не очень актуальна для многих, ибо у большинства разрешена загрузка модулей, через которые ставить руткиты сподручнее.
  • KernelCare: патчим ядро «на лету»
    +1
    — их можно увидеть на patches.kernelcare.com нажмите на ядро, там будет что патчается, и какими патчами.
    — мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
    — там система такая что старые патчи сносятся, новые накладываются, каждый раз.
    — проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com

    Спасибо за вопросы — очень классные.
  • KernelCare: патчим ядро «на лету»
    +2
    пока мы не готовы открыть всё — ибо строим на этом коммерческий сервис, и не хотим лишних конкурентов.
    Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
  • KernelCare: патчим ядро «на лету»
    +1
    на самом деле это менее рискованно чем перезагрузка. Тут конечно вопрос в доверии. Если вы считаете что компания делающая патчи левая -> то риск. А иначе риск очень маленький, ибо изменения очень сильно локализованны.
  • KernelCare: патчим ядро «на лету»
    +2
    kexec кончено очень крут, и делает больше — и делает лучше. Всё же новое ядро. KernelCare не для всех. Но kexec это явно не проще чем сервис который поставил и забыл, и даже не задумываешься когда это сделает. Он себе где то на фоне калупается, без какой либо помощи админов.
  • KernelCare: патчим ядро «на лету»
    +3
    Нет, обычно паники из за маленьких проблем, потерянный указатель, переход в никуда… такое мы чиним легко. Также чиним всякие memory leaks, race conditions, и прочее… это не проблема.
  • KernelCare: патчим ядро «на лету»
    +1
    Вы совершенно правы — это не для полного обновления ядра, а для устранения проблем с безопасностью и критических багов.

    Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
    И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)