Set System File Permissions

What the Linux file permission hardener does

This Automox Worklet™ hardens file permissions and ownership across the Linux system files that CIS Benchmark section 6.1 calls out as security-critical. The Worklet runs chmod and chown in a single remediation pass, stripping group and other read/write/execute bits from credential and boot files and enforcing root:root ownership on GRUB configuration. It targets the standard paths shipped by every mainstream distribution, so one policy covers RHEL, CentOS, Rocky, Alma, Ubuntu, and Debian fleets.

The covered files fall into five groups. Credential files (/etc/passwd, /etc/group, /etc/shadow, /etc/gshadow and their dash-suffixed backups) have group and other bits stripped so only root retains access to the shadow files. GRUB boot configuration (/boot/grub2/grub.cfg and /boot/grub2/user.cfg) has group and other read/write/execute bits removed and ownership set to root:root so an unprivileged user cannot read or modify the boot chain. Cron directories (/etc/cron.d, /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, /etc/cron.monthly, /etc/crontab, /etc/cron.allow) have group and other bits stripped to 700 to prevent unauthorized job injection.

The remaining groups cover SSH daemon configuration (/etc/ssh/sshd_config, group and other bits stripped), system banner files (/etc/motd, /etc/issue, /etc/issue.net set to 644), and log files under /var/log where group write/execute and other read/write/execute bits are removed recursively. The evaluation script exits 1 unconditionally on every run, so the remediation pass fires on each agent check-in.

Why harden Linux system file permissions

Permission drift on Linux endpoints is one of the highest-signal findings in any CIS audit. A world-readable /etc/shadow leaks hashes that an unprivileged user can carry off the box for offline cracking. A writable GRUB configuration lets a local attacker pin a kernel command line that disables SELinux on the next boot. A loose /etc/cron.d directory lets any local account schedule a job as root. CIS Benchmark section 6.1 ("System File Permissions") lists more than a dozen sub-controls that map directly to this Worklet’s chmod and chown actions, and the same controls feed PCI-DSS section 2.2 and NIST 800-53 AC-3.

File-mode bits on system files drift because every actor with root can change them. A package upgrade restores world-readable bits on /etc/passwd, an admin edits sshd_config and leaves it group-readable, a developer chmods a /var/log directory to debug an agent and forgets to revert. Because the evaluation script exits 1 unconditionally, the Worklet re-applies chmod and chown on every agent check-in - idempotent operations that are cheap to repeat and guarantee drift is corrected across servers, container hosts, and developer workstations.

How Linux permission hardening works

1. Evaluation phase: The evaluation script exits 1 unconditionally, scheduling remediation on every policy run. Treat this as a continuous enforcement Worklet rather than a one-shot script: idempotent chmod and chown operations are cheap to repeat, and the always-run model guarantees drift is corrected the next time the agent checks in. To gate the policy to specific endpoint groups, scope the policy in the Automox console rather than editing the evaluation script.

2. Remediation phase: The remediation script walks each target group in sequence using symbolic chmod notation. It strips group and other read/write/execute bits from /boot/grub2/grub.cfg and /boot/grub2/user.cfg, then sets chown root:root on both GRUB files. It sets /etc/motd, /etc/issue, /etc/issue.net, /etc/passwd, and /etc/group to 644 (u+rw,g+r,o+r). It strips group and other bits from /etc/shadow, /etc/gshadow, /etc/ssh/sshd_config, all cron directories, and all dash-suffixed credential backups. It removes group write/execute and other read/write/execute bits recursively from /var/log. If a target path is absent, chmod and chown emit a standard error to stderr and the script continues to the next target.

CIS file permission baseline requirements

• Linux endpoint running a CIS-aligned distribution: RHEL, CentOS, Rocky, Alma, Ubuntu, or Debian with the standard /etc and /boot/grub2 layout

• Root privileges for the Automox agent (the default agent context already meets this)

• GRUB 2 boot loader installed at /boot/grub2/ with grub.cfg and user.cfg present; paths that are absent will produce a chmod error to stderr but will not abort the script

• Optional: a baseline scan with an existing CIS scanner before the first run, so you can diff the before-and-after permission set in audit evidence

• Log aggregation tooling that runs as root, or as a group member explicitly granted read on /var/log; agents that depend on world-readable logs will need adjustment after this Worklet runs

• Compatible with workstations, servers, and container hosts; not intended for minimal Alpine or BusyBox images that do not ship the GNU coreutils chmod and chown binaries on the standard path

Expected file permission state after hardening

After remediation completes, ls -la on the targeted paths returns the expected mode and ownership. /etc/passwd and /etc/group read as -rw-r--r-- 1 root root, /etc/motd and /etc/issue files read as -rw-r--r-- 1 root root, GRUB files under /boot/grub2/ read as -rw------- 1 root root with root:root ownership, and cron directories read as drwx------ 2 root root. Shadow files and /etc/ssh/sshd_config have group and other bits stripped; their exact user bits depend on the state before the Worklet ran. The Automox activity log captures stdout and the remediation exit code for each run.

System operation continues normally. Services that need to read these files do so as root or as a group member that already has the right bits set. End user logins, sudo, SSH, and cron all behave the same after the Worklet runs. The one operational change to watch for is log aggregation: if a non-root agent was reading /var/log via the other-read bit, add it to a group with explicit read on the directory or run it under a privileged context. Validate by running stat -c '%a %U:%G %n' /etc/passwd /etc/ssh/sshd_config /boot/grub2/grub.cfg on a sample endpoint and confirming that /etc/passwd shows 644, while /etc/ssh/sshd_config and /boot/grub2/grub.cfg both show 600. Because the evaluation script always exits 1, the next policy run re-applies the mode set if a package update or admin command resets a file.