We have an automated baseline check that raises an alert if the permissions on /etc/shadow aren’t set to 000.

The staff who receive these alerts have started to question the sanity of 000, since root can read and write wherever it wants to (all files are automatically at least 600 for root) but root can’t execute a file without execute permission set (no automatic 700 file permission for root).

Setting /etc/shadow permissions to 000 is in a number of baselines, e.g. the Ansible playbooks in the official Red Hat GitHub repository (for PCI DSS, CJIS, NIST, CCE).

Is there an origin story behind why /etc/shadow should be 000 and not e.g. the seemingly functionality identical 600? Or are my assumptions wrong about how restrictive / permissive Linux is for the root user?


The idea behind setting /etc/shadow permissions to 000 is to protect that file from being accessed by daemons, even when running as root, by ensuring that access is controlled by the DAC_OVERRIDE capability. Since Fedora 12 and RHEL 6, Fedora-based systems run daemons without DAC_OVERRIDE, but grant DAC_OVERRIDE to administrator login sessions (so that the change is invisible to administrators).

See lower process capabilities for details.

This relies on the fact that 600 and 000 permissions aren’t functionally identical: 600 grants read-write to the file owner, whereas 000 only grants access to processes with the DAC_OVERRIDE capability. Traditionally, running as root always granted DAC_OVERRIDE, but that doesn’t have to be the case.

(SELinux can also be used to limit root’s abilities, but that’s not what’s involved here. /etc/shadow does have its own SELinux context, providing additional access controls.)

  • 5
    A process with UID 0 could still chmod the file even without caps and then read/write to it, so setting the permissions to 000 doesn't really protect against arbitrary command execution, right? – ilkkachu Oct 30 '19 at 20:01
  • 1
    @ilkkachu true, and I don’t think arbitrary command execution is within the scope of the feature. The idea is to reduce the potential for privilege escalation; compromising a reduced-capability daemon won’t get you very far if it doesn’t also have a gadget to run chmod for you. (I haven’t checked what the SELinux context is used for, that might be relevant for chmod...) – Stephen Kitt Oct 30 '19 at 22:25
  • 1
    See bugzilla.redhat.com/show_bug.cgi?id=517575#c3 for another take on the merits or otherwise of this approach. – Stephen Kitt Oct 30 '19 at 22:37
  • 1
    What is the reasonable scenario where you'd want to run a daemon without DAC_OVERRIDE but with root? It seems you should just get rid of it having root entirely already. – R.. GitHub STOP HELPING ICE Oct 31 '19 at 18:16
  • @R.. if you need other capabilities. For example dhclient needs NET_ADMIN, NET_RAW, and NET_BIND_SERVICE; in Fedora it drops everything but those, but to be able to do so it needs to have them to start with, which in 2009 (when the /etc/shadow change was made) meant running as root. Nowadays (since version 4.3 of the kernel) you could have a launcher which would set up ambient capabilities for a non-root daemon. – Stephen Kitt Oct 31 '19 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.