У нас есть пара десятков систем Ubuntu (от 8.04 до 9.40, как настольные компьютеры, так и серверы с доступом только через последовательную консоль), на которых мы хотели бы запустить исправленную версию glibc.
В частности, это исправить неспособность преобразователя glibc разрешить программам, таким как ssh-клиент из OpenSSH, устанавливать бит AD; общая суть того, что мы хотели бы сделать, доступна в сообщении в блоге Как заставить OpenSSH видеть флаги DNSSEC AD при поиске по SSHFP с помощью glibc. Мы планируем сделать несколько более обширную модификацию, добавив поддержку битов AD в файл заголовка, чтобы мы могли скомпилировать стандартный двоичный файл ssh, хотя это также потребовало бы замены клиента ssh.
Итак, мой вопрос: как проще всего внести изменения, синхронизировать их с регулярными обновлениями Ubuntu и распространить на все наши машины?
Я предполагаю, что оптимальным вариантом может быть поддержка нашей собственной копии исходных пакетов Ubuntu, обновление нашей с каждым обновлением, создание новых версий по мере необходимости и их распространение путем настройки сервера, который входит в список серверов пакетов для каждая машина. Но я не знаю достаточно подробностей о том, как это сделать, чтобы понять, лучший ли это вариант. Если это так, я хотел бы получить несколько указателей на подробности настройки.
Некоторым, вероятно, будет интересно, почему я хочу это сделать. Причин две:
В ближайшее время эта функция не будет добавлена в glibc. Его нет уже более пяти лет, и никто не проявляет по этому поводу никакого беспокойства; скорее они говорят, что считают добавление этой функции слишком опасным из-за «высокого воздействия на безопасность» изменения или чего-то подобного.
У нас строгая политика, согласно которой вы не можете подключаться через ssh к компьютерам компании, ключи которых не проверены (т. Е. Мы используем параметр ssh "StrictHostKeyChecking yes").
Я бы хотел избежать здесь обсуждения любого из вышеперечисленных пунктов. Если вы хотите узнать больше о политике разработчиков glibc, или если вы не понимаете, какие атаки вы открываете, не соблюдая нашу политику безопасности, задайте отдельный вопрос, напишите мне по электронной почте с его URL-адрес, и я буду ссылаться на него отсюда.
Вы хотите делать именно то, что вы предлагаете, и поддерживать исправленные пакеты. Настроить репо довольно просто, я просто использую apt-ftparchive для выполнения тяжелой работы по записи файлов пакетов. Имейте правило procmail для просмотра списка ubuntu-security-announce и предупреждений о любых обновлениях безопасности для интересующих пакетов. Если вы никогда не создавали пакет до этого, вам нужно немного повеселиться, но это не особенно сложно, если вы умеете читать документацию.
Создать автоматический репозиторий на одном из ваших внутренних серверов и синхронизируйтесь с версией ubuntu. Убедитесь, что ни один из ваших клиентов не добавляет репозиторий «предлагаемых обновлений» из ubuntu, и зарегистрируйте его самостоятельно (как сопровождающий патч), так вы сможете опередить фактическое обновление и предоставить свою версию заранее.
Назовите версию как дополнительное обновление, так что она будет «выше» версии ubuntu, например, текущая версия:
$ apt-cache policy libc6
libc6:
Installed: 2.9-4ubuntu6
Предположим, ваша организация называется примером, она должна быть 2.9-4ubuntu6example1. Вы даже можете подписывать свои архивы PGP для дополнительной безопасности.
Нет необходимости в SSH, и вы можете использовать PackageKit + PolicyKit, чтобы пользователи могли обновлять его, не предоставляя им root-доступ (при условии, что вы так строги).
В качестве примечания, держу пари, причина того, что патч не принят, - это Ульрих Дреппер, он отвергает почти каждый патч от людей, «которым он не доверяет». Вскоре Debian переключится на eglibc, у которого есть гораздо более дружелюбный разработчик, который рассматривает возможность добавления любого патча.