Prevent Sudoers Configuration Tampering
Block direct writes to /etc/sudoers and sudoers.d except via sudo, stopping attackers from creating persistent root privilege escalation backdoors.
Idea
The sudoers file controls which users can execute commands with elevated privileges on macOS. Attackers who modify this file can grant themselves unrestricted root access, bypassing password requirements and creating persistent privilege escalation backdoors.
This file access rule prevents the sudoers configuration from being modified by any process except sudo itself. With this rule in place, even root-level malware cannot directly edit the sudoers file. Users must use the proper sudo -e /etc/sudoers or visudo commands to make legitimate changes, which provides additional safety checks.
This rule protects not just /etc/sudoers but also the sudoers.d directory where additional configurations can be placed, and the sudo timestamp database that tracks recent sudo usage.
Solutions
- Paths
- •
- •
- •
- Policy
- Access Type
- Processes
- •Signing ID:
- •
- Custom Message
Mitre Attack
Tactics
Techniques
Tags
Deployment Notes
This rule blocks all write access to sudoers files except from the sudo binary itself. This means:
- Direct file editing with vim, nano, etc. is blocked
- Legitimate changes must use
sudo -e /etc/sudoersorvisudo - The sudo binary is the only process that can write to these files
- Even processes running as root are blocked unless they're sudo itself
The rule allows all processes to read the sudoers files, which is necessary for sudo to function properly.
Note that this does not prevent users with sudo privileges from adding themselves to sudoers via the proper sudo commands. It only prevents direct file manipulation that bypasses sudo's safety checks.
False Positive Guidance
Very few legitimate processes need to directly modify sudoers files:
- System installers may need to add entries (handled by sudo itself)
- Configuration management tools (Puppet, Chef, Ansible) may need exceptions
- Security tools that audit sudo configuration should only need read access
If you use configuration management tools, add their signing IDs to the allowlist.
Testing Instructions
- Try to edit sudoers directly:
sudo vim /etc/sudoers(should be blocked) - Use proper sudo editor:
sudo -e /etc/sudoers(should work) - Try to edit sudoers.d:
sudo touch /etc/sudoers.d/test(should be blocked without using sudo -e) - Verify read access works:
sudo cat /etc/sudoers(should work)
Detection Methods
Monitor for FAA events showing blocked attempts to write to:
- /private/etc/sudoers
- /private/etc/sudoers.d/
- /private/var/db/sudo/ts/
Repeated blocks from the same process may indicate malware attempting privilege escalation.