“Ooops.” — Me, doing something as admin that I didn’t mean to do.
While the sudo mechanism has some warranted criticism, it is still an improvement on doing everything as the root account. The essential addition that sudo provides for the average sys admin is the ability to only grant themselves system admin when they explicitly want it.
I was recently thinking about a FreeIPA based cluster where the users did not realize that they could get admin permissions by adding themselves to the user group admins. One Benefit to the centralized admin account is that a user has to chose to operate as admin to perform the operation. If a hacker gets the users password, they do not get admin. However, the number of attacks and weaknesses in this approach far outweigh the benefits. Multiple people need to know the password, revoking it for one revokes it for everyone, anyone can change the password, locking everyone else out, and so on.
We instead added a few key individuals to the admins group and changed the password on the admin account.
This heightened degree of security supports the audit trail. Now if someone performs and admin operation, we know which user did it. It involves enabling audit on the Directory Server (I need to learn how to do this!).
It got me thinking, though, if there was a mechanism like the sudo approach that we could implement for users to temporarily elevate them to admins status. Something like a short term group membership. The requirements, as I can see are these:
- A user has to chose to be admin: “admin-powers activate!”
- A user can downgrade back to non-admin at any point: “admin-powers activate!”
- Admin powers wear off. admin-powers only last an hour
- No new password has to be memorized for admin-powers
- The mechanism for admin-powers has to be resistant to attack.
- customizable enough that someone outside the organization can’t guess what they are.
- provide some way to prevent shoulder surfing.
I’m going to provide a straw-man here.
- A REST API protected via SPNEGO
- another endpoint with client cert possible, too
- The REST API is password protected with basic-auth. This is the group password.
- The IPA service running the web server has the ability to add anyone that is in the “potentaladmins” group to the “admins” groups”
- The IPA service also schedules an AT job to remove the user from the group. If an AT entry already exists, remove the older one, so a user can extend their window.
- A cron job runs each night to remove anyone from the admin group that does not have a current at job scheduled.
As I said, a strawman, but I think it points in the right direction. Thoughts?