GNU/Linux

Торговые ассоциации NCTA, CTIA и USTelecom, отстаивающие интересы интернет-провайдеров, обратились в Конгресс США с просьбой обратить внимание на проблему с внедрением "DNS поверх HTTPS" (DoH, DNS over HTTPS) и запросить у Google детальную информацию о текущих и будущих планах по включению DoH в своих продуктах, а также получить обязательство не включать по умолчанию централизованную обработку DNS-запросов в Chrome и Android без предварительного всестороннего обсуждения с другими представителями экосистемы и учёта возможных негативных последствий.

Понимая общую пользу от применения шифрования для DNS-трафика, ассоциации считают недопустимым сосредоточение контроля за преобразованием имён в одних руках и привязку данного механизма по умолчанию к централизованным DNS-службам. В частности, утверждается, что Google движется в сторону введения в практику применения DoH по умолчанию в Android и Chrome, что в случае привязки к серверам Google приведёт к нарушению децентрализованного характера инфраструктуры DNS и возникновению единой точки отказа.

Так как Chrome и Android доминируют на рынке, в случае навязывания своих DoH-серверов Google получит возможность контролировать большую часть потоков DNS-запросов пользователей. Кроме снижения надёжности инфраструктуры подобный шаг также даст Google необоснованные преимущества перед конкурентами, так как компания получит дополнительные сведения о действиях пользователей, которые могут быть использованы для отслеживании активности пользователей и подбора релевантной рекламы.

Применение DoH также может нарушить работу в таких областях, как системы родительского контроля, доступ к внутренним пространствам имён в корпоративных системах, выбор маршрутов в системах оптимизации доставки контента и выполнение судебных предписаний в области противодействия распространению нелегального контента и эксплуатации несовершеннолетних. Подмена DNS также часто используется для перенаправления пользователей на страницу с информацией об окончании средств у абонента или для входа в беспроводную сеть.

Компания Google заявила, что опасения напрасны, так как она не собирается по умолчанию включать DoH в Chrome и Android. Намеченное в Chrome 78 экспериментальное включение по умолчанию DoH будет охватывать только пользователей, в настройках которых указаны DNS-провайдеры, предоставляющие возможность использования DoH в качестве альтернативы традиционным DNS. У тех, кто использует предоставленные локальным интернет-провайдером DNS-серверы, запросы DNS продолжат отправляться через системный резолвер. Т.е. действия Google сводятся лишь к замене на эквивалентный сервис текущего провайдера для перехода к защищённому методу работы с DNS. Экспериментальное включение DoH также намечено в Firefox, но в отличие от Google компания Mozilla намерена использовать по умолчанию DNS-сервер CloudFlare. Такой подход уже вызвал критику со стороны проекта OpenBSD.

Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика (например, при подключении к публичным Wi-Fi), противостояния блокировкам на уровне DNS (DoH не может заменить VPN в области обхода блокировок, реализованных на уровне DPI) или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси).

Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов. В настоящее время около 30 публичных DNS-серверов поддерживают DoH.

Бенджамин Берг (Benjamin Berg), один из инженеров Rad Hat, занимающийся разработкой GNOME, обобщил результаты работы по переводу GNOME на управление сеансами исключительно средствами systemd, без применения процесса gnome-session.

Для управления входом в GNOME уже достаточно давно применяется systemd-logind, который отслеживает состояния сеансов в привязке к пользователю, управляет идентификаторами сеансов, отвечает за переключение между активными сеансами, координирует многопользовательские окружения (Multi-seat), настраивает политики доступа к устройствам, предоставляет средства для завершения работы и перехода в спящий режим и т.п.

При этом часть связанной с сеансами функциональности оставалась на плечах процесса gnome-session, который занимался управлением через D-Bus, запуском дисплейного менеджера и компонентов GNOME, организацией автозапуска указанных пользователем приложений. В процессе разработки GNOME 3.34 специфичные для gnome-session возможности оформлены в виде unit-файлов для systemd, выполняемых в режиме "systemd --user", т.е. в привязке к окружению конкретного пользователя, а не всей системы. Изменения уже применены в дистрибутиве Fedora 31, выпуск которого ожидается в конце октября.

