Temos uma verificação de linha de base automatizada que gera um alerta se as permissões /etc/shadow
não estiverem definidas como 000.
A equipe que recebe esses alertas começou a questionar a sanidade de 000, já que o root pode ler e escrever onde quiser (todos os arquivos são automaticamente pelo menos 600 para root) mas o root não pode executar um arquivo sem o conjunto de permissões de execução (não permissão automática de 700 arquivos para root).
Definir /etc/shadow
permissões para 000 está em várias linhas de base, por exemplo, os playbooks Ansible no repositório oficial do Red Hat GitHub (para PCI DSS, CJIS, NIST, CCE).
Existe uma história de origem por trás de por que /etc/shadow
deveria ser 000 e não, por exemplo, a funcionalidade aparentemente idêntica 600? Ou minhas suposições estão erradas sobre o quão restritivo / permissivo o Linux é para o usuário root?
A ideia por trás da configuração
/etc/shadow
de permissões para 000 é proteger esse arquivo de ser acessado por daemons, mesmo quando executado como root, garantindo que o acesso seja controlado peloDAC_OVERRIDE
recurso . Desde o Fedora 12 e o RHEL 6, os sistemas baseados no Fedora executam daemons semDAC_OVERRIDE
, mas concedemDAC_OVERRIDE
sessões de login ao administrador (para que a alteração seja invisível para os administradores).Consulte os recursos do processo inferior para obter detalhes.
Isso se baseia no fato de que 600 e 000 permissões não são funcionalmente idênticas: 600 concede leitura e gravação ao proprietário do arquivo, enquanto 000 concede acesso apenas a processos com a
DAC_OVERRIDE
capacidade. Tradicionalmente, rodar como root sempre concedeuDAC_OVERRIDE
, mas isso não precisa ser o caso.(O SELinux também pode ser usado para limitar as habilidades do root, mas não é isso que está envolvido aqui.
/etc/shadow
tem seu próprio contexto SELinux, fornecendo controles de acesso adicionais.)