1

I cannot get Monterey to decrypt volumes at boot on my M1 MacBook Pro. I have this working on another Mac running Catalina where I'm using BootUnlock. I initially installed it directly from the download but that was the x86 version, so I rebuilt it, cleaned down the remnants of the x86 version and re-installed the dual-architecture version:

root@samhain ~ # file /Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/*
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock:   Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock (for architecture x86_64):     Mach-O 64-bit executable x86_64
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock (for architecture arm64e):     Mach-O 64-bit executable arm64e
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/diskutil.xsl: ASCII text
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/helper.sh:    Bourne-Again shell script text executable, ASCII text
/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/update.sh:    Bourne-Again shell script text executable, ASCII text
root@samhain ~ #

It had set the access to the volumes correctly:

enter image description here

However when I rebooted it and logged in it was asking for permission to access the Keychain:

enter image description here

Any ideas to get BootUnlock working or suggestions of an alternative tool or method?

Update 1

I set up a Monterey VM on my Mac Pro (2019, x86) and installed BootUnlock—and it works. On the face of it this is an M1 problem. The log (/var/log/BootUnlock.log) on the MacBook Pro M1 has entries like this:

Trying to unlock volume "sTimeMachine" with UUID ED793E20-4F9D-4A8E-9185-B2735A1164B0 ...
NOTICE: could not find the secret on the System keychain, skipping the volume.

Update 2

It's very simple really, the binary is being killed:

root@samhain ~ # /Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock
zsh: killed     /Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock
root@samhain ~ #

This happens when you attempt to run the wrong architecture but as shown above BootUnlock has both architectures.

Improve this question
13
  • Honestly, I'm struggling to find the use-case for this tool. You want the drives to unlock automatically at boot, without providing credentials? Why not just unencrypt them. Same end result.
    – Tetsujin
    Commented Dec 4, 2021 at 13:26
  • 1
    Because if they weren't encrypted then they'd free to be read by everyone. And don't forget you can't securely erase SSDs, so you shouldn't leave anything unencrypted on them.
    – Philip Kearns
    Commented Dec 4, 2021 at 14:17
  • If they're unlocked without user intervention at boot, then the only gain is once the drives are discarded. Anyone with access to the computer has access to the data on the drives with an auto-unlock.
    – Tetsujin
    Commented Dec 4, 2021 at 15:30
  • How is this different than just applying FileVault to them?
    – Marc Wilson
    Commented Dec 4, 2021 at 18:25
  • @MarcWilson: Two aspects: it's good practice to have separate volumes with quotas for non-OS data such as user data; I want a Time Machine within my MacBook and the only way to do that is with a separate volume (in a separate partition actually) which needs to be encrypted and I want it mounted at boot.
    – Philip Kearns
    Commented Dec 4, 2021 at 19:29

3 Answers 3

Reset to default
2

Apple Silicon Macs require that all executables are signed. When you run an unsigned executable, it is not allowed to run - and it will show up in the shell as "killed".

As you compiled the tool yourself, you have probably left out codesigning. You can do that after compiling by running this command in the Terminal:

codesign -s - /Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock

The "-" means that it will perform an ad-hoc signing. The resulting signature does not use a specific identity and the program will only be able to run on your own local machine. If you have either a developer subscription with Apple, or you have created a free certificate with your Apple ID, you can use that for signing instead.

UPDATE:

I have found the source repository for the program in question, and can see that the BootUnlock is not a new, unique binary - but rather just a copy of the built-in /usr/bin/security program. As that program is known to work and is codesigned appropriately, it would be a good idea to change the script to simply call /usr/bin/security instead of BootUnlock.

Improve this answer
19
  • Thanks for the suggestion, but it didn't work. I tried codesign -s -; it said it was already signed. I tried codesign -f -s -; it replaced the signature. But it's still killing it. In his build directory for BootUnlock he includes a build script which does pkgbuild and productbuild - maybe they sign it. I can paste the build script into my question above if it would help.
    – Philip Kearns
    Commented Dec 7, 2021 at 11:16
  • Does that program have dependencies? (i.e. does it load in for example a shared library or framework?) - If so, those need to be codesigned as well. Try "codesign -vv /Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/BootUnlock" to show information about signing status.
    – jksoegaard
    Commented Dec 7, 2021 at 13:46
  • This is really strange: it outputs two lines, BootUnlock: valid on disk and BootUnlock: satisfies its Designated Requirement. That suggests its cert is not the reason it's being killed.
    – Philip Kearns
    Commented Dec 7, 2021 at 14:10
  • Does it have dependencies? Have you checked those?
    – jksoegaard
    Commented Dec 7, 2021 at 15:11
  • I misunderstood, I thought the -vv would check that. The binary is very simple (it's only 645k) and the process mainly uses scripts to carry out its tasks; those I understand very well. In Solaris and Linux you can use ldd to show the libraries a binary depends on - is there a similar command in macOS/Darwin?
    – Philip Kearns
    Commented Dec 7, 2021 at 15:53
0

This is not an answer per se, it's just a rather ugly workaround. If I get a fix I will post it. With the help and insight of @jksoegaard I figured out the best workaround for the BootUnlock problem.

  1. Download BootUnlock from its site
  2. Install the package as normal
  3. There's a bug in the install that if you select the wrong volume you can't cancel it (I must try fixing that bug), so make sure you select the correct ones. It will ask you for the passwords of each Volume.

Once it's installed as root you will need to edit:

/Library/PrivilegedHelperTools/au.com.openwall.BootUnlock/helper.sh

Replace ${0%/*}/BootUnlock with /usr/bin/security

Open Keychain, select System on the lefthand side, and find the entries for your disks. For each disk open its entry, for example:

enter image description here

Select 'Access Control' (you will be asked for your password) and you will see BootUnlock there already. Press '+' to add another application. Navagate to the root of the boot disk, press Shift-Command-. to see all the files. Navigate to /usr/bin/security and add it:

enter image description here

Press 'Save Changes' (you will be asked again for your password).

Reboot and check that the disks are indeed unlocked and mounted.

Improve this answer
2
  • I am not sure that I understood what bug you are referring to (could you please raise an issue on GitHub, if there is still an issue?). As re: granting /usr/bin/security this permission -- it should be noted that this makes it possible to unlock the drive to anyone who is authenticated to the system. Avoiding this permission to security was one of the goals of the BootUnlock wrapper.
    – galaxy
    Commented Aug 26, 2023 at 9:58
  • I wrote that 18 months ago so having difficulty visualising the bug, but if I see it again I'll use GitHub to report it. You are right in all you say about giving /usr/bin/security such permissions.
    – Philip Kearns
    Commented Aug 28, 2023 at 13:52
0

The difficulty was that on Apple silicone the binaries are built for an architecture only Apple can sign binaries for. The BootUnlock has been updated to work on Apple silicone with the latest release (by leveraging Rosetta for /usr/bin/security and signing the x86_64 part of the binary only).

The reason BootUnlock is using a copy of the /usr/bin/security is to follow the least privilege principle -- we want to have the disk password available only to BootUnlock and not to every user on the system who has access to /usr/bin/security.

Improve this answer
1
  • 1
    I had guessed that was the reason for writing the wrapper. Thanks updating BootUnlock, I'll try it out when I get a chance.
    – Philip Kearns
    Commented Aug 3, 2023 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .