Meilleures pratiques en matière de sécurité des autorisations / etc / shadow (000 contre 600 contre 640)
Nous avons une vérification de base automatisée qui déclenche une alerte si les autorisations sur /etc/shadow n'est pas défini sur 000.
Le personnel qui reçoit ces alertes a commencé à remettre en question le bon sens de 000, car root peut lire et écrire où il veut (tous les fichiers sont automatiquement au moins 600 pour root) mais root ne peut pas exécuter un fichier sans exécuter le jeu d'autorisations (non autorisation de fichier 700 automatique pour root).
Réglage /etc/shadow les autorisations pour 000 se trouvent dans un certain nombre de lignes de base, par exemple les playbooks Ansible dans le référentiel officiel Red Hat GitHub (pour PCI DSS, CJIS, NIST, CCE).
Y a-t-il une histoire d'Origine derrière pourquoi /etc/shadow doit être 000 et non par exemple la fonctionnalité apparemment identique 600? Ou mes hypothèses sont-elles erronées sur la façon dont Linux est restrictif/permissif pour l'utilisateur root?
L'idée derrière la définition des autorisations /etc/shadow Sur 000 est de protéger ce fichier contre tout accès par les démons, même lors de l'exécution en tant que root, en s'assurant que l'accès est contrôlé par le DAC_OVERRIDEcapacité . Depuis Fedora 12 et RHEL 6, les systèmes basés sur Fedora exécutent des démons sans DAC_OVERRIDE, Mais accordent DAC_OVERRIDE Aux sessions de connexion administrateur (de sorte que la modification soit invisible pour les administrateurs).
Voir capacités de processus inférieures pour plus de détails.
Cela repose sur le fait que 600 et 000 autorisations ne sont pas identiques sur le plan fonctionnel: 600 octroient la lecture-écriture au propriétaire du fichier, tandis que 000 accorde uniquement l'accès aux processus avec la capacité DAC_OVERRIDE. Traditionnellement, l'exécution en tant que root accordait toujours DAC_OVERRIDE, Mais cela ne devait pas être le cas.
(SELinux peut également être utilisé pour limiter les capacités de root, mais ce n'est pas ce qui est impliqué ici. /etc/shadow A son propre contexte SELinux, offrant des contrôles d'accès supplémentaires.)