Google's Santa tool (https://github.com/google/santa) supports blocking executables via a Path regex: https://santa.dev/concepts/scopes.html
Jamf is able to blacklist software, but it is by file name, binary, etc., not execution path. If you block Google Chrome.app it will block it anywhere its run from. What you are asking is more the domain of a Security Tool, and yes there are tools to do this. I would suggest looking into something from Carbon Black or CyberArk.
I have used CyberArk EPM specifically for what you are asking with good success in the past. You create policies for what is allowed to run from specifically where. I have had policies that limit where .dmg's can be mounted from for example, if it is not in a specific directory the dmg cannot mount as the process is killed and the user gets an error. This workflow can be adapted to only allow .app extensions to run from /Applications and so on. Use the right tool for the job or have a bad time 
.
Jamf is able to blacklist software, but it is by file name, binary, etc., not execution path. If you block Google Chrome.app it will block it anywhere its run from. What you are asking is more the domain of a Security Tool, and yes there are tools to do this. I would suggest looking into something from Carbon Black or CyberArk.
I have used CyberArk EPM specifically for what you are asking with good success in the past. You create policies for what is allowed to run from specifically where. I have had policies that limit where .dmg's can be mounted from for example, if it is not in a specific directory the dmg cannot mount as the process is killed and the user gets an error. This workflow can be adapted to only allow .app extensions to run from /Applications and so on. Use the right tool for the job or have a bad time .
So, disallowing and allowing app paths in Restrictions payload of Config Profiles doesn't work anymore?
So, disallowing and allowing app paths in Restrictions payload of Config Profiles doesn't work anymore?
Are you doing it here?
Are you doing it here?
They're referring to the Restrictions > Applications > Restrict which apps are allowed to launch configuration profile payload I linked to up above. That method should work, but I was unsure if it was still the recommendation after a decade of Apple and Jamf changing things up.
They're referring to the Restrictions > Applications > Restrict which apps are allowed to launch configuration profile payload I linked to up above. That method should work, but I was unsure if it was still the recommendation after a decade of Apple and Jamf changing things up.
I did not know that was even there. I would not want to use it, because you would pretty much have to specify every folder on the system you want to disallow. With how creative users are, you will be specifying a lot of folders. Either way, that is a very nifty bit of info, thanks for teaching me something.
I did not know that was even there. I would not want to use it, because you would pretty much have to specify every folder on the system you want to disallow. With how creative users are, you will be specifying a lot of folders. Either way, that is a very nifty bit of info, thanks for teaching me something.
It's definitely more of a blunt hammer than a scalpel, but in theory if you just want to block the /Users/ folder and then allow list a few other major directories in it like ~/Library/ you can cover most of the bases without needing a massive number of rules. If your users aren't admin, they're not gonna be able to put things that far outside of their own directories.
I did not know that was even there. I would not want to use it, because you would pretty much have to specify every folder on the system you want to disallow. With how creative users are, you will be specifying a lot of folders. Either way, that is a very nifty bit of info, thanks for teaching me something.
Responding to this thread since I just did some recent testing in Sequoia.
Technically, all of these keys were deprecated back in Catalina. But some appear to still be working on 15.3.2.
I tried using the 'Disallow Folders' option, specified a couple userland folders (~/Desktop/, ~/Downloads/, etc) - and couldn't get it to do anything. Not sure if I was doing something wrong, but I couldn't get it to work at all.
Switched to using the 'Allow Folders' option with an allow-list that #MacAdmins user @Asnyder graciously posted:
/Applications/
/Library/
/System/
/bin/
/usr/
~/Library/Application Support/Pearson/
/Users/Shared/
/Library/Google/
~/Library/Google/
/anaconda3/
~/Library/Google/
~/Library/Printers/
~/Library/Enthought
/opt/
~/Library/Application Support/Pearson
~/Library/Application Support/Autodesk
~/Documents/Unity/
~/Documents/Unreal Projects/
/Library/Application Support/Google/
And so far, it seems to work wonderfully. The only thing I've had to add was that Google path on the bottom because the Chrome keystone updater was getting blocked.
As always, test thoroughly before deploying. Currently have a group of testers doing more testing.
Had one where GoToMeeting.app was installed in user-level /Application Support/ - had to move to /Applications/. Between that and adding the Google path, that's been about it so far.
Seems to work pretty sweet. Somewhat similar to Google Santa without all of the setup. Example of the block message:
If you go with the Allow List route, and you download a .dmg somewhere and then mount it, it will block you from running any .app that is inside the .dmg. So it essentially also blocks .apps from running out of /Volumes/ which is nice.
So while this could technically stop working in a future update because it's deprecated, for now it seems to still work pretty well.
@whiteb I just started using this feature for the first time recently, even though I’ve known about it for many years. Like you suggested, as long as you set this up by restricting the /Users path and then allowing the folders you want to allow applications to run from, it seems to still work. I hope Apple doesn’t remove the ability to use this in a future release.
The only issue I’m concerned about is that it seems to tie into “Parental Controls”, and the pop up for the user gives them an opportunity to bypass the block as shown in your screenshot, if they happen to have local admin credentials. While I would like to say no Mac users outside of those in IT have local admin creds, I can’t be 100% certain of that. I’ve been trying to track down where the OS stores this bypass setting when it’s used, and so far I haven’t been able to locate it.
Does anyone happen to know where this might get stored? I’d like to build something, like an Extension Attribute or a weekly script, to detect any bypasses that might have taken place so I can remediate these.
