Deliberate Elevation of Privileges

“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:

  1. A user has to chose to be admin:  “admin-powers activate!”
  2. A user can downgrade back to non-admin at any point: “admin-powers activate!”
  3. Admin powers wear off.  admin-powers only last an hour
  4. No new password has to be memorized for admin-powers
  5. The mechanism for admin-powers has to be resistant to attack.
    1. customizable enough that someone outside the organization can’t guess what they are.
    2. 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?

6 thoughts on “Deliberate Elevation of Privileges

  1. Maybe using another Kerberos credential cache (KRB5CCNAME), a script can do something like

    1- Point KRB5CCNAME to a ram file
    2- run kinit to the real admin user (probably with a second account for them, with admin privileges.
    3- run the commands requested
    4- remove the credential cache file

    The only downside is there is the need for two users per administrator, one for normal usage and one for admin operations. A 389 server plugin maybe can help to keep them in sync

  2. At work we do something similar (with a commercial product):
    – The user requests “add me to the tmproot group” and a reason why it is needed.
    – A workflow with manager/admin approval starts.
    – After the approval the user is added to the tmproot group and needs to relogin.
    – Now the user is allowed to run “sudo su -” and does the work.
    – The group is removed after 14 days.

    Works fine for us. I (dis)like the approval part – it’s needed here.
    It some kind of workflow something that FreeIPA should provide?

    14 day seems rather long – we’d like to have the option to give the elevated rights early.

  3. I started off there, but then realized that, if users in the potentialadmins group can add and remove themselves from the admins group, you get the same thing with a single credential.

  4. That also does not remove the ability during those 2 weeks when the user is not doing admin type operations. But I like that you have something working. It is a start.

  5. A modified TGS service that you need to explicitly reach out via a command could work.
    This TGS service would release to you a ticket for the request service that is actually a ticket for the user admin@REALM (or what you want).
    Alternatively it could give you a whole krbtgt in the name of the admin@REALM user if you want to allow it to be used against any service.

    The TGT would have a short expiration time and be given only if your own principal has the special priovilege to request it.

    It’s all audited via this TGS service, and does not require special actions and modifications in the target services.

  6. Simo, That sounds like a decent idea. I’d like to add a few thoughts:

    The service ticket you request should be something specific to the host, and maintain the identity of the requestor:

    user@root@HOSTNAME@REALM
    (yes I know that is ugly, sorry)

    and that is what is used to grant the user elevated privs.

    I’d probably suggest that this can only be done using OTP, in order to limit the surface of attack as well.

Leave a Reply

Your email address will not be published. Required fields are marked *