Profiles have become one of the most interesting components of the Apple ecosystem – both on OS X and on iOS. With their ability to easily control the functionality of the operating system, install certificates, and manage application preferences, along with their flexibility to use the same profile on desktop and mobile, many organizations have embraced them.
While I have never been a huge fan of restricting components of OS X, some elements do need to be locked down in certain environments. Earlier this year, I wrote an article about how to tweak the System Preferences profiles generated by Profile Manager 2 to allow third-party prefpanes to be used, as the way Profile Manager 1 and 2 handled this was by generating a whitelist of permitted prefpanes. As Profile Manager did not know about third party prefpanes, they had to be manually added later by editing the mobileconfig file’s XML.
Evaluating the new capabilities of Profile Manager 3, I was pleasantly surprised to find that Apple had added an additional option to the Preferences tab under Restrictions for OS X, allowing an administrator to choose between either a whitelist, using “enable selected items”, or a blacklist, using “disable selected items.” Additionally, Profile Manager now detects third-party preference panes which are installed globally on the server, so they can be included without manually editing the file.
To test, I generated a profile to restrict access to two panes, Profiles and Sharing, shown below.
I installed the profile locally, and the results went as expected. Once I reopened System Preferences, the two panes were grayed out in both the grid of icons and under the the View menu.
If I were to use these kinds of restrictions in production, I would not want the icons to be grayed out in the grid, but to instead be hidden from view in the grid. To my surprise, this caused me to discover a vulnerability which allows users to easily access restricted preference panes.
To access a preference pane which is currently restricted, the process is simple:
1. Under the View menu, click “Customize.”
2. Uncheck the boxes for any disabled preference pane, hiding it from view.
This works on all versions of OS X which support profiles, from Lion up through the latest build of Mavericks. Of course, the new preference pane blacklist does not work on versions of OS X prior to Mavericks, but using the whitelist the same can be achieved.
The significance of this vulnerability depends upon the extent of use of these restrictions in your organization. If you use it to restrict access to preferences which require administrator access to change, it may just be a minor problem. However, if these restrictions are used to disable use of iCloud and other Internet accounts, or to keep the user from changing the password timeout, this can be a serious issue. Effectively, any restriction in System Preferences is useless and easily subverted.
After confirming the issue and gathering some additional information, I reported the issue to Apple’s Product Security team. I received a quick response, but sadly I was told that they did not see this issue as a security issue, as security profiles are only meant to be a means to guide policy, and not to actually enforce it.
As I showed this to a few members of the Mac admin community, they all saw it as a security vulnerability, and it clearly is one, not just a bug. I have found one workaround, which is to install a second profile which enforces the HiddenPreferencePanes key in the com.apple.systempreferences domain. Users will still be able to uncheck the boxes to hide preference panes, but this will not actually do anything. I generated this profile using mcxToProfile:
Unfortunately, since this profile ensures that all preference panes are always visible, it means that my original issue of wanting to hide the greyed-out icons still exists.
I hope Apple fixes this not just in Mavericks, but in Lion and Mountain Lion as well. There are workarounds for most restrictions imposed on computers, but none should be this easy to overcome. The issue remains unpatched in 10.9.1.