If you’re using APFS encryption, you might have stumbled across some odd user names when asked to enter your password to unlock a disk – like FFFFEEEE-DDDD-CCCC-BBBB-AAAA000000C9.
One way of running into this is to make a bootable clone of your APFS encrypted boot volume to an external SSD, then start up from that clone. When you’re invited to enter your password to unlock the internal disk, you may well find odd additional users listed, as well as yourself.
You may be able to replicate this by installing macOS 10.13.4 onto an external drive, ensuring that Guest access is enabled, then turning APFS encryption on. When you connect that external drive to a running High Sierra system, you’ll be prompted to unlock the disk, and may well see similar spurious users listed there as well.
If you use encryption because you have sensitive data on your Mac’s storage, this could appear quite alarming. Has someone hacked into your drive already, or is this another security vulnerability in High Sierra?
The answer is that there is nothing wrong with this behaviour, a guest user can’t unlock your encrypted volume, and it isn’t a vulnerability, or even a bug. I don’t think that High Sierra should be doing it, but when it does, there is no cause for alarm.
To understand what is happening here, you need to know how High Sierra manages encrypted volumes and their access. When you create an APFS volume (encrypted or not), macOS associates it with a list of users, each of whom is known by a GeneratedUID, not a UUID. Although ‘real’ users have GeneratedUIDs which appear similar to real UUIDs and are effectively unique, users added by macOS like the Apple Events User and Guest are assigned standard ones which start with the sequence
FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000
Guest user accounts are normally assigned a GeneratedUID of
FFFFEEEE-DDDD-CCCC-BBBB-AAAA000000C9
If you want to look these up, open Directory Utility (in /System/Library/CoreServices/Applications), select the Directory Editor, and view Users.
If you are already logged on as a user, when you connect an encrypted external volume, macOS checks that you are in the list of users for that volume and invites you to unlock it. If the volume is bootable, macOS may offer you a list of known users, according to GeneratedUIDs. With a guest user enabled, that list may well contain that guest user.
This may be confounded by what some of us have considered bad practice in macOS: when you first configure macOS on a brand new Mac, or install it onto a freshly erased volume, the Guest user is usually but not always enabled by default. Disabling that Guest user is one of the first things that I do whenever I get a new Mac, and it worries me that many users don’t know that they should do that. Apple should set the default as the Guest user disabled, for its improved security.
When macOS is configured with the Guest user enabled (often by default), the Guest user account will be created, and assigned its special GeneratedUID. Even though you may then disable guest access, Guest User may be left in its list of users. So it may be carried over into the list of users for an encrypted volume long after the account was disabled.
This doesn’t mean that a guest user, active or ghost, can unlock an encrypted volume, though. When macOS High Sierra starts up from an encrypted startup volume, it can’t do so from the encrypted volume, so starts up from the Recovery volume instead, launching the unlock dialog. If a guest user tries to unlock the encrypted volume to continue starting up from it, macOS will deny them access, leaving them with just the Recovery volume to play with, and the real startup volume will remain encrypted and unmounted as a result. High Sierra has a Secure Token system to ensure that a guest can’t go any further.
If you use APFS encryption, you can view the list of known users by entering the Terminal command
sudo fdesetup list
and authenticating. You’ll see a list like
hoakley,XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
where the latter entry is that user’s GeneratedUID. If that list includes any Guest account, it should appear as
guest,FFFFEEEE-DDDD-CCCC-BBBB-AAAA000000C9
If it bothers you, you can remove the Guest account using
sudo fdesetup remove -user guest
or by GeneratedUID as
sudo fdesetup remove -uuid FFFFEEEE-DDDD-CCCC-BBBB-AAAA000000C9
although you should be able to rely on the Secure Token system to ensure that your guests don’t get out of control.
You may also be able to list users with a command like
diskutil apfs listcryptousers /dev/disk1s4
where disk1s4 is the encrypted volume. However, in my case all I was able to elicit from that was a list of encrypted volumes with their UUIDs, such as
Cryptographic user for disk1s4 (1 found)
|
+-- XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Type: Disk User
Hint: C
where XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the UUID of the encrypted volume, not its user(s).
To learn more about fdesetup, study Rich Trouton’s superb presentation about it. Although I have looked for documentation from Apple about these issues, you may be unsurprised to learn that my search drew a complete blank.
I am very grateful to Sebastian for asking me what turned out to be such a fascinating question, for providing all the clues needed to work out what was going on, and for letting me use his screenshot.
