Prevent Users from running "sudo /usr/local/bin/Jamf removeFramework"

We just create a restriction for the Terminal.app so that users can't open it. This way they can't run any commands that could get them into trouble.

Hi @egill ,

I have wanted to do this but the problem is one of our state testing applications uses Terminal in the background when loading so it breaks that from working. Also we have some smart students who figured out in they turn off their WiFi (disable network connection) and restart, they could use Terminal again without it getting blocked.

Hi @steve.summers ,

This is a very good idea! I am going to check this out more. Thank you!

-Thomas

@tomgideon2003, @steve.summers' suggestion is going to be your best bet here I think. I'm not sure where you heard of a way to disable the removeFramework command, but I'm guessing you have figured out by now that it's not possible. The command is built into the jamf binary and I know of no way to disable it. Unless Jamf is hiding some super secret command from everyone, which, while possible, isn't likely.

What you might have heard of or read about are ways of re-managing/re-enrolling devices that have had the management framework removed from them. For example, you can look at CasperCheck from Rich Trouton, which is based on the work originally designed by the Facebook IT team.

I decided to go with @steve.summers idea. This helps in many ways on other commands they could do also. It is already deployed and working. Thanks!

Hi @mm2270 , yes I believe that is along the lines of what I was hearing about. Thank you for clarifying on that too!

You could do a few things here.

In our CCE class, we were tasked with this exact thing. Our recommendation was to use a launchD to watch the jamf directory and fix the enrollment if it were removed.

You could also go about using alias's to remove the ability to run it. (but I don't remember if I ever got that working.

Regards,
TJ

FYI restricting terminal won't work, users can download iterm2 which is a drag install.

Thank you @tthurman , I think that is along the same lines as the CasperCheck idea from Rich Trouton. I am going to start with the sudoers file changes and see how everything works out.

Also, yes @djdavetrouble , we have had students doing the same workarounds for other restrictions. That is good to know!

We're testing the following script (your mileage will almost certainly vary):

#!/bin/bash
####################################################################################################
#
# ABOUT
#
#   Sudoers: Sets the client-side /etc/sudoers to company security standards
#
####################################################################################################
#
# HISTORY
#
#   Version 0.1, 25-Apr-2017, Dan K. Snelson
#       Original version
#
####################################################################################################
# Import logging functions
source /path/to/client-side/functions.sh
####################################################################################################


ScriptLog " "
ScriptLog "######################################################"
ScriptLog "# Sudoers: Set sudoers to company security standards #"
ScriptLog "######################################################"
ScriptLog " "



## Variables
timestamp=$( /bin/date '+%Y-%m-%d-%H%M%S' )



## Define Functions

function backupSudoers() {

    ScriptLog "Backup sudoers ..."

    /bin/cp -v /etc/sudoers /etc/sudoers.orig
    /bin/cp -v /etc/sudoers /etc/sudoers-${timestamp}

}



function disableLocalAdminGroup() {

    ScriptLog "Disable local admin group ..."

    /usr/bin/sed -i.bak 's/%admin      ALL = (ALL) ALL/#%admin     ALL = (ALL) ALL/g' /etc/sudoers-${timestamp}

}



function enableLocalAdmin() {

    ScriptLog "Enable sudo for ${1} ..."

    /bin/echo " "  >> /etc/sudoers-${timestamp}
    /bin/echo "# Added ${1} on ${timestamp}" >> /etc/sudoers-${timestamp}
    /bin/echo "${1}     ALL=(ALL) ALL" >> /etc/sudoers-${timestamp}

}


function validateSudoers() {

    ScriptLog "Validate sudoers file ..."

    testSudo=$( /usr/sbin/visudo -c -f /etc/sudoers-${timestamp} )

    # Capture the exit code, which indicates success v. failure
    exitCode=$? 
    if [ "${exitCode}" != 0 ]; then

        ScriptLog "Error: "/etc/sudoers-${timestamp}" failed validation; exiting."

        exit 1
    fi

}


function swapSudoers() {

    if [ "${exitCode}" = 0 ]; then

        ScriptLog "Swap sudoers files ..."

        /bin/cp -v /etc/sudoers-${timestamp} /etc/sudoers

        testSudo=$( /usr/sbin/visudo -c -f /etc/sudoers )

        # Capture the exit code, which indicates success v. failure
        newExitCode=$? 
        if [ "${newExitCode}" != 0 ]; then

            ScriptLog "Error: "/etc/sudoers-${timestamp}" failed validation; exiting."

            exit 2

        else

            cleanUpBackups

            jssLog "sudoers updated successfully"

        fi


    fi

}



function cleanUpBackups() {

    ScriptLog "Remove backup files ..."

    /bin/rm -fv /etc/sudoers-${timestamp}*

}


## Call Functions

backupSudoers

disableLocalAdminGroup

enableLocalAdmin "localadmin"

enableLocalAdmin "managementaccount"

validateSudoers

swapSudoers


exit 0

At the risk of stating the obvious, but don't give the users admin access?

Hi @bpavlov , we are too far into it for now with 1,400 students having 1 to 1 computers and admin access that we couldn't switch back. Editing the sudoers file has seemed like our best option now. Thanks!

Couple of pointers/ideas here.

If you are going to edit the sudoers file there is a specific binary designed for this called visudo and it has some logic built in where you can test the file. Just using printf or echo to append the file can risk some bad results.

Also, if there is really an issue with users being local admin then perhaps make them a standard user? Even look at some of the workflows people have built to issue temporary admin rights.

If your users are running removeframework I would also recommend engaging with them and asking them why they are removing it. It could be a very minor reason that IT could fix easily and you could just make them happy.

I suspect the users in this case are school-aged children who will break things simply for the fun of it.

Hi @tlarkin ,

Yes, I went ahead and used the visudo command to edit it. I started to try nano and noticed the comments in the file saying to use visudo.

For the most part, we haven't any other issues with them being local admins so we are deciding to leave it that way and try this first.

True @Emmert , these are high school aged students who just want to see what happens. It started with them being unhappy that the iMessage application was restricted from working through the Restrict Software ability. I believe that is why a couple removed the framework. None of the students will admit to doing it either.

For what it's worth I work in academia where it's a battle to remove admin access. About a year ago I noticed that anyone with admin access on a multi-user system could easily access data on mapped drives of another user that was logged onto the same system by getting root access. sudo was immediately disabled for everyone but the jamf management account.

A nod to Mr Trouton for the following link...

Editing /etc/sudoers to manage sudo rights for users and groups

Letting users have admin access is just playing with fire but sometimes it's difficult to impossible to change so minimizing the damage or just making it more difficult for the user to create issues is the next best thing. Disabling this a step in the right direction.