Does not work on MacOS Monterey 12.0.1

[spassigl]

I tried on iMac M1 with OSX Monterey 12.0.1 and the tool does not seem to work as expected. I have a user home on an external, APFS encrypted SSD. Hence I wanted to use this tool to get the disk unlocked at boot time and before login. But after installation I tried to login with that user and it did not work. So I logged back in with an administrator account and immediately after login I get a prompt asking me to authorize MacOS to use the system keychain. After I enter a username/password I get the drive unlocked. So it seems Monterey has enforced and limited the access to the system keyring at boot time for APFS volumes.

Contents of /var/log/BootUnlock.log

=== Mon Dec 13 18:50:32 CET 2021 === ===[ update.sh: Mon Dec 13 18:50:32 CET 2021 ]=== Verifying the specific cryptographic user A16FAAD5-1466-402D-A95E-79BAB41C6BE5 on APFS Volume disk8s1 Passphrase valid Adding password for volume "Dati Mac" with UUID A16FAAD5-1466-402D-A95E-79BAB41C6BE5 to the System keychain... === Mon Dec 13 18:52:40 CET 2021 === Trying to unlock volume "Dati Mac" with UUID A16FAAD5-1466-402D-A95E-79BAB41C6BE5 ... NOTICE: could not find the secret on the System keychain, skipping the volume.

[galaxy4public]

@spassigl , thanks for the report. I will look into this and will try to come up with the troubleshooting steps. I also wanted to point out that I am successfully using BootUnlock on Monterey 12.1 (which is the beta stream version). I guess I need to install the release version and see whether I can confirm the issue.

[galaxy4public]

My preliminary assessment of the log entries suggests that the tool failed to update the system keychain in the first place. I will update the installation script to make it crystal clear whether the update was successful or not. If you login as administrator and look at the system keychain, do you see a password entry for the volume you are trying to unlock?

[spassigl]

Yes it's there under the System keychain. The UUID seems correct and the BootUnlock is in the authorized application list. I decided to clean up everything - removed BootUnlock entirely, removed the password entry in the system keychain, removed the encryption, rebooted to a clean state. Then I encrypted again the external APFS volume. I installed again BootUnlock, selected the volume to start at boot, entered the passphrase and all seemed OK. Rebooted, tried to login with the user whose home is on the encrypted disk, no luck. I then logged in with an adminstrator account and as soon as I logged in I had a message prompt that I had to enter username and password to modify the system keychain. The disk was not mounted yet. I entered username and password of the administrator account and the disk was then mounted. Rebooted and tried to login with the other user, no luck. Logged in with the administrator account and the disk was mounted, this time without any password request. But a thing I noticed is that the disk appeared in the Finder a couple of seconds after login - as it was mounted immediately after login not at boot time. But this may only be my interpretation not what necessarily happened.

Here's a section of the log from the reinstall and the first attempt to login

===[ update.sh: Tue Dec 14 18:17:25 CET 2021 ]=== Verifying the specific cryptographic user 6548C5F8-E31D-4ED9-92E2-A539EA23B5D2 on APFS Volume disk8s1 Passphrase valid Adding password for volume "Dati Mac" with UUID 6548C5F8-E31D-4ED9-92E2-A539EA23B5D2 to the System keychain... === Tue Dec 14 18:19:02 CET 2021 === === Tue Dec 14 18:19:46 CET 2021 === Trying to unlock volume "Dati Mac" with UUID 6548C5F8-E31D-4ED9-92E2-A539EA23B5D2 ... NOTICE: could not find the secret on the System keychain, skipping the volume.

Hope this helps troubleshooting.

[spassigl]

Update. I upgraded Monterey to the official 12.1 and still does not work - i.e. the disk is not mounted at boot and I can't login with the account that has its home on the APFS crypted disk.

BUT - there's a big difference. Now I am asked a password to access the system keychain after every login, EVEN when logging in with the administrator account. Only after I enter username and password the disk is mounted.

There seems to be a different security mechanism that prevents an app to access the system keychain before login.

Since you are using 12.1 too and it's working for you - I wonder if the different behaviour is due to my iMac being brand new and freshly installed? Maybe I need to configure something else?

[galaxy4public]

OK, this is weird, indeed. Are you by a chance running an ARM version of macOS? I.e. are you on one of these new M1 based Macs? I am asking since all testing I've done so far is on x86 macOS.

[spassigl]

Yes it's an M1 iMac. Another thing I noticed which is weird. If I log in with the administrative user, log off and try to login with the non admin user with its home on the encrypted disk, the login process fails. I remember I could do that in the past, unlock a volume for another user.

But it indeed seems linked to the system keyring not being accessible at boot time. Maybe it needs to be unlocked first before calling find-generic-password?

I'm happy to help troubleshoot the issue anyway.

[spassigl]

I did a bit of troubòleshooting and I think the issue might be related to the -w flag used to extract the passphrase

Trying this from the admin user

$ sudo security find-generic-password -D 'Encrypted Volume Password' -a "my UUID" -s "my UUID" -w

I get a dialog box asking username and password to access the system keychain.

Now, if I ssh into the iMac and issue the command with -w this is what I get:

% sudo security find-generic-password -D 'Encrypted Volume Password' -a "my UUID" -s "my UUID" -w %

i.e. security(1) silently fails printing no data. I guess it's because it's expecting an interactive authentication.

BUT - in case of an error like when passing a wrong UUID:

% sudo security find-generic-password -D 'Encrypted Volume Password' -a "blah" -s "blah" -w security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.

To verify my assumptions I modified helper.sh this way

13 printf 'Trying to unlock volume "%s" with UUID %s ...\n' "$N AME" "$UUID" 14 PASSPHRASE=$(${0%/*}/BootUnlock find-generic-password \ 15 -D 'Encrypted Volume Password' \ 16 -a "$UUID" -s "$UUID" -w) 17 printf 'pass was: "%s"' "$PASSPHRASE" >&2 18 if ! "$PASSPHRASE" ; then 19 echo 'NOTICE: could not find the secret on the System keychain, skipping the volume.' >&2 20 continue

With this the log does not show the printf in line 17, it seems security(1) fails entirely causing helper.sh to exit If I remove the -w flag, I get the output of the security(1) tool in the log. But oviously the value of PASSPHRASE is not what we want as it's the entire find-generic-password output.

That's all I could do so far, I'm not an expert in OSX security so I need to figure out if there's any way to make the -w flag work without a graphical interactive authentication - if that's the only way I can say it's really a poor design by Apple.

[galaxy4public]

This is expected (not reaching line 17) since security fails to find the password for the specified UUID in the keychain and returns a non zero exit code. The script has set -e, which means fails on errors. You correctly identified the culprit: it is security does not seem to be able to find the record in the keychain for the specified UUID on M1, but I am wondering why.

What you can do to help troubleshooting, is to add lines like:

${0%/*}/BootUnlock list-keychains -d system || :
${0%/*}/BootUnlock default-keychain -d system || :

You can add them before line 13 in your script. Please note that || : is there to ensure that even if the command returns an error the execution continues.

The first command should list the path to your System keychain and the second should print the same info. I guess, on your system the second command may print out that the default keychain is not set. If it is not set, then you have your solution by setting the default system keychain to the path you've got from the first command.

[galaxy4public]

@spassigl, it would help if you could assist me according to my latest comment. I suspect that finding output to those two commands may shred some light on the issue you are having and we would be able to fix the issue for M1 users.

[galaxy4public]

I am closing the issue since there was just a single report and @spassigl seems to be no longer interested in pursuing the resolution of the issue.