Prevent removal of JAMF binary by local admin

j_meister
Contributor

Is there a way to prevent local administrators from removing the JAMF Binary with

jamf removeFramework

?

We still need local administrator accounts for our professors but don't want them to be able to delete the JAMF Framework.

45 REPLIES 45

garybidwell
Contributor II

not prevent, but a way to repair

https://github.com/jamf/JSSBinarySelfHeal

or

https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

Hugonaut
Valued Contributor

you need to modify the sudoers file located in /etc/ -> /etc/sudoers

comment out the line containing

%admin ALL=(ALL) ALL

result

#%admin ALL=(ALL) ALL

and any user that is an admin will no longer be able to run sudo commands. πŸ˜ƒ

they need to do "sudo" for all jamf commands and this will prevent that.


  • please if anyone that knows sees the following, correct me if I'm wrong here

I've never taken this next stop as I'm not positive whether or not it's necessary but if you are really worried, to double down you should also chmod the directory utility application so only users with root privvies can execute it, by default its privileges are

drwxr-xr-x

i dont know if changing the admin sudoers privies prevents this, but i think admin users can still run this which in turn allows them to enable root account and then they could use terminal to login to root and run sudo commands as well. it is by default chowned root:wheel so no need for chownage.

________________
Looking for a Jamf Managed Service Provider? Look no further than Rocketman

garybidwell
Contributor II

We couldn't lock down the sudoer list, as some devs need to run sudo level commands for their work
We just rely on healing as a precaution, as if they're going out of their way to remove the management framework (whether its Mac, Windows or any other platform) then this is a HR issue, as they would have agreed to the IT acceptable use polices when they joined the company and this action would be in breach of this.

j_meister
Contributor

Thanks for your help guys. Although I am a bit disappointed that there is no way to prevent the removal of the JAMF binary I will look into gbidwell's links.
Disallowing sudo is no option as some of our professors use sudo a lot.

Hopefully JAMF will offer an easy and good solution for preventing the removal of the binary in the future.

wesleya
Contributor

Not to be a naysayer, but there is an end of life notice in the GitHub:

I will no longer be offering support for this Self Heal application. Due to the new User Approved MDM additions to 10.13, this is no longer a good tool to be running on client machines. This tool will break the User Approved status of MDM which will break user level profiles and the ability to install VPP apps. Sorry for the inconvenience.

Our people have the same capabilities, and I really don't have that many issues with people doing this. The one thing I can think of is making Jamf as valuable of a resource as you can with Self Service and not being too heavy-handed with how it all works.

gachowski
Valued Contributor II

So the correct solution to this issue is for Apple to allow MDM companies to install their agents/apps to a SIP location. As while that is really easy to write as a sentence you could see where it's a big can of worms.

That said it's no bigger can of worms than, Team Identifiers and gatekeeper certs.

C

churley
New Contributor

You can also restrict commands through sudo. I have a number of developers that need sudo access so I have a list of commands that they are not allowed to run like any jamf commands.

here is the sample code to add to suders
<username> ALL=(ALL) ALL
<username> ALL = !/usr/bin/passwd root, !/usr/bin/su -, !/usr/sbin/visudo, !/usr/bin/vi /etc/sudoers, !/usr/bin/vi /private/etc/sudoers, !/usr/bin/sudo -e /etc/sudoers, !/usr/bin/sudo -e /private/etc/sudoers, !/usr/local/bin/jamf

garybidwell
Contributor II

I don’t see having healing not being able to preapprove MDM profiles in 10.13 onwards being a too much of issue to circumvent, as it can actually be benifit when combined with conditional access.
As long as the binary is installed, it can still report back in to the JSS and update it’s current status.
By having a non approved MDM status for us it means the access to network services are revoked as the conditional requirements are no longer met.

But following on from wesleya’s comment, making Self Service invaluable to the user is the key to making this issue a mute point for the future.
We only give dev’s admin permissions due to their specific job requirements, as we have try to make as many of the benefits of having admin permissions to be made avalible to standard users through Self Service in a controlled & auditied environment.
By making standard users empowered via Self Service as much as possible, we find now that we hardly get any requests from them to make them a local admin.
Out of thousands of users and from the last few years running on Jamf, we’ve only ever had one incident where the binary was disabled on purpose, but they soon came back into the fold when suddenly they found their abilities greatly reduced and received a gental notification message that they were breaking company policy.

bugsin
New Contributor II

If you don't want them to remove the binary then I would do one of two things:

  1. disallow local admin
  2. report removal to human resources

tdilossi
Contributor

I have made terminal, restricted software, so local admins can't launch it to remove the framework. We can remove them from the scope when we need to, but they try to launch terminal, they get nothing.

CorpIT_eB
Contributor II

I hate to bring back an Old thread but how do I prevent the local admins who discover the JAMF bin and start playing with the JAMF commands. 100% of all my mac users are Engineers and Developers and have admin access to their machines.

But don't want them poking around on those array's. Is there a way to prevent admin from running sudo jamf commands?

cpresnall
Contributor

You would need to add the devices to ABM and then a PreStage in Jamf. This will let you make the Jamf binary and MDM profile non-removable.

