WIP: timeout all uses of Privileges

[mnestor]

This is not really the best solution for this but might be a good starting point. The thought here is to always timeout the elevation instead of leaving it until the user remove it or they login again.

I'm sure the community at large and even SAP has a better idea on how to implement this.

[grahampugh]

I would love this to be implemented. At present I have a script that users run from Jamf Pro Self Service to elevate them for a specified time, but the problem with using scripts or LaunchAgents is that the timeout can be altered by the user while they are elevated. Only a config profile can truly prevent that.

We can set the toggle time via config profile, so another option could be to disable the non-toggle option. Having a PrivilegesCLI --toggle switch to emulate the GUI operation would also be helpful so that the timeout value in the profile could be enforced.

[wmehilos]

Seconding the hope of having this implemented soon rather than fumbling around trying to merge the changes in my local clone (which, this being 10 commits behind master isn't straightforward). Stuck between a rock and a hard place, I need the justification logging the GUI gets me, but I need auto timeout too, and the only easy way of doing that on my own would be using some Self Service trickery which isn't going to let me use the GUI (rather not present a terminal window to users).

[grahampugh]

@wmehilos I had to do exactly what you're trying to avoid. I use this script in a Self Service policy, with a separate Trigger-only policy to install Privileges from the script if not already installed. Parameter 4 is the number of minutes you want the elevation to last. I add the LaunchAgent in case people logout/restart before their time is up:

#!/bin/bash

# Sets admin privileges for defined number of minutes
duration_minutes=$4

elevation_duration=$(($duration_minutes * 60))
start_interval=$(($elevation_duration + 10))

# get console user so we can run the script as that user
consoleuser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }')

abort() {
  printf "%s\n" "$@"
  exit 1
}

have_sudo_access() {
  if [[ $(whoami) != "root" ]]; then
    abort "Need sudo access!"
  fi
}

# check sudo access - will abort if not running as sudo
have_sudo_access

# is the Privileges app installed?
[[ -d "/Applications/Privileges.app" ]] || /usr/local/jamf/bin/jamf policy -event Privileges-install

sleep 1

# Write script to tmp location
tmp_location="/tmp/privileges"

echo "#!/bin/bash
su -l $consoleuser -c \"/Applications/Privileges.app/Contents/Resources/PrivilegesCLI --add\"

# now wait for the designated number of minutes
sleep $elevation_duration

# now remove privileges
su -l $consoleuser -c \"/Applications/Privileges.app/Contents/Resources/PrivilegesCLI --remove\"

# finally delete this file
rm -f $tmp_location
" > "$tmp_location"

chmod 775 "$tmp_location"

echo "Runner written to $tmp_location"

# now run the script in the background so the jamf policy can end
"$tmp_location" &

# write the LaunchAgent that ensures privileges are returned to standard on login
LaunchAgentLocation="/Library/LaunchAgents/corp.sap.privileges.plist"

echo '<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>corp.sap.privileges</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/Privileges.app/Contents/Resources/PrivilegesCLI</string>
        <string>--remove</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>LimitLoadToSessionType</key>
    <string>Aqua</string>
</dict>
</plist>' > "$LaunchAgentLocation"

launchctl load -w "$LaunchAgentLocation"

exit 0

It doesn't prevent users manually running the Privileges app. You might be able to achieve that with a Software Restriction. But as you say, I'd prefer not to have to engineer around what seems to be an obvious need.

[mjsanders]

I second this request too. We currently deploy Privileges with the launchd that makes all users by default non-admin, and run a periodic script to ask the user if admin rights are still needed. I think for most users the behaviour should be this: -click on dock icon: toggle admin rights for XX minutes (default 20 minutes, manageable with MDM) -option-click : possibility to get admin rights for undefined time (till logout) The option-clink will be found and used by those who require it (like developers), the toggle will be the default what is best for most users, that need to do one task (installing software, changing some setting) and XX minutes is all they need.

[CLAassistant]

All committers have signed the CLA.

[mnestor]

I wouldn't merge this, the code is sloppy and most likely wrong. I've also found the timeout isn't working that often or resetting the icon like it should.

[Rastafabisch]

I'm not sure if this would actually be related, but I just came across a kind of fundamental flaw enabling users to receive permanent privileges after one input the password, even when it's set for some minutes only. You just need to reboot the computer in the meantime (or possibly just kill the background task).

I think this could be mitigated by having two background tasks, and as one is killed (even by the OS during reboot) the other would directly lock the privileges again.

If this is a new issue feel free to move this post.

[PeetMcK]

My fingers are crossed that this is on SAP's ToDo list, but in the mean time I've written an admittedly simple little package that has been working very well across my Privileges-enabled computers - RevokePrivileges ... basically a LaunchDaemon that watches /var/db/dslocal/nodes/Default/groups/admin.plist for changes, a LoginWindow-only LaunchAgent to revoke privileges on logout or restart, and a little bash script that fairly aggressively cleans all but root and user 501 from the admin group (and keeps any usernames as admin that are added to an array). It even checks if a user that changed their PrimaryGroupID to 80 and sets it back to 20. And checks for an enabled root account and disables it by deleting AuthenticationAuthority from the record and soothes my OCD by changing Password back to *.

@Rastafabisch having a LoginWindow-only LaunchAgent that revokes privileges handles the scenarios your describing pretty well. Not perfect, but short of Apple building a mechanism, with 10 minutes of full admin there's little you could do to stop anything malicious.

[rtrouton]

Closing PR as new version of Privileges has been released.