/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).

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?

Asked By: tsundoku

||

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.)

Answered By: Stephen Kitt
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.