Bug? Able to access prohibited prefpanes.

Thank you for clearing that up. I went ahead and removed the steps to reproduce.

Thanks for removing the steps! Always good to look out for our fellow Mac admins. :)

While I think we all acknowledge that when someone has admin rights, all bets are off anyway, the kicker on this one is it doesn't require the user to be an admin. I wish Apple would address this, but they don't really see this as a security issue, which I find rather... puzzling.

We've addressed this issue with a permissions based workaround.

We block the Security & Privacy prefpane on MacBooks so that users can't turn off FileVault encryption. We do this by moving the security.prefpane from /System/Library/PreferencePanes/ to the ~/Library/PreferencePanes/ directory of our admin(management) account. Then we put a sylink in /System/Library/PreferencePanes/ to the security.prefpane file in the admin account. Since no other accounts have permission to the security.prefpane in the Admin account, the preference pane just doesn't show up for any other users.

There are, however, two downsides to this method:
1) Combo updates or OS re-installs 'fix' it, because combo updates fix permissions, and OS re-installs replace the original security.prefpane file.
2) The *.prefpane is specific to each OS version - so if you wrap the *.prefpane up in a package for deployment, you have to build one for each OS version in your environment

To address those downsides we have policies for each OS version that run once a week on all MacBooks to re-apply this config to make sure those users can't disable FileVault. Desktop Macs don't get these policies because we don't enforce encryption on them.

It's certainly more complicated then a configuration profile - but it's a set-it-and-forget-it situation with all the work on the front end, and then no additional maintenance unless a new OS version is introduced to our environment.

I've read (not tried) that another workaround to this is to deploy a separate MCX or Configuration Profile setting that controls the HiddenPreferencePanes array that gets created when a user sets one in the System Preferences dialog. If you deploy a blank array setting that's System Level Enforced, in theory it should mean that their settings should be overridden with the enforced one and not make any panes hidden, avoiding the issue.

Again, I haven't tested that, but it may be a more sane workaround than moving Preference Panes around and/or changing permissions.
Kind of silly that we should need to do any of this actually. Apple should just address the bug.

Jason, that does sound like a complicated workaround, but may be something that I look into in the not-too-distant future. Thank you for writing out your process!

Mike, I haven't had much luck deploying a managed preference setting that has the HiddenPreferencePanes array in it. On first deployment the prefpanes hide properly, but if the end user makes any customizations to which prefpanes show then the customization appears to take precedence over the mcx that was applied. It doesn't appear to re-apply from what I've seen and on top of that, when it was initially deployed successfully, that's when I noticed the first problem I wrote about. I absolutely agree that it is silly that we have such elaborate workarounds for a bug Apple has yet to fix.

Just wanted to post back, just for the heck of it I decided to give the above possible workaround a try and it works!

Create an MCX setting with the following settings (or a Config Profile with similar if you prefer)

Domain: com.apple.systempreferences Key Name: HiddenPreferencePanes Key Type: Enter manually (Array or Dictionary) Apply Setting to: User Level Enforced

Value:

<array>
<string></string>
</array>

Once this gets applied whet happens is, any previously Hidden Pref Panes become unhidden. If you try to hide them, the UI seems to let you, but since they will only show up in the menu after quitting/relaunching System Preferences, the setting never gets applied and they show up again as unhidden after relaunching the app, and therefore unavailable from the menu.

Not saying this is a perfect workaround. The previously mentioned 'admin user so all bets are off' still applies here, but its a good compromise to make it a bit harder to do, especially if users don't have admin rights on a box.

Edit: I should note that I've applied and tried this on Mountain Lion, but not yet on Mavericks. Hopefully it works there as well, and on older versions of OS X, though I'm not quite as concerned about anything before 10.8 myself.

Hi Mike (mm2270), are you able to send me the screenshots to your mcx setup, happy for you to email them to me on pnbahry@riverview.nsw.edu.au. I must be doing something wrong at my end as System Preferences Crashes each time.

@pnbahry, sure, i can just post them here actually as there's nothing proprietary or security related in them.
Keep in mind these are from Casper Suite 8.73, not 9, so the view will look different if you're on vera 9.

Here are 2 screenshots:
external image link

external image link

I'm not sure if manual arrays like what you see here are something that actually works under 9 though. I'm slightly unclear about that. but have seen some indication on other threads that these are no longer supported types. Not sure if that's related to what you're experiencing.

@mm2270][/url I think thats where my problem is then I am on casper 9 thats why.. Thanks for the screenshots I might keep trying a few other settings see if I can get it working in Casper 9.

Casper 9 does not have Array MCX support !!

Thats why i was not able to get it to work..