Использование systemd дало возможность организовать запуск обработчиков по требованию или при наступлении определённых событий, а также более изощрённо реагировать на преждевременное завершения процессов из-за сбоев и расширенно обрабатывать зависимости при запуске компонентов GNОME. Как следствие, можно сократить число постоянно запущенных процессов и снизить потребление памяти. Например, XWayland теперь можно запускать только при попытке выполнения приложения на базе протокола X11, а специфичные для определённого оборудования компоненты, только при наличии такого оборудования (например, обработчики для смарткарт будут запускаться при вставке карты и завершаться при её извлечении).

Для пользователя появились более гибкие инструменты управления запуском сервисов, например, для отключения обработчика мультимедийных клавиш будет достаточно выполнить "systemctl --user stop gsd-media-keys.target". В случае проблем, связанные с каждым обработчиком логи можно просмотреть командой journalctl (например, "journalctl --user -u gsd-media-keys.service"), предварительно включив в сервисе ведение отладочного лога ("Environment=G_MESSAGES_DEBUG=all"). Также появилась возможность запуска в изолированных sandbox-окружениях всех компонентов GNOME, к которым предъявляются повышенные требования к безопасности.

Для сглаживания перехода, поддержку старого способа запуска процессов планируется сохранить в течение нескольких циклов разработки GNOME. Далее разработчики проведут рецензирование состояния gnome-session и скорее всего (отмечено как "likely") удалят из него средства запуска процессов и сопровождения D-Bus API. Затем применение "systemd --user" будет переведено в разряд обязательных функций, что может создать трудности для систем без systemd и потребует подготовки альтернативного решения, как в своё время было с systemd-logind. Тем не менее, в своём выступлении на конференции GUADEC 2019 Бенджамин Берг упомянул о намерении сохранить поддержку старого метода запуска для систем без systemd, но данная информация расходится с планами на странице проекта.

Проект KDE ввёл в строй инфраструктуру совместной разработки на базе открытой платформы GitLab, которая позволит снизить барьер вхождения новых участников, сделает участие в развитии KDE более привычным и расширит возможности инструментов для разработки, сопровождения цикла разработки, непрерывной интеграции и рецензирования изменений. Ранее проектом применялась платформа Phabricator (и cgit), которая воспринимается многими новыми разработчиками как непривычная. GitLab достаточно близок по возможностям к GitHub, является свободным ПО и уже применяется во многих смежных открытых проектах, таких как GNOME, Wayland, Debian и FreeDesktop.org.

Поддержка Phabricator пока остаётся в строю, а для сторонников GitLab запущен отдельный сервис invent.kde.org. Платформа Phabricator в основном ориентирована на управление проектами и рецензирование кода, но отстаёт в таких областях, как непрерывная интеграция, работа с репозиториями и web-интерфейс. GitLab написан на языках Ruby и Go, а Phabricator на PHP. Для перехода на GitLab разработчикам KDE не хватало некоторых возможностей, которые частично уже реализованы в ответ на их запрос.

Дополнительно можно отметить проводимую компанией GitLab работу по слиянию коммерческой и community веток проекта, что существенно упростит разработку, сделает процессы более прозрачными и явно отделит проприетарный код в отдельные модули. Вместо разных репозиториев gitlab-ee и gitlab-се, поддержание которых приводило к выполнению двойной работы, кодовая база обеих редакций теперь будет разрабатываться в одном общем репозитории, а продукты Enterprise Edition (EE) и Community Edition (CE) будут собираться из одной кодовой базы. Проприетарный код отделён от открытого и перенесён в каталог "ee/".

Репозиторий gitlab-ce, не содержащий проприетарный код, останется доступен в форме зеркала gitlab-foss, работающего в режиме только для чтения. Новый единый репозиторий для активной разработки построен на основе текущего репозитория gitlab-ee, который переименован в репозиторий "gitlab". В настоящее время миграция находится на финальной стадии - репозитории переименованы, объединение состоялось и почти все связанные с ним задачи уже решены.

Разработчики GitLab также представили корректирующие релизы 12.3.2, 12.2.6 и 12.1.12, в которых устранено 14 уязвимостей, среди которых возможность подстановки произвольных git-команд через API, обход подтверждения email при использовании модуля аутентификации через Salesforce, подстановка JavaScript в интерфейсе предпросмотра разметки Markdown, захват управления над чужими учётными записями при использовании модуля SAML, обход блокировки пользователей, отказ в обслуживании и утечки конфиденциальных сведений о проекте.

