Systems Preferences Restrictions ByPass

[stevehillnz]

Students are beating restrictions on System Preferences that have been imposed by Configuration Profiles.

Essentially, they put a copy of System Preferences into any location (sometimes hidden) in their home folders. They will usually rename the app. After Showing Package Contents, they delete /Contents/Resources/NSPrefPaneGroups.xml.

This copy of System Preferences has no icons visible, but going to the View menu shows that they are all there, with no restrictions.

We are struggling to find a solution for this. We tried creating a query for any user folder containing a file with the extension .app, but that returned just about every computer.

The challenges are:
1) The Unrestricted System Preferences app is in a random folder on each machine.
2) The app could have anything as its name.
3) Even if we could find it and delete it, the student could easily repeat the process.

I don't want to completely block System Preferences, but this seems like the only option at this point.

[calumhunter]

what preference panes are they getting access to that you don't wish them to have access to? I'm guessing there are some things you do want them to have access to which is why you are not blocking the system pref app flat out.

So then how about setting the permissions on those particular .prefpanes in /System/Library/PreferencePanes that you do not want them to have access to to "no access"

Old school method ;)

[Merkley]

I found that we have students doing this as well, for the most part. The way they are doing it at our district is by hiding the system preference pane in the view menu then searching for the pane while in System Preferences. Although I've noticed the same way @stevehillnz described as well. I haven't been able to test this more thoroughly yet but I do plan on doing more testing and trying the method @calumhunter has said. They do this to remove the user level configuration profile that is installed to restrict apps so they have access to apps that the schools don't want them to have access. Our production JSS is 9.32 which students can do what has been stated above.

I have upgrade my test environment to 9.6 but haven't had a chance to check on this yet. I plan on doing my testing on Friday when I return to the office.

[mm2270]

At one time, long before I knew how to use or deploy MCX, I used to do the old school method as well and make the System Preferences panes I wanted locked, owned and only accessible by root. No users could access them that way, but I also couldn't either if I had to sit down at someone's Mac, so while it works, its most definitely a kludge.

There are some other options you can look at.
1- Consider looking into whitelist and blacklist folder paths. I don't know how to do this with Config Profiles, but I know old school MCX has this. Essentially you can set up locations (paths) that applications are allowed to run from, so for example, /Applications/ and /Applications/Utilities and perhaps a few others, like from the root /Library/ directory. Blacklist anything from the /Users/ directory path and they won't even be able to launch the modified app from their home folder.
This approach can work, but has caveats. For ex, if your students need to be able to run any application from their home folder, like a legit app, they won't be able to, which could make it a non starter. Also, enabling this can sometimes create a kind of whack-a-mole in that you may find yourself constantly adding in whitelisted paths as you discover applications that require some support app to run from a path that is currently blacklisted.

2- Another possible method would be to create a custom LaunchDaemon that runs a very simple script every 10-15 seconds. Here's an example of a script that may work. It does this by looking for the process "System Preferences" that is running from any location within the /Users/ directory path.

#!/bin/sh

process=$(ps axww | awk '/Users.*MacOS/System Preferences/{print}')

if [ ! -z "$process" ]; then
    killall "System Preferences"
fi

Note that the script is NOT looking for an app bundle named "System Preferences", but rather for an executable within MacOS with that name and that is also coming from somewhere within /Users/ It will ignore it if its coming from /Applications/, so this will only kill a version that the user has run from their own space. BTW, while they can rename the System Preferences.app bundle to anything they want, you can't rename the /Contents/MacOS/System Preferences binary. It won't launch if you do.

Lastly, regarding the issue of hiding Pref Panes and then being able to access them, sadly, this has been a "bug" in OS X for many years now and Apple has chosen not to address it.
There is a way to plug it with an MCX control, and possibly with a custom Config Profile. See this thread for some more details on how, but you may or may not be able to get it to work, especially under Casper Suite 9
https://jamfnation.jamfsoftware.com/discussion.html?id=10214

[Merkley]

So I tried restricting the access to the Profiles Preference Pane through the black list of the Configuration Profiles and it didn't work. I was still able to gain access to it. I was successful in removing access to the preference pane by modifying the permissions as suggested by @calumhunter. I just ran the command to change the everyone permission to No access and then as a student I couldn't open the preference pane. I will just have to remember to run this if we update the OS.

Thanks, this saved me a lot of time. I still plan on testing this with the latest version of the JSS.

[nessts]

you could create a launch daemon and use watch path to chmod -R 000 the preference pane any time something changes. And sometimes this method is a bit nicer because the users do not see the pane to know they are being locked out of it.

[stevehillnz]

Thanks all for your ideas.

@calumhunter your solution looks workable for this institution. Not sure if I will have to reapply after each OS upgrade, but I'm about to find out.

[calumhunter]

You could always run it as a script with a launchagent, firing off every hour. check the perms of said prefs, if they are not what you want ie available to users, then you have your script go ahead and make it no access for them
that way even if an update or a disk permissions repair changes it, your script will run and reset it back the way you want