File Integrity of Password Files
Password files on Linux are used to store user details, like your unique user ID and name. It defines who you are on the system, your access to files, and the permissions you have. Proper password management, together with file integrity of your password files, is important. It keeps your system and user accounts safe.
For most Linux distributions there are two related files available: /etc/passwd and /etc/shadow. The first file defines what local users are available on the system. Fields include an identifier code (your user ID), your username, and an informational field named GECOS. This last field provides (optional) details about you, like contact details. The /etc/shadow file is a cloned file of /etc/passwd, with the exception that it does store the related password of users. It has different file permissions, to avoid others from snooping at your password, or a hashed form of it.
Why File Integrity Testing?
One of the overlooked areas on Linux systems, is actually the integrity of your password files. After all, when everything works, why bother looking into it? One reason is that small errors there, might result in serious security errors at a different place. The password files are an important defense mechanism to allow only authorized people and processes to have access to system resources.
One of the things that can happen is a double user ID. This might be by accident, or on purpose (intruder). The best example is two users with a user ID of zero. Normally you just want the root user to have this ID, and definitely not any other use.
What Can be Wrong?
With every file we edit, a lot can go wrong within the file itself. As we are dealing here with a password file, duplication and typos are the most common. Let’s have a look at the things we have to check for sure:
The easiest check to do is counting the amount of columns. It should cover all specified fields, from UID to the GECOS field.
Every user ID should be unique. While it was common in the past to give multiple system administrators the UID of zero, this is considered now bad practice. The usage of sudo is well known, and should be used instead. For group files (/etc/group and /etc/gshadow) the same principle applies. The user ID itself should be within the range of 0-65535, or more restricted by what your /etc/login.defs specifies.
Harmony with Shadow Files
The shadow files (/etc/shadow and /etc/gshadow) should have the same lines as the files they represent. So if you have a user in /etc/passwd, it should be in the shadow file as well.
To avoid issues with usernames, they should only use normal characters. The maximum length on Linux is 32 characters. Otherwise, the username will be considered invalid by tools like useradd. Also it may contain numbers, but not strictly of numbers.
Missing Home Directories
For a normal user it would be strange to have an account, yet no home directory. It might drop the user into the root directory, directly after logging in.
Changing Your Password Files the Right Way
To prevent most of the integrity issues, changes should be made with the vipw or vigr command.
This command is a wrapper utility. It makes a temporary copy of the file, then performs integrity tests before writing it to (final) password file.
If you want to change your group files, or shadow file, then use -g (groups), or -s (shadow). Combine them both for changing the shadow group file (/etc/gshadow). Or if you feel rather using vigr, use that instead.
Verification of Password Files with pwck
We love automation. Fortunately, most of the checks above can be done quickly with the pwck utility. The first time you run it, we suggest doing a read-only check.
The output might look something like:
Now it is time to check its findings and determine the impact of each finding.
Found some issues in your password files? Share them in the comments!