Linux User Accounts (root vs. Regular User, sudo Mechanics)

#Root Is a Liability, Not a Right: Designing a Sudo-Based Access Model#link

The root account is the ultimate all-access pass on Linux. In 2020, attackers exploited a misconfigured AWS instance where the application ran as root, leading to full database exfiltration. If the app had been running as a dedicated user with only required capabilities, the damage would have been contained. This lesson teaches how to lock down the root account, construct precise sudo rules, and understand the sudo session lifecycle to minimize privilege exposure.

Disabling Interactive root Access

The root account should never be used for direct login. Disable its password with passwd -l root and set an expired or impossible password hash. Ensure SSH is configured with PermitRootLogin no. On systems that require recovery console access, set a grub password and enforce single-user mode authentication. The only path to root should be via sudo from authorized users, providing an audit trail.

After this, even if someone guesses the root password, they can't get a shell. The account still exists for UID 0 process ownership, but interactive login is impossible.

# Harden /etc/pam.d/login to enforce login restrictions
echo 'auth required pam_securetty.so' >> /etc/pam.d/login
# and remove all ttys except tty1 from /etc/securetty

Crafting Precise Sudo Rules

Avoid blanket sudo ALL=(ALL) ALL entries. Instead, define command aliases and per-user rules with allowed command paths and arguments. Use the NOPASSWD flag sparingly and only for specific commands. Combine with timestamp_timeout=0 to force credential re-entry for every sudo invocation, reducing the risk of session hijacking. Implement centralized sudo policy management with LDAP (sudoers.ldap) for consistency across servers.

# /etc/sudoers.d/ops
# Operator group can restart services but not edit configs
%operator ALL=(root) /usr/bin/systemctl restart apache2, /usr/bin/systemctl status *
Defaults:%operator timestamp_timeout=0

This rule permits operators to restart Apache and check service statuses, but not to stop or modify services. The wildcard 'status *' uses sudo's limited pattern matching, while restart is explicitly allowed only for apache2.

Monitoring and Auditing Sudo Activity

Sudo logs to syslog by default, but you can enhance it by enabling sudo's I/O logging (log_input, log_output) to capture entire session transcripts. Forward these logs to a centralized SIEM. Set up alerts for failed sudo attempts and for commands that are outside the expected usage pattern. The sudoers option mail_badpass sends an email on a failed password attempt, providing real-time notification of potential brute-force.

• ▪Lock the root account and disable root SSH login.
• ▪Migrate all admin actions to sudo with command-specific rules.
• ▪Set timestamp_timeout=0 and avoid NOPASSWD for interactive users.
• ▪Enable sudo I/O logging and ship logs to a central collector.
• ▪Use a configuration management tool to enforce sudoers files.