os_root_disable alternative implementation #123

New Issue

michael · 2026-01-19T18:29:18Z

michael commented

2026-01-19 18:29:18 +00:00

Originally created by @nihil-admirari on GitHub.

os_root_disable sets root's shell to /bin/false.

CIS benchmark's “5.6 Ensure the "root" Account Is Disabled,” on the other hand, checks the absence of authentication authority

/usr/bin/sudo /usr/bin/dscl . -read /Users/root AuthenticationAuthority

(should return “No such key”·, since root is disabled by default), otherwise it disables root using a special command:

/usr/bin/sudo /usr/sbin/dsenableroot -d

Is there any advantage to setting root's shell to /bin/false compared to what CIS is suggesting?

Originally created by @nihil-admirari on GitHub. [os_root_disable](https://github.com/usnistgov/macos_security/blob/main/rules/os/os_root_disable.yaml) sets root's shell to `/bin/false`. CIS benchmark's “5.6 Ensure the "root" Account Is Disabled,” on the other hand, checks the absence of authentication authority ```sh /usr/bin/sudo /usr/bin/dscl . -read /Users/root AuthenticationAuthority ``` (should return “No such key”·, since root is [disabled by default](https://support.apple.com/guide/directory-utility/about-the-root-user-dirub32398f1/6.4/mac/14.0)), otherwise it disables root using a special command: ```sh /usr/bin/sudo /usr/sbin/dsenableroot -d ``` Is there any advantage to setting root's shell to `/bin/false` compared to what CIS is suggesting?

michael closed this issue

2026-01-19 18:29:18 +00:00

michael commented

2026-01-19 18:29:19 +00:00

@tcoliver commented on GitHub:

My assumption is that the choice to set the root shell instead of using the dsenableroot utility is purely practical though not ideal.

dsenableroot -d always prompts for a user password when run (even when run as root via sudo). There are flags (-u username -p password) which let it run silently, but they would require putting a local administrator username and password in plain text in the remediation script. Also, the root account cant be used as it has no associated password for that account (unless of course the computer is out of compliance with this rule ;D ).

This in mind, I don't see how using the dsenableroot utility could be done in a safe manor, thus the fallback to swapping the shell to /bin/false.

@tcoliver commented on GitHub: My assumption is that the choice to set the root shell instead of using the dsenableroot utility is purely practical though not ideal. `dsenableroot -d` always prompts for a user password when run (even when run as root via sudo). There are flags (`-u username -p password`) which let it run silently, but they would require putting a local administrator username and password in plain text in the remediation script. Also, the root account cant be used as it has no associated password for that account (unless of course the computer is out of compliance with this rule ;D ). This in mind, I don't see how using the dsenableroot utility could be done in a safe manor, thus the fallback to swapping the shell to /bin/false.

michael commented

2026-01-19 18:29:19 +00:00

@robertgendler commented on GitHub:

If you set the shell to /usr/bin/false it prevents login at the GUI, Terminal, ssh, or whatever EVEN if you have enabled root. But it must be set to /usr/bin/false which exists vs a shell path that does not.

This will prevent also from using su or sudo -i to login as root.

@robertgendler commented on GitHub: If you set the shell to `/usr/bin/false` it prevents login at the GUI, Terminal, ssh, or whatever EVEN if you have enabled root. But it must be set to `/usr/bin/false` which exists vs a shell path that does not. This will prevent also from using `su` or `sudo -i` to login as root.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#123