/etc/shadow permissions security best practice (000 vs. 600 vs. 640)
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).
/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.)