Host-based process controls.

[MrP]

I'm trying to prevent applications/binaries from running from any locations where users have write access in an attempt to prevent them from downloading and installing whatever they want. I'm using the Restrictions payload of configuration profiles and am running into some issues. Has anyone else run into this and if so, have they come up with a less clunky solution?

Parameters:
1: As stated above, no non-admins can run applications from folders where they have write access. 2: Admins can run applications from system locations as well as their user profile.

Attempt 1:
1. Restrict which apps are allowed to launch: Check
2. Allowed Apps: none
3. Allow folders: /Users/ADMINACCOUNT
4. Disallow folders: /Users, /Volumes, etc

Problem: As soon as you add anything in the "Allow Folders" category the facility that controls application execution assumes anything NOT in that folder is blocked(ugh...). So in order to make this work I would have to have nothing in the "Allow folders" and our helpdesk would have to log into the JSS and exclude the systems from the restrictions profile before loading any software, drivers, updates on the fly, then remember to remove the exclusion when done. A: This has proven ineffective in the past due to human error which creates a real security issue(removal of the restrictions profile), and B: it's a PITA. Obviously we use casper's centralization to push the majority of changes to systems, however it is sometime required for a helpdesk technician to do one-off tasks on the fly rather than going through the entire server-side process. I have tried a workflow where the admin puts the installer in a location outside of /Users, like /tmp, however some installers like to put binaries in and run them from, the user profile during the installation, like Adobe installers.

Attempt 2:
1. Restrict which apps are allowed to launch: Check
2. Allowed Apps: none
3. Allow folders: All root folders which users do not have write access to, including "/private/tmp"(also added /tmp) for good measure, and not including user writable locations like "/Users" and "/Volumes".
4. Disallow folders: None.

Problem: Some apps like to put binaries in randomly named folders under "/tmp". For some reason including "/private/tmp" and "/tmp"(which is just an alias) in the "Allow Folders" doesn't allow apps from sub-folders, which is odd considering allowing "/System" and "/Library" allows apps/binaries under them to run without issue. Being that the folders are randomly named under /tmp|/private/tmp, I cannot pre-enter an allow for it, so the application in question won't operate properly. The "Apps Allow" isn't customization. All apps listed are pre-set and not based on inventory, so I cannot add the app as allowed there.

Is restricting apps from running from user locations overkill? Well since I turned it on I've had a number of users report "not having permissions to run applications" and upon inspection it has always been an application they took upon them selves to download to their profile. This is strictly against use policy. So it has helped. Once upon a time we had a proxy with ssl inspection which filtered all such downloads, but our services on that level were commandeered by a parent entity which doesn't have that level of filtration and we don't have any control over what filtration there is. This leaves us to have to compensate on the client side, less have people downloading apps the their user profiles, which again, is strictly against the use agreement. As an admin it's not my place to take corrective action on personnel issues, however I do need to make sure I'm doing everything I can, within reason, to prevent violations.

Maybe there is a third-party option? Our current enterprise AV doesn't offer anything like that for Mac, and it's windows offering is pathetic so I wouldn't hope for much better even if they did have a Mac variant. Not that above is any better. :)

Cheers,
Paul