rules/os/os_root_disable does more than prevent root login- it breaks functionality (and isn't actually needed) #14

New Issue

michael · 2026-01-19T18:28:56Z

michael commented

2026-01-19 18:28:56 +00:00

Originally created by @lattwood on GitHub.

Summary

rules/os/os_root_disable.yaml sets the root shell to /usr/bin/false (or /sbin/nologin if #591 is merged).

breaks sudo -i and forces users to take an unsafe approach of sudo $SHELL
isn't actually needed due to Apple shipping with root disabled in Directory Services

Details

Changing the shell to prevent login breaks sudo -i, which is used for getting a root shell safely. Without using -i, you have to run sudo zsh, which means HOME and other environment variables are inherited from the current user. This sets them up to accidentally create files owned by root in their actual home directory, and to that end, zsh complaints about ownership of compinit files in the home directory when started this way.

It turns out that Apple actually disables root login OOTB (at least on Tahoe).

There is a shell utility (that requires a password when run by anyone other than root)- https://ss64.com/mac/dsenableroot.html.

That program properly enables and disables the root account in Directory Services. Based on the implementation of that program, here are the correct steps for disabling and enabling the root account- which doesn't require touching root's shell.

Steps to disable root

Note: this is the default state of the operating system, and they're prefixed with sudo for completeness.

# Remove the authentication authority
sudo dscl . -delete /Users/root AuthenticationAuthority

# Set password to the disabled marker
sudo dscl . -create /Users/root Password "*"

Steps to enable root

Note: this is overly verbose, you may only need to set a password at the cli through dscl, and the commands are prefixed with sudo for completeness.

# Generate a new UUID for the root user (if it doesn't have one)
sudo dscl . -create /Users/root GeneratedUID $(uuidgen)

# Set up ShadowHash authentication
sudo dscl .  -create /Users/root AuthenticationAuthority ";ShadowHash;HASHLIST: <SALTED-SHA512-PBKDF2>"

# Set the password marker (actual hash stored separately)
sudo dscl . -create /Users/root Password "********"

# Set the actual password (this prompts securely)
sudo dscl . -passwd /Users/root

Steps to reproduce

Apply rules/os/os_root_disable.

Operating System version

Tahoe

Intel or Apple Silicon

Apple Silicon

What is the current bug behavior?

root's shell gets set to /bin/false.

It also appears this rule's fix/check was copied from a 2017 blog post- https://derflounder.wordpress.com/2017/03/19/disabling-login-to-the-root-account-by-changing-the-root-accounts-user-shell/ and doesn't adhere to Apple's own documentation here- https://support.apple.com/en-ca/102367 (this indicates on a machine w/o rules/os/os_root_disable applied, that root is disabled, and root's shell is still set to /bin/sh, indicating that changing root's shell is not a supported method to disable the Root User. Search results of Apple's public Support site also agrees with this- https://www.google.com/search?q=%22disable+root%22+site%3Asupport.apple.com

What is the expected correct behavior?

root should be verified as disabled via the use of dscl commands checking AuthenticationAuthority and Password, and disabled if needed by using dscl to set the Password to the "account disabled marker" of * and removing the AuthenticationAuthority key.

Originally created by @lattwood on GitHub. ### Summary `rules/os/os_root_disable.yaml` sets the root shell to `/usr/bin/false` (or `/sbin/nologin` if #591 is merged). * breaks `sudo -i` and forces users to take an unsafe approach of `sudo $SHELL` * isn't actually needed due to Apple shipping with `root` disabled in Directory Services #### Details Changing the shell to prevent login breaks `sudo -i`, which is used for getting a root shell _safely_. Without using `-i`, you have to run `sudo zsh`, which means `HOME` and other environment variables are inherited from the current user. This sets them up to accidentally create files owned by `root` in their actual home directory, and to that end, `zsh` complaints about ownership of `compinit` files in the home directory when started this way. It turns out that Apple actually disables root login OOTB (at least on Tahoe). There is a shell utility (that requires a password when run by anyone other than root)- https://ss64.com/mac/dsenableroot.html. That program properly enables and disables the root account in Directory Services. Based on the implementation of that program, here are the correct steps for disabling and enabling the root account- which doesn't require touching root's shell. ##### Steps to *disable* root Note: this is the default state of the operating system, and they're prefixed with `sudo` for completeness. ``` # Remove the authentication authority sudo dscl . -delete /Users/root AuthenticationAuthority # Set password to the disabled marker sudo dscl . -create /Users/root Password "*" ``` ##### Steps to *enable* root Note: this is overly verbose, you may only need to set a password at the cli through dscl, and the commands are prefixed with `sudo` for completeness. ``` # Generate a new UUID for the root user (if it doesn't have one) sudo dscl . -create /Users/root GeneratedUID $(uuidgen) # Set up ShadowHash authentication sudo dscl . -create /Users/root AuthenticationAuthority ";ShadowHash;HASHLIST: <SALTED-SHA512-PBKDF2>" # Set the password marker (actual hash stored separately) sudo dscl . -create /Users/root Password "********" # Set the actual password (this prompts securely) sudo dscl . -passwd /Users/root ``` ### Steps to reproduce Apply `rules/os/os_root_disable`. ### Operating System version Tahoe ### Intel or Apple Silicon Apple Silicon ### What is the current *bug* behavior? `root`'s shell gets set to `/bin/false`. It *also* appears this rule's fix/check was copied from a 2017 blog post- https://derflounder.wordpress.com/2017/03/19/disabling-login-to-the-root-account-by-changing-the-root-accounts-user-shell/ and doesn't adhere to Apple's own documentation here- https://support.apple.com/en-ca/102367 (this indicates on a machine w/o `rules/os/os_root_disable` applied, that root is disabled, and root's shell is still set to `/bin/sh`, indicating that **changing root's shell is not a supported method to disable the Root User**. Search results of Apple's public Support site also agrees with this- https://www.google.com/search?q=%22disable+root%22+site%3Asupport.apple.com ### What is the expected *correct* behavior? `root` should be verified as disabled via the use of `dscl` commands checking `AuthenticationAuthority` and `Password`, and disabled if needed by using `dscl` to set the `Password` to the "account disabled marker" of `*` and removing the `AuthenticationAuthority` key.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#14