Недавно я установил arch-linux, где вместо systemd была прекращена поддержка tsystem V. Мне интересно, если кто-нибудь точно знает, почему. Я знаю, что systemd новее, но есть ли в rc.d проблемы с безопасностью?
1 ответ
2
Не совсем. На самом деле, старая система инициализации rc.d, вероятно, намного проще для аудита, учитывая, что она написана в сценарии оболочки (edit: за исключением самого демона init, написанного на C) и намного короче. «Старая» INIT сама система не так уж много более или менее безопасные сам по себе (редактирование: хотя у него есть больше коды и интерфейс Dbus - больше места для ошибок и т.д.). systemd имеет лучшую изоляцию процессов, которыми он управляет, с самого начала, помещая их в свои собственные cgroups, но это само по себе не имеет большого значения само по себе, за исключением надежной маркировки процессов. Это можно сравнить со следующим разговором.
- Вот эта кучка рабочих, а вот еще одна кучка. Мы разделили их на группы. Они не могут менять группы. Только руководитель может установить вашу группу.
- Хорошо. Но ты сделал что-нибудь еще?
- Нет.
- Применяете ли вы правила типа «группе А нужен только доступ к этим ресурсам, поэтому им разрешен только доступ к этим ресурсам»?
- Нет.
- Вы полностью изолируете каждую группу от другой?
- Нет.
Подобно SysV init, старой системе инициализации Arch Linux (которая действительно построена на основе SysV), systemd и т.д. У вас, конечно, есть базовая конфигурация различных вещей (чтобы не быть конкретными), которыми автоматически управляют (независимо от того, запущены ли они на загружаться, в произвольный момент x или убить, когда свиньи вдруг научатся летать). Эти вещи (модули, как их называет systemd), имеют некоторый интерфейс конфигурации (в systemd, INI-подобном файле конфигурации), поддерживается указание systemd использовать некоторые функции ядра Linux, которые могут повысить безопасность вашей системы. Вот несколько примеров, извлеченных из systemd.exec(5):
- Белый и черный списки узлов устройства для этого процесса (
DeviceAllow,DeviceDeny) - Пространство имен Filsystem (
ReadWriteDirectories,InaccessibleDirectories,PrivateTmpи т.д.) - Запрет доступа к сети (одно использование
PrivateNetwork) - Запрещение изменений UID (
NoNewPrivileges) - Фильтрация определенных системных вызовов (
SystemCallFilter)
Все вышеперечисленное можно использовать для дальнейшего ограничения поведения процессов, которые будут инициированы системой init. Вы можете получить некоторую степень комфорта от таких ограничений, которые считаете нужным.
Пока что я не видел широкого их применения и не заметил серьезных попыток заблокировать различные сервисы до максимально возможного уровня с помощью systemd. Тем не менее, я не знаком с внутренним движением каждого проекта и т.д., Так что поверьте мне на слово.
Arch Linux обычно пытается использовать программное обеспечение из исходных текстов с минимальными изменениями, насколько это возможно. Насколько я понимаю, вместо того, чтобы поддерживать нашу собственную систему, было просто решено использовать systemd, поскольку кажется, что она станет де-факто (будь то вопрос де-юре предметом дискуссии) стандартной системой инициализации. Следовательно, меньше работы для сопровождающих Arch Linux.
И последнее замечание: Arch Linux никогда не использовал update-rc, chkconfig или что-то подобное. Это Debianisms, Fedora/RedHat/CentOS/ whatisms и т.д. Я бы посоветовал убрать это из вопроса. systemctl - это просто интерфейс к процессу systemd , такой как telinit для SysV, поэтому я также предлагаю удалить это. Arch Linux действительно пытался скрыть подоплеку SysV с помощью своей собственной BSD-подобной системы инициализации, хотя я бы оставил это. В конце концов, что-то вроде «Почему systemd заменяет SysV/ BSD init?«должно быть более уместным.