Linux - Security - Update /Etc/Passwd Permissions

What the /etc/passwd hardening Worklet does

This Automox Worklet™ enforces the CIS Benchmark baseline on /etc/passwd, the world-readable account database that every Linux login, sudo call, and getent lookup depends on. The Worklet reads the file's current mode and ownership, compares them to the required values of 0644 and root:root, and applies chmod or chown only when a deviation is detected. Compliant endpoints exit with no changes.

The evaluation script calls stat with the --printf format string to extract the octal mode, owner UID, and group GID in a single syscall. The remediation script rechecks those three values and runs chmod 0644 /etc/passwd or chown root:root /etc/passwd against only the fields that are out of policy, so the file's timestamp and inode are preserved when no change is needed.

The Worklet runs on RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, and other mainstream distributions. It also applies the CIS-required modes to /etc/shadow (0640), /etc/group (0644), and /etc/gshadow (0640) in the same pass, so a single policy run brings the core account files into compliance together.

Why harden /etc/passwd at fleet scale

/etc/passwd stores the username, UID, GID, home directory, and login shell for every account on a Linux host. CIS Benchmark control 6.1.2 requires the file to be owned by root, grouped to root, and set to mode 0644 or stricter. A world-writable or non-root-owned /etc/passwd lets a low-privilege attacker rewrite an existing account's UID to 0, append a new root-equivalent user, or swap a login shell to a backdoor. The file persists across reboots, kernel upgrades, and package updates, so any single misconfiguration sits in place until something corrects it.

Permission drift on /etc/passwd, /etc/shadow, and the group files comes from predictable directions. A misplaced chmod 666 left behind by a troubleshooting session, a backup tool that resets ownership during a restore, or a custom image that ships with relaxed defaults can each turn any of the four files into a privilege escalation vector. The Worklet runs stat -c '%U:%G %a' on each path on every cycle, compares the result against the CIS Linux Benchmark 6.1.x ownership and mode requirements, and calls chown root:root plus chmod with the right octal mode (0644 on /etc/passwd, 0640 on /etc/shadow) only on the files that have drifted.

How /etc/passwd permission enforcement works

1. Evaluation phase: The script calls stat --printf='%a %u %g' /etc/passwd to read the file's octal mode, owner UID, and group GID in one syscall. If the mode is not 644 (or stricter, such as 600 or 640), or if the owner UID or group GID is not 0, the endpoint is flagged non-compliant and remediation is scheduled. Endpoints already at 0644 root:root return exit code 0 with no further action.

2. Remediation phase: The script rereads the current mode and ownership, then runs chmod 0644 /etc/passwd only if the mode is non-compliant and chown root:root /etc/passwd only if the owner or group is non-compliant. Each correction is logged to stdout so the Automox activity log captures what changed. The script returns 0 on success and a non-zero exit code if stat fails or chmod/chown is denied, which surfaces the failure rather than masking it.

/etc/passwd hardening requirements

• Linux endpoint with a standard /etc/passwd file (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, Amazon Linux, SUSE)

• GNU coreutils stat with --printf support (default on every supported distribution)

• Root context for the Automox agent (the default agent service runs as root and already meets this requirement)

• Read access to /etc/passwd for evaluation, write access for remediation; no kernel modules or third-party packages required

• Pair with the companion /etc/shadow Worklet (chmod 0000) and /etc/group Worklet (chmod 0644) to complete the CIS 6.1.x account-file hardening set

Expected /etc/passwd state after hardening

/etc/passwd is owned by root:root with mode 0644 (rw-r--r--). Root retains read and write access. Every other account on the system retains read access, which is required because getpwnam, getent passwd, ls -l, ps, and most shell prompts query the file for username and home directory resolution. No account can modify the file directly; useradd, usermod, and userdel continue to work because they run under root through PAM.

Validate from a shell with stat -c '%a %U %G' /etc/passwd, which should print 644 root root. The classic ls -l /etc/passwd check returns -rw-r--r-- 1 root root followed by the file size and modification time. A CIS-CAT, OpenSCAP, or Lynis scan that previously flagged 6.1.2 against /etc/passwd returns a pass result on the next run, and the same applies to the equivalent STIG check on hardened RHEL builds.

Subsequent Automox policy evaluations report the endpoint as compliant without applying remediation again, because the evaluation phase finds 0644 root:root already in place. If an administrator runs chmod 666 /etc/passwd during a troubleshooting session, or if a configuration management tool reverts the file, the next scheduled evaluation catches the drift and the Worklet restores the baseline without manual intervention.