Почему systemd/systemctl system v?

Не совсем. На самом деле, старая система инициализации rc.d, вероятно, намного проще для аудита, учитывая, что она написана в сценарии оболочки (edit: за исключением самого демона init, написанного на C) и намного короче. Сама по себе "старая" система инициализации на самом деле не так уж и более безопасна (отредактируйте: хотя в ней больше кода и интерфейса 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?" должно быть более уместным.