FreeIPA: prevent local root accessing user accounts

So after asking this question, I've been test-driving FreeIPA as a central authentication source based on this question: Managing access to multiple linux system

One problem I ran into is that if a user is given local root permissions, they can in turn login as any user in the FreeIPA directory. Even if that users doesn't have access to that particular machine via HBAC rules.

Sample scenario:

• FreeIPA client machine PC1.
• Two users in FreeIPA: Bob and Alice.
• Alice is not allowed to access PC1 via HBAC rules. Bob has local root on PC1. Bob can su to become Alice on PC1.

The only info I can find refers to commenting out this line in /etc/pam.d/su:

auth            sufficient      pam_rootok.so

Which now asks local root for Alice's password if he tries to:su alice

However, if Bob has root access he can just as easily enable the above PAM/su line. Shouldn't FreeIPA prevent Alice's account from ever accessing PC1 whether it's via direct login attemp or local root su-ing? How does one prevent local roots from being able to login as any FreeIPA user?

Solution 1:

I would classify this as a 'security exploit' between the relationship of the Linux 'client' system(s) and FreeIPA. Though not necessarily a 'bug' it DOES expand the local root accounts ability beyond that of the local O/S instance (which it should 'not').

The repetitive statements that this issue is all about UNIX and how it works is incorrect. Though a 'root' account has the ability to create a localized version of any account ID and 'su' to it, the use of FreeIPA permits the local root account to obtain and access resources existing externally to the local instance (though specifically configured 'not' to be available to it).

That IS an issue with the FreeIPA implementation, permitting the local "root" account to escape its boundaries...

Solution 2:

Please check Simo Sorce's answer in a related Bugzilla, it pretty nicely summarizes Linux security model and what you can or cannot do as a local root:

Hi Swartz, the root account on any linux machine is all powerful and can do anything it wants, it can even create local users and impersonate them w/o issue.

I suggest you take the time to understand what is the security model on Linux and what the root account can do (anything, including modifying the running kernel).

In any case a compromised machine cannot really do anything more, in a IPA environment, than what it can do in any other environment.

Unless the compromised machine steals actually active credentials it cannot influence other machines unless you are using insecure services that implictly trust any client.

In the NFS case for example root-squash is really not something you can trust any security upon, if you are concerned about access to NFS services you need to run NFS with sec=krb5, where each user access is authenticated via kerberos credentials.

If you are interested in a way to confine what users (including root) can do I suggest you read up on SELinux and capabilities and how to confine users of all kinds.

I am going to close this as NOTABUG, because there is nothing unaccounted for in what you are describing in the report, this is all known stuff.

Solution 3:

Ok, if your user is local "root" on that machine he can do anything on that machine. Blocking "su -" would not really prevent anything. "su -" trumps everything, it is inherently local.

For something you want to accomplish you need to design your HBAC rules against service called 'su-'. The main thing here is no user account should have local root on the boxes.

Hope this helps.