Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So after asking this question, I've been test-driving FreeIPA as a central authentication source. 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?

Thanks.

share|improve this question

3 Answers 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.

share|improve this answer
    
Yes, that's exactly my point. Local root can do anything. So question is how does one effectively block local roots (on client systems) from becoming any FreeIPA user they want? I have HBAC rules on FreeIPA server that completely prevent Alice from accessing PC1 (regardless of service). Yet local root on PC1 can become any FreeIPA user (including Alice) thereby bypassing server HBAC rule (wtf?). Shortcoming in FreeIPA? This seems like a a typical scenario encountered in the wild where you sometime need to give root access to a system. –  Swartz Apr 29 at 18:19
    
You can't. Period. Root can largely do what it like, that is why it is root. And i do not think it is a shortcoming, it that is how nix systems has been designed. –  Danila Ladner Apr 29 at 18:48
    
Ok. I can't do anything on local box since root is omnipotent and could revert any changes. However FreeIPA (server) has HBAC rule preventing Alice from ever using PC1. So local root (not FreeIPA server root) pretty much bypasses any access control on the FreeIPA server. As an example, NFS has root squash just for scenarios like this so that local root can't willy-nilly access network shares. Seems like a shortcoming in FreeIPA to me. –  Swartz Apr 29 at 20:29
2  
@Swartz root can do anything on the local machine, and if you have physical access to the machine, you can become root. What you should look out for is what root can do to other machines on the network and restrict that by proper configuration of those other nodes. The root squash feature of NFS is an example of a setting which is not effective for that purpose, but it does help in some other scenarios. –  kasperd Apr 30 at 5:51

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.

share|improve this answer

You would have to put this in /etc/pam.d/su and /etc/pam.d/runuser:

auth       required    pam_localuser.so
share|improve this answer
    
But, as local root, I can just as easily edit this out and we're back to square one. –  Swartz Apr 29 at 18:14
    
Right, but this is just what it is, no other option. Maybe just make your root filesystem read-only :). root can basically do anything, that's why I always prefer that I give users sudo access but no "sudo su -", just the ability to run the commands that they need with sudo. –  Florin Asavoaie Apr 29 at 20:25
    
I guess time to make a bug-report (or feature request). I see this a huge shortcoming in FreeIPA. Basically local root can effectively undermine the entire FreeIPA security policy. One compromised box -> all accounts are compromised. Huge security vulnerability. –  Swartz Apr 29 at 20:35
    
This is not about FreeIPA. This is all about Unix and how it works. Actually, it's all about any Operating System. If local Administrator is compromised on a Windows PC, then it can take it out of the Domain and do whatever. Also, not all accounts are compromised, you can just execute stuff as other accounts, so can you in Windows... –  Florin Asavoaie Apr 29 at 20:42
    
Also, you may also be able to do some enhancements on this side with SELinux. –  Florin Asavoaie Apr 29 at 20:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.