как пропатчить ядро linux
Livepatch: обновление ядра Linux без перезагрузки
Livepatch является механизмом ядра Linux, который позволяет обновлять ядро без перезагрузки. Из данной статьи вы узнаете, как работает Livepatch, и подходит ли он для вашей системы.
Увеличение времени безотказной работы с помощью Livepatch
Обновление ядра «на лету»
Перезагрузка системы может быть нежелательна по ряду причин. Многие критические системы подразумевают безостановочную работу, однако даже при стабильности программного обеспечения могут выходить обновления безопасности, которые относятся к ядру ОС и при традиционном подходе приводят к перезагрузке ОС.
Исправление ядра в реальном времени — это процесс установки исправлений безопасности для работающего ядра Linux без перезагрузки системы. Реализация для Linux называется Livepatch. Процесс исправления живого ядра — довольно сложный процесс. Однако, он обладает рядом преимуществ. Одним из них является возможность отложить перезагрузку до выполнения планового обслуживания. Это позволяет максимально увеличить доступность системы. Еще одним преимуществом является то, что обновления для системы безопасности не только устанавливаются, но и немедленно активируются.
Хотя обновление ядра «на лету» имеет свои риски, последствия известных проблем можно минимизировать.
Требования
Для оперативного обновления необходимо обеспечить выполнение некоторых требований. Прежде всего, нужно обеспечить поддержку Livepatch в самом ядре. В версиях 4.x первоначальная поддержка уже добавлена, то есть достаточно использовать более современное ядро. Во-вторых, системе необходим клиентский инструмент для извлечения патчей ядра и их загрузки. Чтобы разрешить загрузку патчей ядра, в системе должна быть включена возможность загрузки модулей ядра. Патчи ядра обычно создаются поставщиком дистрибутива Linux. Чтобы знать, как перенаправлять наборы команд, требуется определенная практика.
Как работает обновление ядра «на лету»?
Обновление ядра в процессе его работы реализуется с помощью трех механизмов:
Исправление начинается с создания патча. Это означает, что конкретная функция ядра должна быть изменена. Создание патча может быть сделано с помощью такого инструмента, как kpatch-build. В результате получается модуль ядра, который затем распространяется. Когда этот модуль загружен, он обеспечивает, что процессы, использующие определенный системный вызов, используют его исправленную версию.
История реализации механизмов live patching
Первой рабочей реализацией исправления ядра на лету была Ksplice. Этот проект был частью университетских исследований MIT. Для продвижения новой технологии четверо студентов создали компанию Ksplice, Inc. Oracle приобрели компанию Ksplice и сделали сервис одним из основных компонентов своего дистрибутива Oracle Linux.
В 2014 году Red Hat создала Kpatch и выпустила его под лицензией GPLv2. В том же году SUSE объявил о выходе kGraft. Обе технологии очень похожи с небольшими отличиями. Оба инструмента нацелены в первую очередь на подмену функций с использованием встроенного механизма ядра Ftrace. Патч для наложения в обоих случаях оформляется как подгружаемый модуль ядра. Тем не менее, как в механизме применения патчей, так и в их формате и процедуре их подготовки у Kpatch и kGraft есть существенные различия. В частности, при применении патчей Kpatch проверяет, что ни один из процессов не выполняет функции, которые будут обновлены. Для этого приходится ненадолго останавливать все процессы в системе. kGraft же работает с каждым процессом отдельно – некоторые из них при этом могут использовать старые варианты функций, некоторые – уже новые. Постепенно все процессы в системе переходят на использование новых функций. При этом нет необходимости их останавливать. Если kGraft требует создания патча вручную, Kpatch позволяет создавать патчи как вручную, так и автоматически.
Коммерческие предложения
Поскольку эта функция пользуется большим спросом, большинство дистрибутивов Linux предлагают такую возможность только в качестве платного дополнения. Такие технологии, как Ksplice, Kpatch и kGraft, коммерчески интересны для поставщиков. Типичный пользователь Livepatch готов платить за ее использование.
Хотя есть несколько исключений, большинство пользователей в настоящее время не имеют прямого доступа к этой технологии. Постепенно это может измениться, особенно сейчас, когда Livepatch стал располагаться в ядре.
Kernel Live Patching Core
Реализация, расположенная в дереве исходного кода ядра Linux, называется Livepatch. Она вобрала в себя лучшее от Kpatch и kGraft. Она использует Kernel Live Patching Core и доступна каждому. Специальных патчей не требуется, так как эта функциональность теперь является одним из компонентов ядра.
Дистрибутивы, поддерживающие обновление ядра без перезагрузки
На данный момент тестировать Livepatch непросто, так как не все ядра его поддерживают или имеют инструменты клиента для добавления и применения патчей. Но есть другие различные технологии, такие как Kpatch, ksplice, kGraft и Livepatch. Приведем краткий обзор некоторых доступных в дистрибутивах реализаций исправления без перезагрузки.
Поддержка Livepatch в ядре
Arch Linux
Ubuntu
При работе на Ubuntu загляните в директорию /boot :
Статус Livepatch через Sysfs
Если каталог livepatch присутствует, значит, поддержка ядра включена.
Применение патчей ядра Linux без перезагрузки
Для обновления патчей ядра без перезагрузки нужен клиент. У клиента есть инструкции, как работать с конкретным ядром. В статье мы будем использовать Ubuntu 16.04 (LTS). Клиентская утилита является коммерческой (предоставляется Canonical). К счастью, пользователям разрешается вносить изменения в одну-три системы бесплатно. Чтобы использовать утилиту, необходимо создать токен.
Установка клиента
Воспользуемся canonical-livepath (Ubuntu)
Убедимся, что ядро успешно обновлено
Для проверки примененных патчей вы можете использовать следующие способы:
1.Использование директории livepatch
2. Использование флага tainted
Другой способ проверить, что ядро обновилось, — посмотреть, есть ли в /proc/sys/kernel/tainted значение больше нуля. Если есть, то это говорит дебаггеру и другим устройствам о том, что ядро было изменено.
Больше информации о том, кто внес изменения в ядро можно узнать, используя dmesg :
Можно использовать эту же команду для просмотра деталей обновлений.
Предостережения
Если ваша система хорошо защищена, и загрузка модулей ядра отключена, то Livepatch работать не будет.
Ошибки в работе Livepatch
Соединение с демоном разорвалось (Ubuntu)
Команда не найдена (Ubuntu)
Скорее всего, каталог для snaps не определен в переменной PATH. В этом случае обратитесь к утилите, используя полный путь ( /snap/bin/canonical-livepatch ).
Полезные ссылки
Больше информации о Livepatch можно найти по ссылкам:
Как пропатчить ядро без перезагрузки: livepatch, kpatch и Canonical Livepatch Service
Тему обновления патчей ядра без перезагрузки мы уже рассматривали в статье, опубликованной в 2014 году. В ней речь шла о KernelCare — инструменте, разработанном нашими партнёрами из компании Cloud Linux. На момент написания статьи KernelCare был чуть ли не единственным пригодным для полноценного использования инструментом для наложения патчей.
Прошло два с небольшим года — и ситуация изменилась, причём кардинально: начиная с версии 4.0 возможность наложения патчей «на лету» была официально добавлена в ядро.
Инструменты kpatch и kGraft, которые в 2014 году находились в «сыром» состоянии, также были существенно усовершенствованы. Kpatch даже был добавлен в официальные репозитории, — например, в Ubuntu 16.04 его уже можно установить с помощью стандартного менеджера пакетов.
А компания Canonical совсем недавно представила сервис Canonical Livepatch Service, с помощью которого можно патчить без перезагрузки ядро Ubuntu.
Более подробно о некоторых современных инструментах для добавления патчей мы расскажем в этой статье.
Простейший пример: livepatch
Начнём с очень простого эксперимента. Для этого нам понадобится любой дистрибутив Linux c ядром версии 4.0 или выше (в нашем случае это Ubuntu 16.04; здесь и далее все примеры команд приводятся именно для этого дистрибутива). В новых версиях ядра функция добавления патчей «на лету»(она так и называется — livepatch) включена по умолчанию.
Чтобы проверить, как она работает, нам потребуется, во-первых, установить заголовки ядра:
Далее установим отладочные символы ядра:
При выполнении этой команды в Ubuntu 16.04 может быть выдано следующее сообщение об ошибке:
Причина ошибки в том, что репозитории deb-src по умолчанию не подключены, а соответствующие строки в файле /etc/apt/sources.list закомментированы. Чтобы мы смогли работать с репозиториями исходных кодов, выполним:
После этого предыдущая команда будет выполняться без ошибок. К эксперименту всё готово, можно начинать:
Соберём модуль и вставим его в ядро:
Посмотрим, что получилось. Выполним:
Вместо стандартной информации о параметрах ядра мы увидим вот такой текст:
Как видим, патч был успешно применён.
Вся информация о загруженных патчах хранится в директории /sys/kernel/livepatch:
Деактивировать патч можно с помощью команды:
Kpatch
Kpatch — инструмент, разработанный компаний Red Hat. Впервые он был представлен широкой пользовательской аудитории в феврале 2016 года. За это время он был значительно усовершенствован: в Ubuntu 16.04 он уже включён в официальные репозитории. Рассмотрим особенности работы с kpatch на практических примерах.
Начнём с установки необходимых зависимостей:
Для полноценной работы с kpatch также желательно установить ccache:
Вот и всё, зависимости установлены. Можно устанавливать kpatch:
В нашем эксперименте мы будем патчить исходники ядра. Клонируем репозиторий с исходным кодом нашей текущей версии Ubuntu:
По завершении клонирования скопируем исходники в директорию ubuntu-xenial-kpatch (это нужно, чтобы вносить изменения в исходный код и потом создавать на основе этих изменений патчи):
Откроем файл ubuntu-xenial-kpatch/ubuntu-xenial/fs/proc/version.c и внесём в него следующие изменения:
Cоздадим патч с помощью команды:
Патч представляет собой обычный текстовый файл, в котором перечислены внесённые изменения:
Чтобы добавить патч в ядро, выполним:
Как видно из только что приведённого вывода, на выходе мы получаем модуль ядра. Чтобы применить патч, нужно просто добавить этот модуль стандартным способом:
Посмотрим, что получилось в результате:
Canonical Livepatch Service
Несколько месяцев назад компания Canonical запустила официальный сервис Canonical LivePatch Service, который позволяет патчить ядро «на лету» при помощи простейших команд. Этот сервис ориентирован в первую очередь на пользователей enterprise-уровня, и поэтому является платным.
Но рядовые пользователи тоже могут оперативно получать все свежие обновления ядра. Для этого нужно зарегистрироваться на Ubuntu One и получить токен. Токен даёт возможность установить на 3 машины программу canonical-livepatch, которая загружает и добавляет патчи.
Посмотрим, как работает Canonical Livepatch Service. Перейдём по ссылке выше, получим токен, а далее выполним:
По завершении установки выйдем из системы, затем войдём снова и выполним:
Если всё было сделано правильно, мы получим следующее сообщение:
Далее выполним команду:
Вывод показывает, что сanonical-livepatch работает, и в ядро установлены все последние обновления. Более подробную информацию можно получить, воспользовавшись опцией −−verbose:
Также информацию об установленных патчах можно получить, заглянув в уже упомянутую выше директорию /sys/kernel/livepatch:
Kpatch_livepatch_Ubuntu_4_4_0_47_68_generic_14 — это и есть последний загруженный патч. Последние цифры в имени патча (14) совпадают с номером версии, указанным в выводе команды canonical-livepatch status (см. выше).
Убедиться, что новый патч был добавлен, можно и с помощью команды lsmod:
Заключение
В этой статье мы проделали небольшой отбор инструментов для добавления патчей в ядро Linux. Естественно, что все аспекты темы в рамках одной публикации затронуть невозможно. Если у вас есть замечания и дополнения — добро пожаловать в комментарии.
А если вы хотите изучить тему более глубоко, обратите внимание на следующие ссылки:
Применение патчей к ядру Linux
Джеспер Джал (Jesper Juhl), перевод Олега Смагина aka saturn721
Часто задаваемый вопрос в списке рассылки ядра линукс — это как применить патч к ядру, или, точнее, какой патч для какой версии ядра подходит. В данном документе это объясняется.
В дополнение к объяснению того, как применять и отменять патчи, здесь приводится краткое описание структуры различных ветвей ядра (и примеров того, как применять их конкретные патчи).
Что такое патч (patch)?
Патч, или заплатка — это небольшой текстовый документ, содержащий суть изменений между двумя разными версиями исходных текстов. Патчи создаются с помощью программы ‘diff’. Для правильного применения патча вам нужно знать, на основе чего он был создан, и в какую новую версию патч превратит исходные тексты ядра. И то и другое может быть представлено в метаданных файла патча и, возможно, в его названии.
Как применить или отменить патч?
Патч применяется с помощью программы ‘patch’. Эта программа читает файл различий (или патч) и делает изменения в нужных местах исходных текстов.
Патчи для ядра Linux генерируются относительно родительского каталога, содержащего исходные тексты ядра.
Это означает, что пути к файлам внутри файла патча содержат имя директории исходных текстов ядра, относительно которой этот патч генерировался (или имена некоторых других директорий подобно «a/» или «b/»).
то отменить его можно так:
Как передавать файл заплатки/патча программе ‘patch’?
Это (как и в других Unix-подобных системах) может быть сделано несколькими способами. Во всех примерах, указанных ниже, я передаю файл (в разархивированном виде) программе через стандартный ввод, используя следующий синтаксис:
Если для вас этого достаточно, можете дальше не читать этот раздел.
Если файл патча содержится в архиве gzip или bzip, и вы не хотите распаковывать его заранее, можно вызвать ‘patch’ так:
Если файл патча содержится в архиве, и вы хотите разархивировать его вручную до применения, (в примерах ниже это предполагается), это можно сделать так:
Основные ошибки
Когда программа ‘patch’ применяет патч, она пытается проверить файл разными способами. В частности, проверяется, что файл является допустимым патч-файлом и что код, окружающий биты, которые должны быть изменены, соответствует контексту патча.
Если программа ‘patch’ считает, что в патче что-то выглядит неправильно, она может выбрать один из вариантов поведения — отказаться проводить изменения и закончить работу или попытаться найти способ применения патча с небольшими изменениями.
Один из примеров ситуации «что-то не так», которую программа пытается исправить, — это когда контекст изменений присутствует, нужные строки находятся, но у них другие номера. Так может случиться, к примеру, если программа ‘patch’ делает изменения в середине файла, но по каким-то причинам несколько строк в начале файла были добавлены или удалены. Если все остальное в порядке, программа обычно подгоняет номера строк и применяет патч.
Всякий раз, когда программа ‘patch’ применяет патч с его предварительной модификацией, она сообщает вам, что патч применен с ‘подгонкой’ (‘fuzz’).
Вы должны быть осторожны с подобными изменениям, поскольку даже если все выглядит верно, это не всегда так, и что-либо может быть неправильно.
Если вы не применяете к исходным текстам своего ядра неофициальные патчи, а используете только патчи с ресурса kernel.org, применяя их в правильном порядке, и не делаете самостоятельных изменений в исходных текстах ядра, то вы никогда не увидите сообщений ‘fuzz’ или ‘reject’ от программы ‘patch’. Если они будут выдаваться, это свидетельствует об порче ваших локальных исходных текстов или скаченного патча. Вам стоит попробовать снова закачать патч, а если и это не устранит проблемы, то следует скачать полные исходные тексты ядра с kernel.org.
Давайте посмотрим на другие сообщения, которые может генерировать программа ‘patch’.
Если вы получили сообщение «Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).» или подобное, это означает, что программа ‘patch’ регулировала применяемые изменения (в данном случае пришлось передвинуться на 7 строк от того места, где они должны были применяться, чтобы их стало можно применить). Результирующий файл может получиться правильным или неправильным в зависимости от причин, по которым исходный файл был не таким, как ожидалось. Так часто случается, когда вы пытаетесь применить патч не к той версии ядра.
Сообщение «patch: **** unexpected end of file in patch» или «patch unexpectedly ends in middle of line» означает, что программа не может обнаружить в файле патча нужное содержание. Это значит, что либо вы некорректно загрузили патч, либо пытаетесь применить патч не в разархивированном виде, либо применяете патч, переданный через почтовый клиент или что-то и подобное, разбивающее длинные строки на две. Зачастую такие предупреждения могут легко быть устранены путем объединения (конкатенации) таких двойных строк.
Как ранее указывалось, эти ошибки не могут проявиться, когда вы применяете официальные патчи с ресурса kernel.org в правильном порядке и к не измененным исходным текстам ядра. Таким образом, если это случается с патчами с kernel.org, это обозначает искажение патча при загрузке или исходных текстов на вашей машине, и вам стоит полностью заново перекачать исходные тексты ядра или патч, который вы намерены применить.
Есть ли альтернативы программе ‘patch’?
Можно использовать программу ‘interdiff’ (http://cyberelk.net/tim/patchutils/) для создания патча, представляющего разницу между двумя патчами, и дальнейшего его применения.
Однако, хотя эта программа поможет вам сэкономить один или два шага, рекомендуется применять все шаги, поскольку в некоторых случаях interdiff может сработать неправильно.
Другой альтернативой является сценарий ‘ketchup’, написанный на языке python, который автоматически скачивает и применяет патчи (http://www.selenic.com/ketchup/).
Другими интересными инструментами являются diffstat, который показывает сводку изменений, сделанных программой patch; lsdiff, который выводит краткий перечень файлов, затрагиваемых заданным патч-файлом, вместе с номерами изменяемых строк; и grepdiff, показывающий список файлов, модифицируемых патчем, для которых элементы патча содержат заданное регулярное выражение.
Где я могу скачать патчи?
Патчи доступны на http://kernel.org/ Наиболее свежие патчи доступны с главной страницы, но для них имеются и отдельные страницы.
Взамен ftp.kernel.org вы можете использовать ftp.cc.kernel.org, где cc — код страны. Использование для закачки зеркало из наиболее ближней к вам страны позволяет ускорить загрузку, сократить глобальный трафик и уменьшить нагрузку на сервер kernel.org. Поэтому при наличии возможности используйте зеркала.
Ядра 2.6.x
Имеются основные стабильные релизы, выпускаемые Линусом Торвальдсом. Чем больше номер, тем свежее релиз.
Чтобы применить патч от 2.6.11 к 2.6.12, нужно сделать следующее (учитывайте что такие патчи не применимы к ядрам версий 2.6.x.y, их можно применять только к базовым версиям 2.6.x ядро — если необходимо перейти от 2.6.x.y к 2.6.x+1, то нужно сперва применить патч, отменяющий 2.6.x.y, т.е. вернуться к 2.6.x).
Вот несколько примеров:
Ядра 2.6.x.y
Это ветки, которые рекомендуются для пользователей, желающих иметь стабильное ядро и не заинтересованных в разработке и тестировании экспериментальных версий.
Если нет доступного ядра 2.6.x.y, то текущей стабильной версией является ядро с самым большим номером 2.6.x.
Не инкрементальность патча означает, например, что патч 2.6.12.3 подходит для обновления основной версии 2.6.12, но не промежуточной версии 2.6.12.2. Для применения патча 2.6.12.3 к существующему ядру 2.6.12.2 вы должны сперва отменить патч 2.6.12.2 (перейти назад к версии 2.6.12), а затем применить патч 2.6.12.3.
Вот небольшой пример:
Это опытные ядра, выпускаемые Линусом, когда он сочтет, что текущее дерево git (приложение управления исходными текстами ядра) находится в состоянии, достаточно пригодном для тестирования.
Эти ядра не стабильны, и вам следует ожидать периодических проблем, если собираетесь их запускать. Однако они наиболее стабильны среди всех опытных ветвей ядра и, кроме того, в конечном итоге превращаются в стабильное ядро. Таким образом, очень важно тестировать их многим людям.
Таким образом, 2.6.13-rc5 означает, что это пятый кандидат-релиз для ядра 2.6.13, и патч должен применяться к версии 2.6.12.
Вот три примера наложения этого патча:
Эти ежедневные снимки дерева ядра Линуса (сделанные в репозитарии git, поэтому такое название).
Вот несколько примеров применения патчей:
Это экспериментальные ядра, выпускаемые Андрю Мортоном (Andrew Morton).
Эта ветка находится в постоянном развитии и содержит многочисленные экспериментальные возможности; имеется много отладочных патчей, не пригодных для магистральных веток и т.д. Она является наиболее экспериментальной из всех ветвей, описываемых в данном документе.
Вот несколько примеров того, как их применять:
На этом список разъяснений по различным ядра деревьев можно закончить.
Я надеюсь, что вам теперь ясно, как применять различные патчи и помочь в тестировании ядер.
Особая благодарность Рэнди Данлэп (Randy Dunlap), Ролфу Айке Беру (Rolf Eike Beer), Линусу Торвальсу (Linus Torvalds), Бого Эггерту (Bodo Eggert), Йоханнесу Стезенбаху (Johannes Stezenbach), Гранту Коди (Grant Coady), Павлу Мачеку (Pavel Machek) и другим, которых я забыл указать, за помощь в создании данного документа.
Как выбирать программное обеспечение для патчинга ядра Linux в реальном времени
Всем привет! В сентябре OTUS открывает набор на новый поток курса «Безопасность Linux». В связи с этим традиционно подготовили для вас перевод полезного материала.
В 1991 году произошли два не связанных между собой события, каждое из которых предвещало две совершенно разных свободы: конец Холодной Войны и рождение Linux.
Возможность патчинга ядра в реальном времени появилась в 2008 году, когда Linux был еще подростком. Сегодня, когда ядру Linux вот вот стукнет 30, патчинг в реальном времени тоже созрел и готов опровергнуть свою репутацию необязательного дополнения, которое просто «неплохо иметь в комплекте».
На это есть две причины. Во-первых, это доминирование Linux в качестве предпочтительной платформы для экономичного и универсального веб-хостинга: более половины всех известных веб-сайтов в настоящее время работают на Linux. Во-вторых, признание того, что патчинг в реальном времени — это не просто удобство; это также эффективный и малозатратный способ повышения безопасности системы Linux.
Ksplice, первое решение для патчинга ядра Linux в реальном времени, без особых усилий приобрело прибыльный статус после запуска, лишь укрепив свое лидерство, когда технологический гигант Oracle купил его в 2011 году. Сегодня это самая известная из пяти организаций, предлагающих услуги автоматических исправления безопасности для Linux. В алфавитном порядке это:
Что такое патчинг ядра Linux в реальном времени?
Ядро Linux содержит более 20 миллионов строк кода, написанных в основном (предположительно) людьми-программистами. Как и во всем программном обеспечении, в нем есть ошибки. В наш век повышенного внимания к кибербезопасности ошибки предполагают уязвимости. Чтобы решить эту проблему, производители Linux стараются как можно быстрее выпускать обновления для своих ядер. Системные администраторы Linux также стараются быстро реагировать, устанавливая эти обновления, составлять график работы становится сложнее. Это потому, что нет никакой закономерности для обнаружения уязвимостей. Вот несколько причин, почему:
Зачем нужна остановка сервера? Потому что обновление ядра не вступит в силу до перезагрузки. Если вы не перезагрузитесь — если отложите ее в долгий ящик или забудете, — вы окажетесь в затруднительном положении, потому что сервер без актуальных патчей является небезопасным. Позже мы поговорим об этой мантре подробнее, но суть ее такова:
Когда уязвимости становятся общедоступными, то же происходит и с их эксплойтами.
Или, говоря другими словами, у вас есть уязвимость, о которой вы не знали раньше, но теперь знаете. И все остальные тоже.
Спаситель в этом сценарии — установка исправлений в реальном времени (live patching). Это способ обновления не всего ядра Linux, а только его проблемной части. И делается это без остановки процессов или прерывания работы пользователей.
Однако есть ограничения. Патчинг ядра в реальном времени не может исправить все виды ошибок. Ошеломляющая сложность кода ядра и технические проблемы, связанные с изменением кода на лету, означают, что эта техника используется только для устранения критических проблем, обычно связанных с безопасностью.
Несмотря на это, система со средствами для установки патчей в реальном времени более безопасна, чем система без нее. Вот несколько вопросов, которые стоит задавать, когда вы ищете решение для патчинга в реальном времени:
1. Что внутри патча (и кто за ним стоит)?
Когда вы подписываетесь на услугу патчинга в реальном времени, вы платите больше, чем просто за само программное обеспечение. Это становится понятно, когда вы начинаете копаться в исходном коде ядра Linux и понимаете, как плохо написанный патч может нанести вред всей Linux системе.
Я упоминал ранее, что ядро - это огромный объем работы, которая, кажется, расширяется как по активности, так и по объему. Обратите внимание на рост количества строк кода в главной ветке репозитория ядра Linux. (Подсчет происходит по состоянию на 1 января каждого года. Учитываются только файлы и заголовки C/C++, файлы Python и Perl.)
С таким большим объемом кода писать патчи для ядра Linux — непростая задача. Требуется глубокое знакомство с архитектурой ядра и структурами данных. Требуется опыт работы с соглашениями о написании кода и стандартами качества сообщества Linux. И нужен особый талант, чтобы изобретать решения, не влияющие на функциональность, производительность и стабильность.
Есть два противоположных метода, которые производители исправлений используют для разработки и доставки патчей для ядра. Я называю их инкрементальным и монолитным.
Инкрементальные патчи, как шарик жевательной резинки, накладываются друг на друга, каждый из которых изменяет поведение предыдущего. Вы, как заказчик, должны отслеживать, какие патчи вы устанавливаете, а какие нет, а также порядок их установки. Невнимание к этим вопросам может привести к непредсказуемым изменениям в поведении вашей системы. Этот метод наложения патчей позволяет поставщикам быстро выпускать небольшие целевые патчи. Но со временем система может стать нестабильной до такой степени, что восстановить ее сможет только полное обновление ядра.
Монолитный патч — это патч, включающий все предыдущие патчи. По сути, есть только один мастер-патч, который заменяет активный, а не добавляется к нему. Такой подход делает платформу более стабильной, значительно увеличивая время безотказной работы сервера, которое часто измеряется тысячами дней.
2. Как долго ждать до следующего патча?
Между отчетом об уязвимости и ее исправлением неизбежна присутствует задержка. Требуется время, чтобы проанализировать ошибки ядра, и время, чтобы оценить их влияние. Требуются изобретательность и мастерство, чтобы найти решение, и масса тестов, чтобы убедиться, что оно работает. Затем его ждет обязательная проверка и утверждение в рамках процесса разработки Linux.
Задержки, которых можно избежать, случаются, когда поставщик Linux заменяет оценку серьезности сообщества своей собственной. Это означает, что поставщик может устранить несколько уязвимостей с помощью меньшего количества исправлений, но из-за этого заказчик в среднем дольше ждет исправления определенных проблем.
Администраторы Linux, которые понимают причины беспорядочного характера выпусков исправлений, не в большем выигрыше, чем те, что нет. Ни один из них не находит утешения в знании того, что пока они ждут патчей, их системы еще более уязвимы для эксплойта, чем они были до его обнаружения.
3. Насколько серьезной должна быть ошибка?
Почти все вновь обнаруженные уязвимости получают идентификатор CVE. Позже, при более внимательном рассмотрении исследователей безопасности уязвимость получает оценку серьезности, то есть меру ее воздействия.
Важной схемой рейтинга является общая система оценки уязвимостей (CVSS — Common Vulnerability Scoring System). Она представляет уязвимость в виде набора чисел, каждое из которых является оценкой характеристики, например:
Таким образом, количество уязвимостей варьируется не только по месяцам и годам, но и по степени серьезности.
Схемы оценки уязвимости, такие как CVSS, дают поставщикам Linux возможность оценить, как реагировать на конкретную уязвимости ядра. Например, они могут захотеть написать исправления для уязвимостей с совокупным баллом 7 и выше. Это означает HIGH в CVSS v2, HIGH или CRITICAL в CVSS v3. Поставщик, утверждающий, что нацелен на критические уязвимости, может иметь в виду только уязвимости с рейтингами серьезности 9 и 10, если использует CVSS v3.
4. Могу ли я откатить патч?
Автоматическая установка исправлений без какого-либо надзора — страшная идея для многих системных администраторов. Они знают, что даже тщательно протестированные исправления могут изменить поведение системы, влияя на ее производительность или функциональность незаметным и не вполне очевидным образом. Когда это происходит, когда сервер ведет себя странно после установки патча, самый быстрый способ справиться с этим — удалить патч.
Некоторые сервисы патчинга в реальном времени могут удалять патчи. Это упрощает определение того, является ли недавнее обновление причиной изменений в поведении системы.
5. Могу ли я хостить свой собственный патч-сервер?
Агент ПО для патчинга в реальном времени проверяет наличие доступных исправлений на удаленных птач-серверах. Он делает это через регулярные настраиваемые интервалы, обычно с возможностью выполнения специальных проверок. Если патч доступен, программное обеспечение агента загрузит и установит его. Но если агент патчинга не может связаться с патч-сервером, где служба патчинга поставщика хранит патчи, патчинг в реальном времени не произойдет.
Чтобы решить эту проблему, нужно создать собственный патч-сервер. Такой локальный сервер транслирует патчи на все компьютеры вашей компании под вашим фаерволом. Средство безопасного копирования загружает патч и затем распространяет их через фаервол после проверки целостности файлов патчей. Вы можете управлять этим процессом и проверять его, когда вам удобно, сделав совет директоров вашей компании немного спокойнее.
Есть и другие преимущества:
Заключение
Перед тем как подвести итоги, вот три дополнительных вопроса, которые следует задать потенциальному поставщику решений для патчинга: