Students can bypass software restriction

Someone at JAMF is misinformed. I'm using their Restricted Software feature in the JSS to block several items. Whether the application is renamed or not it's working for me.

For example, I block Caffeine, which is an application that disables screen savers. In my Restricted Software list I have blocked the "Caffeine" process. This is the process I would seen in Activity Monitor while the application is running. Don't use the name of the application itself "Caffeine.app".

Yep. Page 380 of the 8.6 admin guide: (emphasis added)

6. Enter the name of the process that you want to restrict. The process name is case-sensitive and supports filename wildcards.

Hmm, I wonder why.

For example, I have the process called "Terminal" in the restricted software page and when I run it in the Utilities folder, it definitely fails to start. It gives me the nice message and everything saying it is disabled. When I copy it over, and rename it to "Term", the application starts up no problem. Even though in activity monitor it still shows the process as Terminal.

Edit: The response I received -
"Hope this response finds you well. It turns out that the string we look for with Restricted Software is actually the Terminal.app part of the process and not the word or phrase that appears in Activity Monitor. Basically, we need the name of the application in order to restrict it. I understand this isn't ideal, as it turns the restriction process into a game of whack-a-mole."

he may have renamed the app. but the executable likely did not get renamed, if you have a launchdaemon looking for process Terminal
/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
But, you must be saying that he copied Terminal to his home and renamed it right? /Applications and Utilities should be owned by root:admin and there is no way without admin rights to copy in the applications folder.
do you have recovery partitions, thats probably a hole in your plan too, there is a terminal with essentially root access. you could also make terminal only visible to root:admin
sudo chmod -R o-rwX /Applications/Utilities/Terminal.app
which would leave it for admins but remove it from being seen by the other users.

Hi Everyone,

These users have write access to the /Applications folder? I used to manage Macs in a school environment and I restricted apps from running by file path. There is a template in the JSS for this, it is called applicationaccess.new. You can set the path of allowed and disallowed apps. Then toss everything you don't want them to run in say /Application/Utilities and restrict it.

Normal users should not have write access to the /Applications folder. Then restrict any app from running from /Users.

I hope this helps,
Tom

Perhaps OP means ~/Applications?

The users do not have write access to Applications, they are copying Terminal elsewhere, such as their mobile account's home. The way the process shows when doing a ps ax | grep on it is as follows (which seems like it is the root of the issue):

25017 ?? S 0:03.34 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

I checked one of the renamed versions and as nessts said the actual executable was not renamed but the .app container was indeed renamed which seems to throw it off for some reason. We have tested this with a few apps now and is definitely the case. Hope this helps clarify things a bit.

I think for now we will restrict apps from running in the /Users folder as mentioned by tlarkin. I still feel that the Application Restriction should be killing the Terminal process even if it is moved and the .app container renamed, though, as the executable is still "Terminal".

One of the most effective ways I've found to prevent unauthorized app launching is to create folder whitelist and blacklist MCX settings in Managed Preferences to prevent app launching from the /Users/ path and only allow it from /Applications/ and /Applications/Utilities/ This is found under com.apple.applicationaccess.new in Managed Preferences. (Edit: sorry, didn't see that Tom had a;ready mentioned this. Agreed with him.)

Then set up Software Restrictions for the couple of apps you don't want users to launch, like Terminal. With both of these in place, even if a user copies an app to their home directory in an attempt to rename it, bypass the settings or whatever, no apps from their home folder will launch.

Obviously, in certain cases this may be too strict of a setting. Some rare applications need to open processes from the users home folder and may not work right in those cases.

All that said, I was always under the impression the way the process appears in Activity Monitor is what we should be adding in to the Restricted Software setting. That has always worked fine for me and has never been bypassed to my knowledge..

yeah, use mcx for this. otherwise, you're fighting against the tide. i've always thought the casper method of killing processes was crude. define whitelisted folder locations, including app support folders, if certain apps need them, then make sure standard users can't write to them to add their own stuff.

Use MCX white/black lists to restrict apps from running in non writeable places.

While using the MCX Blacklist/Whitelist is probably what we will implement, I think my main issue that I wanted to bring to the attention of JAMF was that the Restricted Software section seems to not be behaving as intended(unless that process field is there for show). We also use a classroom management software and it has the ability to limit application usage as well - and it correctly prevents the executable from opening no matter what the .app container is named. This could show that there is a loophole in the Casper Restricted Software enforcement -- unless this is unique to our setup?

Can we have another user test this possibly (even though we had JAMF try it and they replicated it on their own machines)? Just copy Terminal into a User Home folder and rename the .app container and run it.

I tested in my environment and Restricted Software worked fine.

I copied the Terminal.app to my ~/Applications folder and renamed it "Thing.app". After firing it up it was quit and deleted in less than 10 seconds.

Using Casper 8.43 and Mac OS X 10.7.4 here.

OP what version of the JSS are you on?

Yeah, I'm curious what version you're on as well. I'm wondering if this is a new defect introduced in a recent version perhaps.

Also curious to know what OS the Macs are running that are able to bypass this.

Appreciate the opportunity to participate here. There's a defect in 8.6 that is causing some issues when using Restricted Software to block based on process name. Sounds like this is what's being encountered here. This has been registered under D-003132, and I'm showing this as fixed so presumably it will be in the next release.

A suggested workaround until the next release would be to "killall terminal" (or the appropriate process name), either directly in an every15 policy, or via a script that deploys a LaunchAgent to run more frequently.

Not the best solution, obviously-- but once the next release is out you should be able to continue to use Software Restrictions combined with a Config Profile or MCX to limit applications to those within /Applications.

-Rob

@Rob, thanks for the confirmation. Glad to hear it will be fixed. I think most of us never give Restricted Software much thought because it has always and forever worked by seeing the process name and not the executable bundle name. Its one of those things that, unless you test this out with each new release, you'd never know was broken.

Thank you Rob, appreciate the information on that. We are looking forward to that release :)

Also, we were thinking about doing the killall Terminal in a script, but we are hoping the MCX way will prove to be enough for the time being. I also wish there were time based restrictions as this is a one-to-one, yet students have the choice to rent or bring their own, so we cannot restrict Terminal at home during after school hours for those people that opt to bring their own, but that's for another discussion.

As for the topic at hand, thank you Rob for clearing it up. We were on the latest release so that seems like the reason indeed.

Thanks again to all who helped out! :)

(Also to mm2270 we have a mostly 10.7.4 campus, some students that brought their own have 10.8.1 or 10.8 if you were still curious)