4

I'm reading Linux All-in-One for Dummies and it recommends verifying that the permissions on /etc/shadow are set to 400 (p. 456). Elsewhere on this site, I see that some distros set this to 600 instead, allowing write in addition to read. I'm curious which is the better practice and why.

Since the owner is root:root, root can just chmod to 600 whenever it wants to edit it anyway, so is the distinction meaningful? Is there a specific threat model addressed by choosing 400 instead of 600 for a root-owned file, or is it just about following the best practice of assigning minimal permissions? And doesn't the system (as root) have to edit the file when a user legitimately changes their password?

1 Answer 1

5

At best, it shows that you're following the practice of granting least privileges and are hardening your system to a specific guideline. At worst, it's security theater.

If the /etc/shadow file is configured properly for the OS, then setting the permissions to read/write or read for the owner (root) has little effect. Because root is normally assigned all Linux capabilities, it can read/edit any file, and changing the permissions to 600, 400, or even 000 does not matter. I added the 000 because newer versions of some CIS Benchmarks recommend it.

The only difference I have found between 600 and 400/000 is a warning if you edit the file that it's a read-only file. In vi, forcing a write (:w!) will override that warning. Point of interest: if a file does not contain an execute bit (i.e. 666, or 000), root cannot execute it.

Also, users can change their passwords because a setuid bit is set on /usr/bin/passwd. Without it, users would be unable to change their passwords.

-rwsr-xr-x 1 root root 72344 Feb 4 20:28 /usr/bin/passwd

4
  • 1
    It looks like setting the permissions to 000 is supposed to prevent root from accessing /etc/shadow after the DAC_OVERRIDE capability has purposely been dropped. But I cannot tell whether this is actually effective against attacks or just a way to avoid accidental modifications.
    – Ja1024
    Commented Jun 18 at 15:48
  • So, when I use passwd (as non-root) to change my password, does passwd (after setting its uid to 0) have to temporarily chmod /etc/shadow to make it writeable? Would this introduce a race condition where you could "break" your system's CIS compliance by killing passwd just at the right moment (when /etc/shadow has 600 instead of 000 permissions)?
    – Max
    Commented Jun 18 at 21:25
  • I've seen experimental OSs removing capabilities from root, the threat would need to be very high for me to consider implementing it. You'd also need to remove capabilities like CAP_FOWNER, and CAP_CHOWN. Possible, yes. I'm not signing up for it.
    – kenlukas
    Commented Jun 18 at 22:35
  • The passwd command does not change the file permissions. It does a setuid command to allow the process to change /etc/shadow and then removes it. While it's unlikely that passwd will allow you to break out, gtfobins has a long list of programs that will.
    – kenlukas
    Commented Jun 18 at 22:44

You must log in to answer this question.

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