El Cap preference pane question

[roiegat]

I'm working on an updgrade path to El Captian and noticed something fun. I discovered the lovely world of SIP. So in 10.10 we moved several preference panes to a hidden location to stop users from using them. But in 10.11 we can't move preference panes due to SIP. So my question is: Is it possible for a non-admin user to re-enable those panesl in any way? Racking my brain to think like a crazy user to figure out if they can do it. Though maybe possibly creating their own preferences in ~librarypreferences...but not sure if that would work.

Would an admin user be able to do it? IS there a way to ensure a machine only enables what it's allowed to have enabled even when and admin user is using it?

[Josh_Smith]

I can't answer your question about moving preference panes, but I restrict access to a preference pane using a configuration profile and that seems to work well.

{DisabledPreferencePanes=[com.apple.preferences.TimeMachine, com.apple.prefs.backup], HiddenPreferencePanes=[com.apple.preferences.TimeMachine, com.apple.prefs.backup]}

[Nix4Life]

@roiegat you should take a look at Profiles. I used to do the same as you ( it was just a rename, not as involved as your solution), but started using Profiles, since that is the future. AFAIK the only way for the settings to not apply to a user is thru Scope >"exclusions" at the JSS settings level.
hth
Larry

[roiegat]

We use profiles for a couple things. I just need ot make sure the users can't disable them. We have some users with admin access and I need to make sure they don't delete the profiles. So might have to create an offiline policy to check onon it at all times.

[mm2270 · Accepted solution]

IS there a way to ensure a machine only enables what it's allowed to have enabled even when and admin user is using it?

Short answer: No
As has been said a number of times before, once users are admins, its not possible to secure everything 100%. You can get pretty far along, or make it so difficult for them to bypass the controls that they deem it not worth the effort, but in short, you can't really stop them from figuring out some way around controls.

Here's my advice, as someone who also needs to ensure that a base of admin users numbering close to 10,000 aren't able to get around certain controls. (some we care about and others we don't really worry about)

1. Enable a Firmware Password that you do not give out to users.
   Upside: Stops them from booting into Recovery HD to change settings, reset passwords and other stuff
   Downside: Stops them from doing self triage repairs like Disk repairs from Recovery mode. (Also blocks all other alternate boot modes, like Safe mode, SUM and the rest) Repair permissions isn't as important under 10.11, so that kind of goes away at least.

2. Enable a Configuration Profile that locks down System Preferences you don't want them to have access to.
   a. Put a password on it to prevent removal so they can't blow it away in Terminal with profiles. b. Along with that must ride a profile that enables and enforces a blank "HiddenPreferencePanes" array. This is important because it prevents them from enabling a long time hack that gets them access to those greyed out pref panes with a few clicks.
   c. Make sure one of the panes you gray out is Profiles ;)
   d. One last thing: be sure you have a valid reason for locking down a Pref Pane, and not just because you feel like IT overlord today. Its easier to explain and get buy-in on why they don't have access to something when you can point to concrete security reasons for it.
   Upside: While you can't move the panes out of the default locations now (which was never a good idea anyway), it at least prevents casual and even more advanced user access
   Downside: Profiles are generally equal opportunity and will block you from accessing those same preference panes when on any of the systems. You can try using some scoping to help make sure it only gets applied to some systems and not others, but in general, to be truly secure, you probably should just push it to all your systems, even IT ones.

3. Create/Enable as many EAs you can think of to check on all kinds of values from the system.
   a. There are some in the JSS EA templates that may be helpful, though a number of them are broken in their current incarnation and will need to be reworked a bit.
   b. If necessary, scope policies to Smart Groups that find machines out of compliance to push the settings back down with an ongoing policy. They'll be playing whack-a-mole trying to stop restrictions from being sent down, and in many cases, will eventually give up trying.

Those are a couple of the things we're doing, though there's certainly a lot more you can do. Does this stop the most persistent of users from circumventing things? No, not really, but it makes them spend an inordinate amount of time trying to get around stuff. As per usual, HR/company wide policies should always be there too - AUPs or other things the users sign and agree to, to put them on the spot when its discovered that they are getting around stuff. In essence, if there isn't something spelling out what is unacceptable for them to do, they can always play dumb and say they didn't know.

Outside all of this, there is the concept of trusting your client base to do the right thing and use the computers responsibly. You'd be surprised at how often this will end up being the case. You'll always have those bad apples who believe its "their" computer and they should be allowed to do whatever they want with it, security and protecting intellectual property be damned. No real getting away from those types. I know this model just doesn't work everywhere, but sometimes it ends up being a compromise between locking down too much and easing up some things that aren't really all that important to give them a little more sense of freedom and respect. Sometimes its not worth getting into a endless struggle with your users.

[roiegat]

@mm2270 Great advice! How do you put a password on a profile to stop it from being removed? I though anyone with admin right could just remove it.

[obi-k]

I created password protected profiles using Apple Server Profile Manager then exported it. Not sure if the later Casper 9 versions do that.

Forgot to mention: You can create a separate password for that profile (different than admin one).

[mm2270]

Sorry @roiegat, I meant to follow up on this yesterday. As @mvu mentions, you would probably need to create the profile outside of the JSS since I don't think the ability to add a password to a profile is something the JSS offers yet. We're only on 9.82 here, not 9.9x, but I don't recall seeing anything in the latest release notes that this is possible yet.
Once you do that, I think you should be able to import the profile into Casper and retain that setting. However, I seem to recall seeing somewhere a trick to make sure Casper doesn't mangle your profile, but I need to locate it again. In some cases it may strip out items it doesn't understand, but there is some way to prevent that from happening. Anyone recall what that trick is? Is it to sign the profile?

[gachowski]

We are doing the same thing as Michael....( MVU)

The one thing I didn't try is signing the profile in configurator before uploading it .. then the JSS can't/won't change the setting.

C

PS we just set it to never : )

[djdavetrouble]

Hi Josh,
I saw this, and am wondering why you need both com.apple.preferences.TimeMachine, com.apple.prefs.backup to hide one preference pane. What does the second one link to?
Thanks!

[roiegat]

Yep I created it using Apple Server Profile Manager so I could protect the removal of it with another password. Tested it out and it worked great. Still working to make sure nothing else is breaking during the upgrade...but we'll see.

Thanks guys.

[Josh_Smith]

@djdavetrouble Great question....unfortunately I don't remember and I don't have a good way to test it right now, I recently switched jobs.