Can we block specific sudo commands from being ran?

[howie_isaacks]

Is there a way to block specific sudo commands from being ran? Two specific commands that I have in mind are:

sudo jamf removeFramework or sudo /usr/local/jamf/bin/jamf removeFramework

sudo -s

We don't want users with admin rights to be able to remove the Jamf framework, and we don't want them to be able to elevate their Terminal session to root. We use CyberArk EPM to allow non-admin users to run sudo commands that they need to run as part of their jobs. I recently discovered that non-admin users can run both of these commands with CyberArk installed. Both are very dangerous. We want to be able to allow legitimate admins to be able to run these commands. I sometimes have to run removeFramework to clear out issues with the Jamf agent or Jamf keychain issues. I also frequently elevate terminal sessions to root to be able to view the contents of certain directories where a normal sudo command won't do it. We just want our regular users to not be allowed to run these commands. I can't think of a way for Jamf Pro to restrict the commands. CyberArk seems to allow ALL sudo commands which is dumber than a bag of hammers 😳 It seems to be a total waste of money. It actually makes our Macs LESS secure.

[shannon_pasto · Accepted solution]

You could try using Cmnd_Alias in the /etc/sudoers file. Something like this...

Cmnd_Alias BLOCKED_COMMANDS = /usr/local/bin/jamf
<username> ALL = ALL, !BLOCKED_COMMANDS

 replace <username> with the username of the user you want to block. That line basically says allow the user <username> to run any command with sudo except those listed in the BLOCKED_COMMANDS section. This won't stop them from editing the sudoers file with sudo though so you might need to add that in.

[howie_isaacks]

I accepted this as the solution because I like doing things like this. I have created scripts that add users to the sudoers group so I am familiar with doing something like this. I'm going to try this. What I wanted was to have a block that would still allow other users to run sudo commands such as with a support tech going into Terminal and using the substitute user command and changing the Terminal to use the managed local admin account.

[shannon_pasto]

Just a side note on this, you can (and probably should) put any modifications to sudoers into /etc/sudoers.d. The reason being is that Apple might overwrite the main /etc/sudoers file with updates or upgrades. You can just drop a file into /etc/sudoers.d with your requirements, eg I created a new file called blocked_list in /private/etc/sudoers.d and put my 2 lines that I shared above into this file.

[howie_isaacks]

You specified "/usr/local/bin/jamf" as one command, but how do we add multiple commands?

[howie_isaacks]

One more thing... I did find out how to add multiple commands. We separate them with a comma. When I am logged in as my test user that I don't want to run specific commands, I used Terminal to enter "sudo jamf recon". I was allowed to run recon and I saw an error:

/etc/sudoers 55:57: syntax error

Obviously I made a syntax error somewhere in the sudoers file.

[shannon_pasto]

that's what it sounds like. Can you share the lines you added? I tried the following and it worked...

Cmnd_Alias BLOCKED_COMMANDS = /usr/local/bin/jamf, /bin/ls
shannon ALL = ALL, !BLOCKED_COMMANDS

[AJPinto]

You probably want to take this ask to CyberArk. You need to create a CyberArk Policy to block the sudo stings you mentioned, and then have a group of users (devices) that are exempted from that policy. 

We also use EPM, and block everything run with sudo. If a given sudo command is needed, a policy is created to auto escalate (most users are not admins) or allow native workflow (OS asks for creds). It may seem heavy handed, but half measures in security, only half way secure you.

[howie_isaacks]

We contacted CyberArk. Here's what they said. I'm copying and pasting it exactly:

"We would like to inform that EPM cannot block any sudo commands. The recommendation is to remove admin permission from the users and then create an Elevate policy (within EPM) for specific sudo commands for these users. is currently a known limitation."

How am I supposed to know all of the specific sudo commands that a user needs? It's stupid that we can't specify the commands we don't want people to run. I still think that CyberArk is crap.

[howie_isaacks]

Using what @shannon_pasto posted, I created this script. 

#!/bin/zsh

# Who is the current logged in user?
currentUser=`/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }'`

# Add blocked commands to /etc/sudoers then add the user to the block. If more commands are needed, separate them with a comma.
echo "Cmnd_Alias BLOCKED_COMMANDS = /usr/local/jamf/bin/jamf" >> /etc/sudoers
echo ""$currentUser" ALL = ALL, !BLOCKED_COMMANDS" >> /etc/sudoers

 It has worked every time I have tested it except once when I screwed up the syntax.

[easyedc]

I've had this working previously in CyberArk, I know it can be done. Unfortunately we no longer have CyberArk in our env so I can't go back and check what rule was enforced. However I do remember it was around the Jamf process and you could provide the string to block while still maintaining access to Jamf recon, Jamf policy, etc. Go back to them and ask again.  The idea is that you're not blocking sudo, you're blocking the Jamf process regardless of sudo or not. The flip can be done, where it also automatically elevated Jamf to allow non-sudo Jamf [verb] if I recall. 

CyberArk was bringing a nuke to a bar fight in most situations which is why it was pulled out of our env.

[howie_isaacks]

I am inclined to think that CyberArk can provide the solution. Maybe my coworker who deals with them just hasn't communicated what we need completely. It doesn't seem logical that CyberArk would be setup to allow ALL sudo commands without some method of blocking what we don't want. I have not yet deployed the script I posted here into production, but if/when I do, we can still use Jamf commands by changing the Terminal session to another admin account. We are about to officially start using LAPS. That is one of the first things that I tested with the managed local administrator.