usnistgov/macos_security
1
0
Fork 0
mirror of https://github.com/usnistgov/macos_security.git synced 2026-02-09 08:12:18 +00:00
Code Issues 21 Actions Packages Projects Releases Wiki Activity

checking for authenticated-root hangs forever when multiple OSes are available #193

New Issue
Closed
opened 2026-01-19 18:29:36 +00:00 by michael · 7 comments
michael commented 2026-01-19 18:29:36 +00:00
Owner
Copy Link

Originally created by @cvgs on GitHub.

Originally assigned to: @robertgendler on GitHub.

Summary

When executing the check script for rule 7.2. "Enable Authenticated Root" on a machine that contains multiple OS installations will cause the script to hang indefinitely, because "csrutil" is expecting manual input.

Steps to reproduce

  1. Create two separate installations of macOS on a machine
  2. run the check script for rule "7.2. Enable Authenticated Root", which is basically /usr/bin/csrutil authenticated-root | /usr/bin/grep -c 'enabled'

Operating System version

13.2 (22D49)

Intel or Apple Silicon

Apple Silicon

What is the current bug behavior?

On a test machine with two OS partitions ("Pirates" and "💬", Emoji FTW!) the csrutil will expect "1" or "2" to select the correct OS partition:

# /usr/bin/csrutil authenticated-root status
This computer has several macOS installations:
  1: Pirates
  2: 💬

Pick a macOS installation (1..2):

The script will never provide an answer to csrutil and hangs until terminated.

What is the expected correct behavior?

The command /usr/bin/csrutil authenticated-root statusshould have a parameter to select the current OS partition automatically and report on its status.

Relevant logs and/or screenshots

Once an OS is selected, the proper status is returned.

> /usr/bin/csrutil authenticated-root status
This computer has several macOS installations:
  1: 💬
  2: Pirates

Pick a macOS installation (1..2): 1
Authenticated Root status: enabled

Possible fixes

  • Apple should modify to the csrutil tool so the status of the default OS can be returned automatically
  • We could use an expectscript to try to parse csrutils questions (the OS order is not determinate)
  • The script could use a manual timeout and return an error state
Originally created by @cvgs on GitHub. Originally assigned to: @robertgendler on GitHub. ### Summary When executing the check script for rule 7.2. "Enable Authenticated Root" on a machine that contains multiple OS installations will cause the script to hang indefinitely, because "csrutil" is expecting manual input. ### Steps to reproduce 1. Create two separate installations of macOS on a machine 2. run the check script for rule "7.2. Enable Authenticated Root", which is basically `/usr/bin/csrutil authenticated-root | /usr/bin/grep -c 'enabled'` ### Operating System version 13.2 (22D49) ### Intel or Apple Silicon Apple Silicon ### What is the current *bug* behavior? On a test machine with two OS partitions ("Pirates" and "💬", Emoji FTW!) the csrutil will expect "1" or "2" to select the correct OS partition: ``` # /usr/bin/csrutil authenticated-root status This computer has several macOS installations: 1: Pirates 2: 💬 Pick a macOS installation (1..2): ``` The script will never provide an answer to csrutil and hangs until terminated. ### What is the expected *correct* behavior? The command `/usr/bin/csrutil authenticated-root status`should have a parameter to select the current OS partition automatically and report on its status. ### Relevant logs and/or screenshots Once an OS is selected, the proper status is returned. ``` > /usr/bin/csrutil authenticated-root status This computer has several macOS installations: 1: 💬 2: Pirates Pick a macOS installation (1..2): 1 Authenticated Root status: enabled ``` ### Possible fixes - Apple should modify to the csrutil tool so the status of the default OS can be returned automatically - We could use an `expect`script to try to parse csrutils questions (the OS order is not determinate) - The script could use a manual timeout and return an error state
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

We've added a warning to the rule. I do not believe we'll do any additional fix for this edge case.

@robertgendler commented on GitHub: We've added a warning to the rule. I do not believe we'll do any additional fix for this edge case.
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@hcbraun commented on GitHub:

I also ran into this bug. Would be great to fix this. Running multiple installations on Apple Silicon is actually easy and convenient.

Is there a command to get the current running macOS installation?

@hcbraun commented on GitHub: I also ran into this bug. Would be great to fix this. Running multiple installations on Apple Silicon is actually easy and convenient. Is there a command to get the current running macOS installation?
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

Our warning has been added to ventura, monterey, and big_sur

WARNING: If more than one partition with macOS is detected, the csrutil command will hang awaiting input.

To get the current boot device you can run /usr/sbin/bless --getBoot

Then I think from there you'd use the /usr/sbin/diskutil apfs list and determine the System from there.

@robertgendler commented on GitHub: Our warning has been added to `ventura`, `monterey`, and `big_sur` ``` WARNING: If more than one partition with macOS is detected, the csrutil command will hang awaiting input. ``` To get the current boot device you can run `/usr/sbin/bless --getBoot` Then I think from there you'd use the `/usr/sbin/diskutil apfs list` and determine the System from there.
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@cvgs commented on GitHub:

Getting the volume name can be done like this:

/usr/sbin/diskutil info -plist / | /usr/bin/plutil -extract VolumeName raw -- -

But then you'd need some kind of expect wrapper to select the proper answer.

If you'd just like to prevent stalling, you could do yes -1 | /usr/bin/csrutil authenticated-root status, but that would randomly return incorrect results - though it would err on the side of caution and report "disabled" in the worst case.

Perhaps there is another way to get the authenticated root value?

@cvgs commented on GitHub: Getting the volume name can be done like this: `/usr/sbin/diskutil info -plist / | /usr/bin/plutil -extract VolumeName raw -- -` But then you'd need some kind of `expect` wrapper to select the proper answer. If you'd just like to prevent stalling, you could do `yes -1 | /usr/bin/csrutil authenticated-root status`, but that would randomly return incorrect results - though it would err on the side of caution and report "disabled" in the worst case. Perhaps there is another way to get the authenticated root value?
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

I believe Apple has made it so difficult to dual boot Apple Silicon machines, this is an edge case that may be better suited for us just adding a note in the rule about dual booting.

@robertgendler commented on GitHub: I believe Apple has made it so difficult to dual boot Apple Silicon machines, this is an edge case that may be better suited for us just adding a note in the rule about dual booting.
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

Closing this until Apple adds a better way to check the current booted OS with csrutil.

@robertgendler commented on GitHub: Closing this until Apple adds a better way to check the current booted OS with csrutil.
michael commented 2026-01-19 18:29:36 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

Maybe we could pester apple for an option to the command for current running system like csrutil authenticated-root status --current

@robertgendler commented on GitHub: Maybe we could pester apple for an option to the command for current running system like `csrutil authenticated-root status --current`
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#193
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?