Restrictive Software loophole

[mcsoellner]

Hello everyone,

I recently discovered that there is a loophole to restricting software.
Currently, I have four restrictive software settings: Mackeeper, Steam, uTorrent, and Minecraft. All set up to remove the applications if they are triggered/launched. Recently, one of my coworkers discovered that if you rename the software in the applications folder, you will be able to launch the software. i.e. rename Steam to Steam2, Steam will not launch, but Steam2 will.

Is there a way to fix this or a better way to restrict software?

[tomr]

Check the box to restrict the software by exact process name.
If you launch Stream and then do a process list or check activity monitor this will be the name you see there. This should also correspond to the binary inside the bundled app.
So in the case of Steam it would be the file inside Steam.app/Contents/MacOS

It is important to note that the process name you put in is case sensitive and must match the name of the running process exactly.

This method takes a little longer to quit the app but it will handle users renaming the app itself.

[mm2270]

This has been a known issue forever. As @tomRGA detailed above, the trick is to use the process name, not the application bundle name to restrict the app. There's no way anyone can rename the binary that runs from the application, even if they rename .app bundle.

The only problem you'll run into with this is that it won't really be able to delete the full application if you set your Restricted Software to delete offending apps. It will delete the application binary, which renders the app useless, but it will leave a shell of an application on the systems.

[mcsoellner]

@tomRGA Hi, thank you for the info. I put in the process and it works; however, it is not deleting the application. Any suggestions?

[tomr]

As @mm2270 pointed out you can't really do that when you restrict a title by process name.
However since it does delete the binary rendering the software useless and the title remains blocked this is probably the lessor of two evils.

[StoneMagnet]

Something may be broken with the "Restrict exact process name" option in 9.100.0. I just duplicated Chess.app to test if both the original and the copy would be blocked using a Restricted Software Record with a Process Name of Chess and the "Restrict exact process name" option enabled. Chess.app is blocked, but Chess copy.app isn't despite both having a process name of Chess.

That was odd. After creating the Restricted Software Record for the exact process name "Chess", Chess.app would be blocked on launch, but not Chess copy.app. Eventually (I tried it a few times, the timing is not consistent) the jamf binary will notice Chess copy.app running and kill it.

[casper_admin]

I did use the binary name to block the Messages app but it takes some time to close the app, and student have enough time to send out a quick message because its taking about 8-10 second before it close. that give them plenty of time to compose and send a message

[mm2270]

Setting up a new Restricted Software title is not immediately active on systems. The Macs need to check in and run a management command to pull down the changes locally to then apply the restriction. So it's normal to see an initial delay from the time a new one is set up in the JSS and when it first starts being active on any machines.

As for there being a delay in closing any apps, unless this has changed, the restricted software process only runs every 10 seconds at most, since I think it still gets called by a LaunchDaemon, and launchd jobs can't run any more frequently than every 10 seconds. So sometimes there's a delay from app launch until it quits. Other times (if you catch it just right) it appears to happen immediately. I'm not sure if there's a good way to prevent any delay up to around 10 seconds with how it works.
That being said, it's possible using exact process matching introduces an additional delay, although I don't know if I've actually seen that happen myself.

[tomr]

What @mm2270 said.
That being said i think there is additional overhead with exact process matching as I have seen an app take longer to quit when blocked it that way as opposed to just doing it by name.
If I had to guess I would say that this is because the process has to become registered and then terminated.
Blocking by name prob just doesn't allow anything within that folder (app bundle) to run. That name is stored locally on the client (in the hidden Blacklist.xml file) and in turn the "blocking" method is much quicker. This would also explain why changing the name of the app allows you to bypass the restriction. It now has a name that is not matched against anything that is supposed to be blocked.
But that's just a guess.

With that being said that 10 seconds is still enough time for students to set up an account an send a message? Or do they already have accounts set up in Messages via some other method?

[StoneMagnet]

@mm2270 I created a restriction for a process named Chess yesterday to test and see if the behavior had changed, then did a sudo jamf policy on my test machine to ensure it had the updated restrictions. As expected, Chess.app was blocked immediately on launch. Chess copy.app on the other hand will run between a few seconds to over a minute before it gets terminated.

[casper_admin]

This is not a work around but a lil trick.

I create 2 Restrictions for the same app (Messages.app).

1st: Blocking process name Messages.app, and not Deleting app
2st: Blocking process name Messages, and Deleting app

This way when a student lunch Messages.app it will close right way. and when they copy and lunch the copy.app there will be a delay then will quit and delete the copy.app, leaving the Messages.app

So the copy always gets deleted, and the original stays and is always blocked instantly. My students end up giving up on keeping coping the app knowing it will quit and delete itself .

[mm2270]

@StoneMagnet If it's true that you're seeing it stay running for up to a minute before being shut down, I would reach out to Jamf on that, as that doesn't sound kosher. It should never take that long to kick in. If it is, they may be able to help diagnose what's going on, or, they may need to go back and take a closer look how they have that implemented to see if they can improve the time. If I saw an app stay up for more than 15 -20 seconds before quitting, it would negate some of the value of blocking the app to me.

[sfappletech]

I’m a new JAMF user and I am having an issue with a handful of manage devices, where the terminal application is restricted in jamf with a kill process command, and many devices are stuck in a loop where the device automatically logs in to the local user account at start up and continuously loops the restricted application folder icon. Problem does not however, occur in safe mode. Trying to resolve this without reimaging and wondering if anyone else in the community has encountered this problem??? Input is appreciated!

[mm2270]

@sfappletech Are you maybe referring to what's described on this thread?