25

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?

Improve this question

1 Answer 1

Reset to default
42

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

Improve this answer
7
  • 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
    Commented Oct 30, 2019 at 20:01
  • 2
    @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
    Commented Oct 30, 2019 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
    Commented Oct 30, 2019 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
    Commented Oct 31, 2019 at 18:16
  • 1
    (As a general comment, the purpose of my answer is to explain why /etc/shadow is 000. I’m not commenting on whether the approach which led to that state of things is good or bad, or the best approach, or whether it was in 2009.)
    – Stephen Kitt
    Commented Oct 31, 2019 at 19:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .