In this blog post, we’ll examine a few security best practices around group, password and shadow files – and evaluate the IT Best Practices rules and see why and how they have to be modified slightly for Debian-based systems when we implement them in the Assimilation suite.

Many of the IT Best Practices rules are based on the RHEL6 DISA STIGs that are published by NIST here in the US. Most of those rules apply directly on any Linux machine, and some apply more generally to other POSIX systems as well. But there are differences between systems which sometimes come up in looking at these best practices. In this article, we’ll talk about a few such rules.

Security Best Practices Around Group, Password and Shadow Files

The /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow files are common across most POSIX systems and are nearly identical. However, there are some minor differences that turn out to matter for this particular set of best practices on Linux systems. But first, let’s see what the rules say, and what the problem is.

Rules for /etc/passwd and /etc/group

The passwd and group files contain information for translating user and group id numbers into names, provide information about home directories and a variety of other information which is not highly security sensitive.

The rules for the permissions of /etc/passwd and /etc/group are pretty straightforward – they state that these files should be owned by root [nist_V-38450, nist_V-38458], grouped to group root [nist_V-38451, nist_V-38459], and not executable by anyone, or writable by group or other [nist_V-38457, nist_V-38461]. As far as I know, these rules apply to any POSIX system. Of course there are other best practices that aren’t security related – stating that these files all must be readable by the world. If not, lots of bad things happen – but those bad things aren’t security related.

Rules for /etc/shadow and /etc/gshadow

The shadow and gshadow files contain encrypted password for logins and groups. This kind of information is useful for brute-force cracking and a variety of other nefarious activities. As a result, their contents are highly security sensitive.

In spite of this, the STIG rules for these files are somewhat similar to those for passwd and group files – they have to be owned by root [nist_V-38502, nist_V-38443] and grouped to root [nist_V-38503, nist_V-38448], but because of the sensitive nature of the shadow and gshadow files, they must not be generally readable [nist_V-38504, nist_V-38449]. The STIGs state that they both have to be mode 0000 since root can read whatever it wants regardless of permissions.

This is where the differences come in. On Debian-based systems there are are a few utilities that only need to read the shadow and gshadow files, but don’t need to write them. To better protect these critical files, they made the choice to create a group called shadow whose only permission is to be able to read these two files, and made these commands set-group-id to shadow. There are no files on the system which are writable by group shadow, and only these two files that are readable by group shadow.

The effect of this is that these commands cannot be coerced into modifying these files, so that is felt to be more secure than making a setuid-root command to do the same thing. Since no logins belong to group shadow, only root can make a command to be set-group-id to shadow.

However, this means that if one were to follow the RHEL6 STIG rules on a Debian-based system, these commands would not work. So in the Assimilation implementation of these rules, we chose to say that these shadow files can be grouped to either shadow or root, and that if they are grouped to shadow, that it is permissible for them to be group-readable. Since Red Hat doesn’t have a group shadow, this means that on Red Hat based systems, our implementation does exactly what the original STIG said to do, and also follows best practices for Debian-based systems as well.

Summary

In the Assimilation Cybersecurity software, we have now implemented these rules, and they will notify you when your systems are not in compliance with best practices for these rules as well as many others.