Adding password protection to manually installed management profiles

While working with some colleagues, I recently built a management profile that my one colleague requested to be set as non-removable. Normally, this can be accomplished by setting the PayloadRemovalDisallowed key in the profile to a boolean value of true.

I provided the profile to my colleague and he tested it out. However, in the course of testing, he discovered that the profile could be removed by a user with administrative rights using the following procedure:

1. Open System Preferences
2. Select the profile in question.
3. Click the minus button.

4. Be warned about removing a locked profile.

5. Enter admin credentials when prompted.

After entering admin credentials, the profile was then removed.

When I checked Apple’s reference documentation on configuration profiles, the issue came down to how the profile was being delivered. Apple’s documentation includes the following note about the PayloadRemovalDisallowed key:

	Note: OSX versions 10.10 and later honor a true value of the PayloadRemovalDisallowed key
	to prevent manual removal of profiles installed through an MDM server. Such profiles cannot
	be removed using the Profiles preference pane, nor the profiles command line tool even when
	run as root. Only the MDM server can remove such profiles. Profiles installed manually, with
	PayloadRemovalDisallowed set to true, can be removed manually, but only by using administrative authority.

view raw

gistfile1.txt

hosted with ❤ by GitHub

This profile was being installed by an installer package, so from Apple’s point of view it was being installed manually. That meant that the manual installation behavior, where the profile could be removed by anyone with admin rights, was the applicable behavior here.

Another colleague working with us on this issue suggested adding a removal password to the profile, using Apple’s com.apple.profileRemovalPassword profile payload.

A removal password for a profile is designed to allow the removal of a management profile, even if that profile is otherwise set to be non-removable. For more details, see below the jump:

Kernel extensions and macOS High Sierra

As part of the pre-release announcements about macOS High Sierra, Apple released the following KBase article:

• Prepare your institution for iOS 11, macOS High Sierra, or macOS Server 5.4: https://support.apple.com/HT207828

As part of the KBase article, Apple included a Changes coming with macOS High Sierra section which featured this note:

macOS High Sierra introduces a new feature that requires user approval before loading new third-party kernel extensions. This feature will require changes to some apps and installers in order to preserve the desired user experience.

That section in turn links to this KBase article, which describes the behavior in more detail:

• Prepare for changes to kernel extensions in macOS High Sierra: https://support.apple.com/kb/HT208019

To improve security on the Mac, kernel extensions installed with or after the installation of macOS High Sierra require user consent in order to load. This is known as User Approved Kernel Extension Loading. Any user can approve a kernel extension, even if they don’t have administrator privileges.

What’s all this mean? For more details, see below the jump.