MCX Blacklist?

[Ebonfyre]

I’m trying to learn the ins and outs of user management via local MCX records. I’ve googled till my fingers are numb and am not finding any clear answer to this question:

Can you simply tell OSX not to allow one application to run?

In WGM it’s clear enough that you can provide lists of apps that are approved, but there is no similar “disallow” list. I see disallow in the folder restrictions, but that forces you to define an “allow” folder list as well. I don’t want to attempt to manage allow lists, I don’t feel comfortable that I’d think of every possible app.

Using mcxquery it is clear that there is a “whiteList” key, is there a simple “blackList” that I’m just not finding documented anywhere?

Perhaps I’m just naive of the implications programmatically why this isn’t completely clear and easy to do, but it just doesn’t seem like a tough request.

My goal is to simply disallow the use of Skype for the Student account, while allowing it on the Teacher account in a schoolwide laptop deployment. When I first read about MCX management it sounded perfect, but nothing I have found is reassuring me that it actually will do what I want, and so far I have failed to get it to do so with my own trial and error with WGM and dscl.

I’m running a mixed 10.5.8 and 10.6.3 environment, to be clear. Sorry if this is a newb question, but I’ve wasted so much time searching for this answer on my own.

[tlarkin]

May I make a suggestion? I am in a similar situation, I work for a school system and I have to be able to manage what apps users get and use. In OD, I use MCX to manage the absolute path apps can run from. So, I restrict applications to only be able to run from /Applications, and say all apps can only be ran from here. Then apps that I may want local admin to use but not the user I simply move them into /Applications/Utilities and that way the app is there, but the managed user cannot use them. This also prevents students from running skype from a thumb drive, because the path is not in /Applications. They don’t have the ability to write to the /Applications folder at all, so they cannot drop their own apps in.

Then you can set up a teacher group in OD and not even manage them at all for apps to run. This will be applied via their group policy. I find this more efficient than running approved software lists, because with out digital signing they can just rename the app to an approved one and get away with it, especially if they own it and it is running from their desktop. I tried digital signing in 10.5.2 and it was a hot mess, so I stopped using it. Could be way better now, but I haven’t changed my methods just yet.

[Bill-G]

Hi,
there are two ways to accomplish this.

1. in the section for disallowing applications within specific folders select the Skype. As Skype.app is really just a folder containing all of it’s constituent parts, including the actual executable, you can block an individual application by selecting it as the folder. The UI could do with making this more clear although it is in the docs, albeit not as explicitly as it could be.

2. if you don’t select anything in the Applications tab then the settings in the Legacy tab will apply to all applications, even for 10.5 or later, so you could simply blacklist Skype in there. This probably won’t work if you have previously used the Applications tab unless you clear everthing out of that tab’s settings before turning of management.

Bill

[tlarkin]

Just to add something from my experience…

We had a state assessment testing software suite, which was written in Java and had a self update option, which was not optional. Anytime the State updated their server side, you had to update your client side. So to keep it simple, and easy for the IT staff when I built the package, I left the update folder writable, so that all updates could be downloaded and applied. Well, one student figured out that one nested folder in some application was writable, and they started dropping their own apps in that folder. Lone and behold, one student told another and with in like a week we had 100s of students dropping apps in this folder.

So, I had to create a network policy (via Casper) that hit every student machine, wiped out their Kansas Assessment testing software folder and copied the new one over, and this time that folder [b][u]was not[/u][/b] writable at all. This means that I had to repack the update and push it out manually anytime they put an update out. This is one of the caveats of using folder paths.

The upside to it, is it is really less work in the end. If I look at total “overall cost of ownership,” of my methodology of creating packages and images, this actually benefits me. Since I standardized everything from the base OS image, and then configure everything via post image scripts based on users/groups (students, teachers, middle schools, lower schools, etc.) I have to repack that application anyway to update the image. I use instaDMG and instaup2date python scripts to build my base OS. Then compile that base OS with all my packages in Casper. This allows me to have a pristine up to date image that will go on all my macs in my enterprise. Having this set up this way means I can keep a base image of what every Mac should have, whole deployment wide, and then build post image shell script that pull down packages for those specific group of users.

So, if you are going to keep your images up to date, you might as well repack your packages anyway when they get updated. This also gives you the chance to test the update.

The problem I ran into with the whitelist/blacklist options, were that if you did not use digital signing, the user could just rename the app whatever they wanted. If you did use digital signing, any and every single app with in the application’s contents. Some developers love to put other apps with in their App’s content folder. This gets super annoying to drill through each application with in it’s contents and put a digital signing onto every app with in it.

I went through this in 10.5.2 and gave up on it. It may have vastly improved, but even the iLife apps had issues. For example, garage band would not run because it was not allowing a bom file to go through. So I had to drill into that app in WGM, to that specific bom file in Garage Band, and allow it. After doing that once and seeing it fixed the issue I went to file path immediately.

[Ebonfyre]

What about all the supplemental apps that live in the less evident areas of the system, such as CoreServices? How can you possibly ensure that you have all those locations taken into consideration?

[tlarkin]

[QUOTE][u]Quote by: Ebonfyre[/u][p]What about all the supplemental apps that live in the less evident areas of the system, such as CoreServices? How can you possibly ensure that you have all those locations taken into consideration?[/p][/QUOTE]

You have to add the path. For example, Adobe puts an app that validates the license file online in /Library/Application Support/ so I have to approve that path for CS4 to run. I have not had any issues so far with anything from the CoreServices folder.

[Author]

Posts