Prevent removal of JAMF binary by local admin

Ran this on a test machine... the binary did come back down but w/o an enrollment it's not going to do much good.

(did a removeFramework, then verified jamf binary was off) $ jamf -bash: /usr/local/bin/jamf: No such file or directory <I installed and rebooted here and then reopened terminal> $ jamf There is an error in your syntax. Error: No verb was specified. Type "jamf help" for more information. $ jamf version version=10.13.0-t1559772983 $ sudo jamf recon Password: There was an error. The file /Library/Preferences/com.jamfsoftware.jamf.plist does not exist. Use the createConf verb to create it.

It seems w/o calling / doing a quickadd or similar it may put the binary back on, but you wont be able to do anything with it.

Or do a

jamf enroll -invitation invitationIDFromYourJamfPro

@ryan.ball Just out of curiosity where can I locate the "InvitationID" is that a hashed ID or the link to the website enrollment?

@CorpIT_eB you can get the invitation ID from a QuickAdd package's post install script, or you can pull it straight from your MySQL database if you're running on-prem. QuickAdd is probably the easiest.

@CorpIT_eB create a new email invitation and send it to yourself. set a date that isn't going to expire soon and run through the prompts. At the end, click the invite you just created to open up the status page and there will be an invitation ID in there for you to use

@hdsreid does this invitation ever change or it's always the same id instance?

So it would looks something like this.

jamf enroll -invitation 18912347651903847514576134548519324851 (not real ID)

Or would I still need to include the Variable "Invitation" since I see it triggered there.

@CorpIT_eB The invitation id will not change, but will expire at the date listed. That looks right to me.

@ryan.ball If it's not too much trouble, could you mock up a workflow on how we could implement this in our environments. This would also help understand how to properly use your tool.

I too host developers, and Engineers that are local admin to their machines and have started playing around with the JAMF binary's and want 100% to block this to possibly a group of JAMF admins or LDAP users only.

It would be awesome to do it via a MDM profile so there is no way it can ben removed.

I ran this with the invitation enrollment string, it still failed to enroll due to the configuration file not being present, everything looks correct in the script though.

As I've been working on this, it's occurred to me that on 10.14+ the user will still need to manually approve the MDM for this, correct?

@CorpIT_eB I will work on something and throw it on github.

Just alias removeframework to echo "Ah ah ah, you have to say the magic word" as a global shell profile setting

The other thing you need to worry about is them deleting the JSS certificates, that will break the MDM functionality.

That is not something you should spend time on in my view. If one of my users Would remove it I would give him a Warning and should it happen again my manager would contact the users manager.

If business making own rules outside agreement there is a problem inside the Company

@jameson it's not always within our control. But as admins I (we) rarely find out until it's been a while. Be it from a bug in the JSS upgrades that breaks the connection or users, knowingly or not, break it. A failsafe should be in place. I've seen it with AV products and other security focused products that actively prevent tampering with their binaries. Why not jamf? Until jamf adds it, we as admins need to have some sort of mechanism to fill the need.

@ryan.ball you're the man!!

Ok, Everyone it seems as we are temporarily solo in this endeavor I spoke with Support and they have been great. However there response was:

I did speak with a few others to ensure I wasn't missing anything and as of right now, if the users are admins and have access to terminal there isn't a way to lock down the Jamf binary.

CHALLENGE ACCEPTED!!

So I might submit it as a Enhancement Request. But I am sure we all can come up with a work around that would work to our advantage soon.

I love this community!

Bump to the need of password protecting jamf removeframework OR a health check/re-enroll launchdaemon

macOS Supervision is just not as robust as mobile OSes

Give one warning and then fire the next person who does it. Odds are good they will stop messing with it. Some solutions do not require technical expertise.

Considering an automated re-enroll won't be an option with Big Sur and beyond, I think the best solution is to make sure Jamf is a requirement for accessing the network and company resources. If someone runs removeFramework or removes the MDM profile, make sure they lose their machine certificate as well. Our Macs would lose all network/VPN access as well as conditional access.

That said, we have security agents that are very hard to remove and require some safe mode shenanigans, so Jamf surely can do better than having removeFramework be so accessible.

We capture Macs which are not checking in for 30 days or longer, and automatically send weekly emails to users with CC to their managers. Anytime it can be easily changed with CC/BCC to HR. So, "now we have your attention" :) Users who were consistently ignoring any emails from IT, now responding back

I will echo @mhasman 's idea here. The best way to track this is to capture data and build intelligence around devices not checking in or submitting inventory. 30 day threshold seems to be the a great target area. We are already doing this. Adding tamper protection to the jamf binary sounds like it will cause way more problems than it will solve.

Also, look at adding other tools to your tools stack as just having jamf is a single point of failure. Then have the other tools health check each other.

This is an interesting suggestion. How would I set about doing this?

We can block specific commands to be executed by Admin users and in this case i have blocked jamf binary except recon, manage, policy, version, checkJSSConnection. 

There is possibilities of removing the binary location completely by user if they have admin access and optionally can be block rm command too but not recommended instead we can use the Extension Attributes to track the file location to re-deploy if deleted.

#!/bin/bash

SUDOERS_FILE="/etc/sudoers.d/block_jamf_remove"

cat << 'EOF' > "$SUDOERS_FILE"

#Block the JAMF Binary are located as given below
Cmnd_Alias BLOCK_JAMF_FRAMEWORK = /usr/local/bin/jamf, /usr/local/jamf/bin/jamf

#JAMF Binary are allowed to execute as given below
Cmnd_Alias ALLOW_JAMF_BINARY = /usr/local/bin/jamf recon, /usr/local/bin/jamf policy, /usr/local/bin/jamf manage, /usr/local/jamf/bin/jamf recon, /usr/local/jamf/bin/jamf policy, /usr/local/jamf/bin/jamf manage

########################
# User specifications
########################

# root can run anything
root    ALL = (ALL) ALL

# Admin group can run ANY command EXCEPT removing the jamf framework
%admin  ALL = (ALL) ALL, !BLOCK_JAMF_FRAMEWORK
%admin  ALL = (ALL) PASSWD: ALLOW_JAMF_BINARY
EOF

chmod 440 "$SUDOERS_FILE"

/usr/sbin/visudo -cf "$SUDOERS_FILE"
if [[ $? -ne 0 ]]; then
    echo "ERROR: sudoers file validation failed, removing file."
    rm "$SUDOERS_FILE"
    exit 1
fi

echo "Sudoers file deployed successfully."
exit 0

 

​@JamfTechHelp should be marked a solution for modern management. DDM commands are coming for this. cheaper than that pile Scyberark minus the C

Switch your perspective. Instead of trying to force your users to do everything right, consider a device compliance perspective:

If their device is not compliant (or not managed), they can’t log into organization resources. This requries a small set of smart groups where any device that hasn’t checked in for a short time, or is not managed, will be considered noncompliant, and is not allowed on the network, not allowed to access data, or if you want to give yourself lots of work and have Connect - not allowed to log into their own computer. 

In the words of Raph Koster, designer on Ultima Online, “The client is in the hands of the enemy. Never ever ever forget this.” 

As rewarding as that would be, you wouldn’t be able to hear their reaction as well as when you block their access while they’re still hired… 

I also do have a small set of shell scripts labeled with the names specific users. The guy who likes to disable the firewall, the gal who likes to tamper with the antivirus and so on.