FreeIPA: setting polkit / PolicyKit rules for users (make your user a polkit administrator on your clients)

Yup, it’s another FreeIPA post!

One thing you might notice if you move your main user account to FreeIPA is that your client systems don’t consider the user to be an ‘administrator’ for polkit (formerly known as PolicyKit) purposes. That is, when you run anything that uses PolicyKit for privilege escalation, you are prompted for the root password, not your user’s password.

By default, PolicyKit considers all members of the ‘wheel’ user group to be administrators. We can see this in /etc/polkit-1/rules.d/50-default.rules:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});

If your user is managed exclusively in FreeIPA, they’re unlikely to be considered a member of the local system ‘wheel’ group. My first attempt to fix this involved creating a sort of clone of the ‘wheel’ group on my FreeIPA server and adding my account to that. This exposed a couple of interesting bugs in polkit but also caused the FreeIPA and polkit devs to break out words like ‘completely wrong’ and ‘idiot’, so I don’t do that any more. The ‘right’ way to do it is to create a new group on the FreeIPA server which isn’t trying to shadow/copy/override a group on the clients. I called mine ‘sysadmins’ and let FreeIPA generate one of its extremely high GIDs for it. Add all the user accounts you want to have admin privileges on your client machines to this group.

Then you add a file to /etc/polkit-1/rules.d on all your clients which will be evaluated before 50-default.rules (this is very important – polkit’s behaviour is that it evaluates addAdminRule() functions in order until one returns a valid result and then ignores the others, so if your rules file comes after 50-default.rules, it will never take effect) which tells polkit to treat users of that group as administrators instead:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:sysadmins"];
});

I called mine /etc/polkit-1/rules.d/40-happyassassin.rules, following my own naming policy, but so long as it comes before 50-default.rules you’ll be fine. Now any user in the FreeIPA-managed ‘sysadmins’ group will be considered an admin user by polkit on all systems with that rules file. You can of course use the same group for FreeIPA sudo rules, and then sudo and polkit admin privileges will be managed together.

You could tweak the rules file as you like, of course, and do other stuff with the mechanism. If you have a hybrid setup and you also want users in the local system’s wheel group to be considered admins, you’d want the rule to return ["unix-group:sysadmins", "unix-group:wheel"] (I think that’s the syntax, anyway). You can set up PolicyKit rules files to grant all sorts of privileges in different cases to different FreeIPA-managed user or group accounts; just remember that it’s a bad idea to have collisions between group names and GIDs in FreeIPA and on your local systems, keep them separate.

Of course in a properly-managed domain you’d want to use ansible or Puppet or whatever to distribute the rules file to clients when they’re set up.

5 Responses

  1. Amir Hedayaty
    Amir Hedayaty September 13, 2014 at 11:29 am | | Reply

    I was recently setting up FreeIPA for a friend for a lab around 10 computers.
    Overall, FreeIPA is something I would still recommend. It made the kerberos and
    LDAP so easy to set up. However, I have some question/suggestion.

    First, I would like to ask about possiblity of having different sysadmin group per host.
    What I would like to see is having a different sudoer on different hosts and
    similarly policykit configured giving permission to different users per hosts.

    Second, NFS. It is something which seems esntial for a accounting system.
    However, it should be configured independently.

    Third, FreeIPA does some help with setting up automount for NFS; however, if domainname and realm
    are different. It will create buggy configuration.

    1. Amir Hedayaty
      Amir Hedayaty September 13, 2014 at 11:49 am | | Reply

      Forgot to mention, another feature is NIS like printer sharing

  2. Amir Hedayaty
    Amir Hedayaty September 13, 2014 at 5:01 pm | | Reply

    It was not my first experieced I had some experience with LDAP/NIS. Eventually made them all work.

    I am telling you like a feedback from a comunity member to someone whose voice might be heard for the roadmap.
    Reporting bug on doain vs realm issue might help. But I do not see a better way to express about printer/NFS/policy.

    I like to see the IPA in a state which I can recommend it as a real replaement for AD.

  3. D Jons
    D Jons February 12, 2015 at 5:48 pm | | Reply

    Personally, I think it’s kind of pointless to have both sudo and policykit managing user privileges. It just ends up being another thing that wastes countless hours for users and admins trying to figure out why it doesn’t work. It also makes it more difficult to manage access controls centrally.

    In theory, having multiple security methods adds layers and makes systems more secure. In practice, however, it just makes it more confusing for admins to configure, and much more likely that they’ll do it wrong.

    What all too often ends up happening is they just disable everything they can, rather than spending the time to learn how to use all the different access controls. For examaple, it’s become almost standard practice to immediately disable SELinux. The concept of it is great, but the reality can get quite painful.

Leave a Reply

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