Как убить Systemd одной командой

С помощью следующей команды вы можете полностью обрушить systemd и неважно от имени какого пользователя вы ее выполните:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

После выполнения этой команды, процесс с PID 1 получает системный вызов PAUSE. Вы больше не сможете запускать и останавливать сервисы, сервисы в стиле inetd перестанут работать, также вы не сможете чисто перезагрузить или выключить систему.

В целом система становится непригодной к использованию, потому что ssh и su ожидают 30 секунд ответа от systemd, поскольку в них интегрирована система входа. И все это может вызвать одна небольшая команда.

В некоторых системах эта команда работает, только если ее завернуть в бесконечный цикл:

while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done

Как все работает показано на видео:

Как убить Systemd с помощью одной команды

Этот баг очень банален. Команда systemd-notify отправляет сообщение нулевой длины на доступный всем сокет UNIX, который расположен по адресу /run/systemd/notify. Процесс с PID 1 получает это сообщение и падает, потому что размер сообщения не больше нуля. Но несмотря на банальность, это очень серьезная ошибка, так как она позволяет любому локальному пользователю очень просто вывести из строя один из самых важных компонентов системы.

В связи с этой ошибкой сразу возникает вопрос, действительно ли допустимо, чтобы самая популярная система инициализации с такой простой ошибкой существовала более двух лет? Ошибка воспроизводится начиная с Systemd 209. Разве пустая строка это не очевидный тест?

Родительский процесс PID 1, это самый важный процесс в пространстве пользователя и к его качеству можно было бы относится лучше. Не обязательно же было завершать процесс, можно было просто вывести сообщение в журнал.

Проблемы Systemd лежат глубже этой ошибки. Systemd неправильна по своей сути. Написание стабильных программ очень сложно. И даже профессиональные программисты неизбежно допускают ошибки в проектах такого масштаба и сложности. Но они понимают все сложности и сводят к минимуму вероятность ошибок или хотя бы пытаются минимизировать их действие. Разработчики Systemd, похоже не понимают всего этого и пытаются запихнуть в родительский процесс PID 1 много ненужных и очень сложных вещей, что очень небезопасно.

Некоторая сложность обязательна, поскольку Systemd предоставляет очень много важных и полезных функций. Неважно кто это сделал бы, Systemd или кто-то другой, но нужно найти компромисс между сложностью и функциональностью.

Мы не говорим о сложности всего Systemd, нас интересует только PID 1. Единственная задача, которую он должен выполнять - это инициализировать систему инициализации и убивать зомби процессы. Все остальное же должно быть построено по модульному принципу, чтобы сбой в одном из модулей не рушил всю систему. Например, сбой в коде управления сервисами не должен никак влиять на нормальную перезагрузку.

Любой код, который принимает сообщения от недоверенных источников, должен работать в отдельном непривилегированном процессе, таком как systemd-notify. Этот процесс должен проверить сообщение, перед тем как передать его привилегированному. Это называется разделение привилегий и является наилучшей практикой в информационной безопасности.

Systemd же наоборот, делает анализ сообщения от ненадежных источников на Си в процессе с PID 1. Если вы думаете, что Systemd не нужно разделение привилегий, потому что сообщения исходят только от локальных пользователей, то заметьте, что сейчас и локальные атаки могут быть выполнены через интернет.

Но давайте пойдем еще дальше. Systemd имеет проблемы с безопасностью и в других местах. Например, в том же процессе PID 1 функция umask устанавливает полномочия в 0. Это значит, что все файлы, созданные systemd, будут доступны для чтения и записи по умолчанию. Затем, если нужно Systemd меняет эти полномочия на более строгие. Но в идеале все должно быть наоборот, сначала запретить все, а потом уже разрешить то что нужно. В таком случае, если забыть поменять права для такого файла, то он просто не будет работать.

Если же systemd забудет поменять права, что случалось уже два раза, то файл будет работать, только оставит дыру в безопасности системы, поскольку к нему смогут получить доступ все желающие.

Изначально операционная система Linux считалась эталоном безопасности и надежного программного обеспечения. В то время как Microsoft улучшала свою Windows, а Apple MacOS, разработчики свободного ПО, похоже, расслабились. Но есть подвижки в положительную сторону обнаружение Heartbleed и Shellshock были тем тревожным звоночком, который заставил разработчиков внимательнее относиться к качеству программного обеспечения.

Были разработаны новые, безопасные языки для системного программирования, такие как Go и Rust. Systemd была написана на Си, и она небезопасна уже потому, что содержит сотни тысяч строк сложного кода на Си без использования многолетних практик безопасности, таких как разделение привилегий и отказоустойчивый дизайн. Но тем не менее ставит перед собой задачу быть незаменимой.

Systemd - это уже больше чем система инициализации. Это ядро вторичной операционной системы. Она обеспечивает журналирование, менеджер устройств, управление контейнерами, входом в систему, клиент DHCP, DNS, клиент NTP. Система создает интерфейсы, которые могут использовать другие приложения, а это делает ее незаменимой.

Systemd используется в большинстве дистрибутивов Linux. Система инициализации была легкой мишенью для Systemd, потому что существующие системы инициализации были настолько плохи, что не могли составить конкуренцию. Но это не совсем верно для других сервисов, которые пытается заменить Systemd, управление сетью, DNS, NTP.

Systemd перелагает очень мало функций, по сравнению с существующими решениями и несет в себе некоторый риск. Возможно, не стоит так стремиться использовать Systemd везде, чтобы в будущем можно было внедрить более безопасные альтернативы, когда они появятся. Но это будет возможно, только если Systemd не разрушит всю модульность системы и стандарты.

Источник: