Não exatamente. Na verdade, o antigo sistema rc.d init é muito mais fácil de auditar, dado que é escrito em shell script ( edit : exceto para o próprio daemon de inicialização, escrito em C) e é muito mais curto . O sistema init 'antigo' em si não é muito mais ou menos seguro per se ( editar : embora tenha mais código e uma interface dbus - mais espaço para erros , etc.). O systemd tem melhor isolamento dos processos que gerencia, desde o início, colocando-os em seus próprios cgroups, mas isso por si só não faz muito em si, exceto os robustos processos de rotulagem. Pode ser comparado com a seguinte conversa.
- Aqui está esse grupo de trabalhadores, e aqui está outro monte. Nós os separamos em grupos. Eles não podem mudar de grupo. Apenas o supervisor pode definir seu grupo.
- Ok. Mas você fez mais alguma coisa?
- Não.
- Você aplica regras como "o grupo A precisa apenas de acesso a esses recursos, para que eles tenham permissão apenas para acessar esses recursos"?
- Não.
- Você isola completamente cada grupo de outro?
- Não.
Assim como o SysV init, o antigo sistema de init do Arch Linux (que realmente é construído sobre o SysV), systemd, etc. você obviamente tem algumas configurações básicas das diferentes coisas (para evitar ser específico) que são automaticamente gerenciados (iniciados na inicialização, em tempo arbitrário x , ou mortos quando os porcos aprendem a voar de repente). Essas coisas (unidades como systemd as chama), tem algum tipo de interface de configuração (no systemd, um arquivo de coonfiguração semelhante ao INI, suporta dizer ao systemd para fazer uso de alguns recursos do kernel Linux que podem aumentar o segurança do seu sistema.Aqui estão alguns exemplos, extraídos de systemd.exec(5) :
- Lista de permissões de nó de dispositivos e listas negras para esse processo (
DeviceAllow,DeviceDeny) - Espaçamento de nomes do sistema de arquivos (
ReadWriteDirectories,InaccessibleDirectories,PrivateTmp, etc.) - Negando acesso à rede (um uso de
PrivateNetwork) - Negando alterações de UID (
NoNewPrivileges) - Filtrando chamadas específicas do sistema (
SystemCallFilter)
Todos os itens acima podem ser usados para restringir ainda mais o comportamento dos processos que serão gerados pelo sistema init. Você pode obter alguma medida de conforto de tais restrições como achar melhor.
Agora, até agora, eu realmente não vi nenhum uso generalizado destes, nem notei nenhum esforço sério para bloquear vários serviços ao nível máximo possível com o systemd. Dito isto, eu não estou familiarizado com os acontecimentos internos de cada projeto, etc., então tome minha palavra com um grão de sal.
O Arch Linux geralmente tenta usar software de fontes upstream com a menor modificação possível. Entendo que, em vez de ter que manter nosso próprio sistema, foi decidido usar o systemd, pois parece que ele se tornará o de fato (seja de jure é uma questão para debate) sistema de inicialização padrão. Assim, menos trabalho para os mantenedores do Arch Linux.
Uma nota final, o Arch Linux nunca usou update-rc, chkconfig nem nada parecido. Esses são os Debianisms, Fedora / RedHat / CentOS / whateverisms, etc. Eu sugiro remover isso da questão. systemctl é apenas uma interface para o processo systemd , como telinit para o SysV, portanto, sugiro também removê-lo. O Arch Linux tentou esconder os alicerces do SysV com seu sistema de iniciação inicial semelhante ao BSD, embora eu deixasse isso. No final, algo como "Por que o sistema está substituindo o init SysV / BSD?" deve ser mais apropriado.