CorpIT_eB
Contributor II

@cpresnall forgive my ignorance but what's "ABM" and can you go into more detail on this processes I would be most grateful.

ryan_ball
Valued Contributor

ABM - Apple Business Manager

Also, that is not quite correct. With DEP enrollment you can make the MDM profile non-removable, but not the Jamf binary.

CorpIT_eB
Contributor II

Thanks @ryan.ball I was about to say the very same thing I have never seen either of those option on the Apple Business Manager (ABM)

ryan_ball
Valued Contributor

The option for restricting MDM profile removal would be in your Jamf Pro DEP Prestage Enrollment.

cpresnall
Contributor

ABM = Apple Business Manager. This is what the DEP or Device Enrollment Program has become.
Basically it allows you to link your devices to Jamf during initial setup through certificate based communication with Apple. Businesses sign up and then add their devices by purchase order number to their ABM account. When the device goes through setup assistant it reaches out to Apple, confirms that the serial number in in ABM, and then ABM tells the device what MDM to talk to. In this case, ABM tells the device to talk to Jamf, and in Jamf you set up a Pre-Stage telling the device what to do on setup (create users, install profiles, make MDM non-removable, etc.).

Once set up, this makes things much simpler for businesses especially where the users are admins, or where IT does not have the throughput to physically touch each device prior to handing it out.

CorpIT_eB
Contributor II

@cpresnall The thing is our Business never gets to see the DEP processes our company has a middle man since we don't use apple directly. So I have no idea what it looks like from that end.

I usually restrict MDM removal from the profile itself but that's not what I was looking for.

gachowski
Valued Contributor II

@CorpIT_eB

https://help.apple.com/businessmanager/en.lproj/static.html

I would recommend that you require your middle man to set up DEP/ABM. We use many vendors all over the world and they all support DEP/ABM.

C

tomhastings
Contributor II

CorpIT_eB, you can still use DEP even if you don't purchase directly from Apple. Most resellers are DEP enabled these days. At my last position I had to request the reseller to complete their part of the DEP process. Enabling it for current and future purchases is a simple process for them but apparently a "real difficult process" for Macs that had been purchased a few years ago.

tnielsen
Valued Contributor

The best solution may be a non-technical one.

ryan_ball
Valued Contributor

This is what I would do. Use a LaunchDaemon to detect if the binary is present, and if it is not reinstall it. The LaunchDaemon would be set to RunAtLoad and StartInterval of say 60 seconds. This would be a script to start with (I have not tested this script):

#!/bin/bash

log="/Library/Logs/Jamf_Framework_Rescue.log"
jamfBinaryPath="/usr/local/bin/jamf"
jamfProURL="https://jamfpro.yourcompany.com:8443"

function writelog () {
    DATE=$(date +%Y-%m-%d %H:%M:%S)
    /bin/echo "${1}"
    /bin/echo "$DATE" " $1" >> "$log"
}

function jamf_framework_rescue () {
    if [[ ! -e "$jamfBinaryPath" ]]; then
        writelog "Jamf Binary is missing, reinstalling..."

        # Download the jamf binary from the Jamf Pro server
        curl -ks "$jamfProURL/bin/jamf" -o /tmp/jamf | while read -r LINE; do writelog "$LINE"; done

        # Create required directories
        mkdir -p /usr/local/jamf/bin /usr/local/bin | while read -r LINE; do writelog "$LINE"; done

        # Move the jamf binary
        mv /tmp/jamf /usr/local/jamf/bin | while read -r LINE; do writelog "$LINE"; done

        # Make the jamf binary executable
        chmod +x /usr/local/jamf/bin/jamf | while read -r LINE; do writelog "$LINE"; done

        # Create a symbolic link
        ln -s /usr/local/jamf/bin/jamf /usr/local/bin | while read -r LINE; do writelog "$LINE"; done

        # Create a configuration file
        jamf createConf -k -url "$jamfProURL" | while read -r LINE; do writelog "$LINE"; done
    fi
}

# Run the function
jamf_framework_rescue

exit 0

And surprise surprise, you can create the LaunchDaemon using my tool, Launchd Package Creator.

CorpIT_eB
Contributor II

@ryan.ball I wish I knew how to utilize that tool just by looking at it, it looks amazing.

ryan_ball
Valued Contributor

@CorpIT_eB You can do it! Let me know if you have any questions about it. ryan.ball on the MacAdmins Slack.

gachowski
Valued Contributor II

You can most likely, set your VPN to verify that the binary is there.

C

jwojda
Valued Contributor II

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.

ryan_ball
Valued Contributor

Or do a

jamf enroll -invitation invitationIDFromYourJamfPro

CorpIT_eB
Contributor II

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

wmehilos
Contributor

@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.

hdsreid
Contributor III

@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

CorpIT_eB
Contributor II

@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.

ryan_ball
Valued Contributor

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

CorpIT_eB
Contributor II

@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.

jwojda
Valued Contributor II

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?

ryan_ball
Valued Contributor

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

tlarkin
Honored Contributor

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

craigo
New Contributor III

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

jameson
Contributor II

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

jwojda
Valued Contributor II

@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.