Addendum to The Demise of Firmware Passwords on M1 Macs

Shortly after posting The Demise of Firmware Passwords on M1 Macs, which I at least in part agreed with Apple’s assessment of FileVault being an equivalent level of security (so long as your users aren’t admins), someone commented on the fact that hidden in the menubar of the Recovery Assistant is an Erase Mac option!

From there, all it takes is a couple of extra clicks to begin erasing the entire system, including the main OS.

From an admin standpoint, this is very very bad… While your M1 Mac data may not be at risk of being exfiltrated or recovered, this means that Mac admins unequivocally do not have any greater control over the Mac hardware we purchase, deploy, and manage as anyone (literally anyone) who happens to be in physical possession of the hardware.

The Demise of Firmware Passwords on M1 Macs

Last week, Mr. Macintosh gave a great presentation on the changes introduced with macOS Big Sur on M1 Macs for reinstalling macOS. Click here for the recorded presentation and here for the presentation slides. Having recently begun testing an M1 MacBook Air myself, I was very interested in getting a jump start on this.

There were a number of important takeaways from the presentation, but one in particular I learned was that M1 Macs no longer support the firmware password feature. Sure enough, reviewing Apple’s own support article on firmware passwords:

Having previously worked at a school, setting a firmware password was a critical security feature as it prevented anyone without this password from booting to anything other than the configured default boot volume. This ensured more tech-savvy users could not load their own bootable macOS from the organization’s hardware or boot to the recovery OS and potentially wipe the device entirely.

While Apple indicates in their support article that FileVault achieves the equivalent level of security, the question is even with FileVault enabled does this open up the ability for users to do mischief?


  • On Intel Macs, the only security mechanism that prevents an admin user from booting to a different OS or the recovery OS is a configured firmware password.
  • In Big Sur, external booting of validly signed macOS installers and macOS boot volumes is now permitted by default.
  • Given M1 Macs do not have a firmware password option, any user with valid admin credentials can load macOS installers, other bootable macOS volumes, as well as fully erase and reinstall macOS.
  • So long as your users are not admins, Apple’s claim of FileVault being an equivalent level of security is valid… but only in this context.

For more info, see past the jump.

Read More

Running Jamf Scripts with Custom Command Line Arguments at Runtime (Without Jamf Remote)

In a previous role, I had created custom scripts with Parameter values to be used in Jamf Remote by my IT support colleagues. This provided a simple interface for common support tasks while also being able to supply custom values to scripts without having to copy & paste complex command line arguments.

In the case where a Mac had an incorrect hostname, a support technician would simply launch & authenticate into the Jamf Remote app, select the appropriate device and script, enter the desired hostname in the appropriate Parameter value field, and click Go!

This was made possible by the fact that:

  1. All our Macs were on-premise or remotely connected via VPN.
  2. Our Jamf Pro Server was also on-premise.

In a Jamf Cloud & work from home environment, this simply isn’t possible in the same way even if you are able to remotely connect to your Macs. That said, there are still plenty of use cases where this functionality is useful. This is limited by the fact that scripts attached to policies can have custom variables assigned at the policy level but not at runtime. To accomplish the same hostname functionality would require the support technician to have access and comfort to edit a policy, change a Parameter value associated with it, and trigger the policy from the user’s Mac via sudo jamf policy -event <custom value>. Depending on the level of your support team, this may simply not be an option.

As of Jamf Pro Server version 10.28.0, the previously available jamf runScript for local scripts is being deprecated and while this did not achieve the same functionality of running scripts within Jamf it renewed my interest in finding a replacement.

Thankfully, a fellow Jamf user commented on a related feature request with a solution. With a simple bash script function added to your script tied to a policy, you can call Jamf policies on the command line and supply custom variables at runtime!

The function parses the Jamf policy command based on its process ID and then parses the parameter values to be used as part of the script.

To utilize this bash function, you’ll need to complete the following:

  1. Copy & paste the checkCustomParamaters function to your desired script(s) and call the function.
  2. In your script where you normally use $4$9, instead assign the appropriate $pXValue where X is the parameter value.
  3. Assign your script to a policy and make it available on an Ongoing basis with a custom trigger.

Now you can call your policy with your selected custom variables! The added benefit of this method is that you have more than just the normal parameter 4 – 9 values available in Jamf scripts.

sudo jamf policy -event <custom trigger name> -p1 <p1 value> -p2 <p2 value> ...

Now, we can accomplish the task of remotely changing a Mac’s hostname:

sudo jamf policy -event sethostname -p1 "new_hostname"
Checking for policies triggered by "sethostname" for user "testuser"...
Executing Policy Change Mac Hostname
Running script SetHostname...
Script exit code: 0
Script result: P1 value is new_hostname
Successfully changed hostname to new_hostname!

Running Recon...