Опубликован экстренный выпуск почтового сервера Exim 4.92.3 с устранением очередной критической уязвимости (CVE-2019-16928), потенциально позволяющей удалённо выполнить свой код на сервере через передачу специально оформленной строки в команде EHLO. Уязвимость проявляется на стадии после сброса привилегий и ограничена выполнением кода с правами непривилегированного пользователя, под которым выполняется обработчик поступающих сообщений.

Проблема проявляется только в ветке Exim 4.92 (4.92.0, 4.92.1 и 4.92.2) и не пересекается с устранённой в начале месяца уязвимостью CVE-2019-15846. Уязвимость вызвана переполнением буфера в функции string_vformat(), определённой в файле string.c. Продемонстрированный эксплоит позволяет вызвать крах через передачу длинной строки (несколько килобайт) в команде EHLO, но уязвимость может быть эксплуатирована и через другие команды, а также потенциально может быть использована для организации выполнения кода.

Обходные пути блокирования уязвимости отсутствуют, поэтому всем пользователям рекомендовано срочно установить обновление, применить патч или убедиться в использовании предоставляемых дистрибутивами пакетов, в которых перенесены исправления актуальных уязвимостей. Исправление выпущено для Ubuntu (затрагивает только ветку 19.04), Arch Linux, FreeBSD, Debian (затрагивает только Debian 10 Buster) и Fedora. RHEL и CentOS проблеме не подвержены, так как Exim не входит в их штатный репозиторий пакетов (в EPEL7 обновление пока отсутствует). В SUSE/openSUSE уязвимость не проявляется из-за применения ветки Exim 4.88.

Линус Торвальдс принял в состав будущего выпуска ядра Linux 5.4 набор патчей "lockdown", предложенный Дэвидом Хоуэллсом (David Howells, работает в Red Hat) и Мэтью Гарретом (Matthew Garrett, работает в Google) для ограничения доступа пользователя root к ядру. Связанная с "lockdown" функциональность вынесена в опционально загружаемый LSM-модуль (Linux Security Module), устанавливающий барьер между UID 0 и ядром, ограничивая определённую низкоуровневую функциональность.

Если злоумышленник в результате атаки добился выполнения кода с правами root, то он может выполнить свой код и на уровне ядра, напирмер, через замену ядра при помощи kexec или чтения/записи памяти через /dev/kmem. Наиболее очевидным следствием подобной активности может стать обход UEFI Secure Boot или извлечение конфиденциальных данных, хранящихся на уровне ядра.

Изначально функции ограничения root развивались в контексте усиления защиты верифицированной загрузки и в дистрибутивах уже достаточно давно для блокирования обхода UEFI Secure Boot применяются сторонние патчи с ограничениями. При этом в основной состав ядра подобные ограничения не включались из-за разногласий в их реализации и опасений нарушения работы существующих систем. Модуль "lockdown" вобрал в себя уже используемые в дистрибутивах патчи, которые были переработаны в форме отдельной подсистемы, не привязанной к UEFI Secure Boot.

В режиме lockdown ограничивается доступ к /dev/mem, /dev/kmem, /dev/port, /proc/kcore, debugfs, отладочному режиму kprobes, mmiotrace, tracefs, BPF, PCMCIA CIS (Card Information Structure), некоторым интерфейсам ACPI и MSR-регистрам CPU, блокируются вызовы kexec_file и kexec_load, запрещается переход в спящий и ждущий режимы, лимитируется использование DMA для PCI-устройств, запрещается импорт кода ACPI из переменных EFI, недопускаются манипуляции с портами ввода/вывода, в том числе изменение номера прерывания и порта ввода/вывода для последовательного порта.

По умолчанию модуль lockdown не активен, собирается при указании в kconfig опции SECURITY_LOCKDOWN_LSM и активируется через параметр ядра "lockdown=", управляющий файл "/sys/kernel/security/lockdown" или сборочные опции LOCK_DOWN_KERNEL_FORCE_*, которые могут принимать значения "integrity" и "confidentiality". В первом случае блокируются возможности, позволяющие вносить изменения в работающее ядро из пространства пользователя, а во втором случае отключается функциональность, которую можно использовать для извлечения конфиденциальной информации из ядра.

При этом важно отметить, что lockdown лишь ограничивает штатные возможности доступа к ядру, но не защищает от модификаций в результате эксплуатации уязвимостей. Для блокирования внесения изменений в работающее ядро при применении эксплоитов проектом Openwall развивается отдельный модуль LKRG (Linux Kernel Runtime Guard).