Можно, технология позволяет, вот в полезности у неё куда меньше, ведь тот же:
yum update openssl
service httpd graceful
etc… вообще не даст downtime
ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.
А создавать эти патчи, при всей автоматизации — дорого. Кто то должен их просмотреть, убедится что он ничего не сломает, и его не надо переделывать. Ну или переделать — что вообще трудно, ибо надо иметь специалиста для данного софта.
Собрать, протестировать, подписать, выпустить.
То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
Нет, такие вещи мы просто не знаем как обнаружат. И конфликт двух патчилок тоже не сможем обнаружить. Например если поставить KernelCare на ядро с ksplice --> можно быть уверенным что ядро крашанётся. С ksplice мы это обнаруживаем в userland программе. Если же какой руткит (а они часто подобным образом меняют код) — и он сменил туже/соседнюю секцию --> то мы этого не увидим, и крашанёмся.
На самом деле интересная идея -> сверять эти куски кода, и ставить патч только если таже сигнатура этих кусков. Я спрошу наших разработчиков. Это на данный момент не критично (ибо не случается), но такая защита не повредит.
Двоякое чувство. С одной стороны хочется, ибо то как мы создаём патчи — это очень интересно, у нас технология сильно улучшена по сравнению с ksplice. Они у нас меньше по размеру, легче 'вырезается' именно нужный бинарный кусок. И при этом куда более точно. И мы видим что пока не SuSe не RHEL так не делают.
И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
Конечно, часто бывает что ядро в критической секции и мы просто не можем наложить в этот момент патч, мы это узнаём ждём, пробуем ещё раз пару раз… если за пол минуты не находим, вылетаем с ошибкой (но это редко)
Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
1. Там всё что есть для каждого ядра. Что мы пока не делаем, это не разделяем, что в этот раз «CVE-2222», а в прошлый CVE-2232. Сейчас над этим работаем.
2. Хорошая идея, и очень просто сделать. Добавим.
3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
Есть, мы обсуждаем это с Parallels & OpenVZ командами. Мы хотим чтоб они нам давали патчи которые они считают 'критичными', и мы их тоже будем вставлять. Но пока это в стадии обсуждения/рассуждения. Нам в этом очень важно партнёрство с вендорами, ибо без них нам очень трудно понять что важно, а что нет.
kGraph не будет работать с текущими ядрами, только со специфично проопатченными. Ну и там очень сыро.
kpatch -> там интересно, но тоже только последние ядра.
Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
Патчи подписаны, но проверяются на уровне userland, а не в ядре. Мы знаем что это проблема, и работаем над ней (ещё не успели просто дописать).
Она не очень актуальна для многих, ибо у большинства разрешена загрузка модулей, через которые ставить руткиты сподручнее.
— их можно увидеть на patches.kernelcare.com нажмите на ядро, там будет что патчается, и какими патчами.
— мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
— там система такая что старые патчи сносятся, новые накладываются, каждый раз.
— проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com
пока мы не готовы открыть всё — ибо строим на этом коммерческий сервис, и не хотим лишних конкурентов.
Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
на самом деле это менее рискованно чем перезагрузка. Тут конечно вопрос в доверии. Если вы считаете что компания делающая патчи левая -> то риск. А иначе риск очень маленький, ибо изменения очень сильно локализованны.
kexec кончено очень крут, и делает больше — и делает лучше. Всё же новое ядро. KernelCare не для всех. Но kexec это явно не проще чем сервис который поставил и забыл, и даже не задумываешься когда это сделает. Он себе где то на фоне калупается, без какой либо помощи админов.
Нет, обычно паники из за маленьких проблем, потерянный указатель, переход в никуда… такое мы чиним легко. Также чиним всякие memory leaks, race conditions, и прочее… это не проблема.
Вы совершенно правы — это не для полного обновления ядра, а для устранения проблем с безопасностью и критических багов.
Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)
www.cloudlinux.com/blog/clnews/kernelcare-stability-updates-for-openvz-virtuozzo-kernels.php
yum update openssl
service httpd graceful
etc… вообще не даст downtime
ну остальные сервисы нужно перезапустить, но там опять же < секунды задержка.
А создавать эти патчи, при всей автоматизации — дорого. Кто то должен их просмотреть, убедится что он ничего не сломает, и его не надо переделывать. Ну или переделать — что вообще трудно, ибо надо иметь специалиста для данного софта.
Собрать, протестировать, подписать, выпустить.
То есть в теории возможно — но мы ещё очень далеки от того чтоб это делать, и область применения не очень понятна.
www.cloudlinux.com/blog/clnews/kernelcare-cve20143153.php
На самом деле интересная идея -> сверять эти куски кода, и ставить патч только если таже сигнатура этих кусков. Я спрошу наших разработчиков. Это на данный момент не критично (ибо не случается), но такая защита не повредит.
И это создаёт вторую часть — нам пока не хочется об этом рассказывать нашей возможной компетиции. Это конечно чисто шкурный подход. Но мы хотим себе дать год на раскрутку сервиса, чтоб мы имели шанс устоятся, до того как это будет у всех.
И цены мы выставили такие — чтоб люди не жаловались что дико дорого, и людям не имело смысл переходить на что то более дешёвое.
Вот как только утвердимся, имя станет известным — и нас будет трудно выпихнуть с этого маркета — тогда мы покажем как это делаем, и скорее всего выпустим технологию как opensource.
Так же идёт привязка патча к сигнатуре ядра, поэтому патч на 'чужое' ядро просто не станет.
Ну и конечно патч можно откатить. Что не сделано — это какой патч накатывать. В userland тулзе ещё нет выбора, но вообще для этого всё готово. Патчи нумеруются, и всё что надо это сказать тулзе какой # накатить.
2. Хорошая идея, и очень просто сделать. Добавим.
3. О, вот это классная идея, а какими мониторингами вы пользуетесь? Мы сейчас делаем свой портал, чтоб можно было видеть где что поставлено, какое ядро, какое 'пропаченное' ядро, итд… но вот встроить это в nagios или zabix я как то не подумал.
kpatch -> там интересно, но тоже только последние ядра.
Ну и вопрос кто будет предоставлять патчи для разных ОС. Мы вот хотим быть той конторой которая будет это делать. :)
Она не очень актуальна для многих, ибо у большинства разрешена загрузка модулей, через которые ставить руткиты сподручнее.
— мы этого пока не умеем. У нас либо всё, либо ничего. В будущем будем позволять делать выборочно. Но когда оно наступит завит от того будут у нас это просить часто или редко.
— там система такая что старые патчи сносятся, новые накладываются, каждый раз.
— проверка чего? Вы можете не ставить автоматом патчи, а запускать установку с командной строки. А смотреть что нового в patches.kernelcare.com
Спасибо за вопросы — очень классные.
Контора: CloudLinux. Нашей OS пользуется порядка 2,000 хостинговых компаний, на более чем 20,000 серваков. Обслуживают ~10M-20M доменов в шаредном хостинге. Среди клиентов такие монстры как GoDaddy, Softlayer, итд… Так что мы не то чтоб совсем с улицы.
Мы можем делать довольно большие патчи, и изменять структуры ядра. Конечно когда структуры меняются, нам приходится их инициализировать, итд… что усложняет работу. Иногда нам это приходится делать — но пока редко. Ещё не было не одно случая когда мы не могли починить проблемы в безпоасности. И это за несколько лет RHEL 6 ядер.
И если честно, то не предвидеться что такое вариант вообще возможен. Просто некоторые вещи требуют больше работы от нас (в основном именно структуры данных, так сколько кода поменялось довольно не важно — процесс автоматизирован)