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?

Improve this question

1 Answer 1

Reset to default
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

Improve this answer
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. Commented Jun 18, 2024 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)? Commented Jun 18, 2024 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. Commented Jun 18, 2024 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. Commented Jun 18, 2024 at 22:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.