6

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?

Community
  • 1
Swartz
  • 294
  • 5
  • 14
  • This strongly suggests that you've given someone root access who should not have it to begin with. Rather than try to lock down the root user (you can't) you should instead grant the non-root user the proper access. – Michael Hampton Apr 05 '15 at 04:24

4 Answers4

3

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.

Martin Kosek
  • 386
  • 1
  • 3
2

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.

Danila Ladner
  • 5,241
  • 21
  • 30
  • 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 '14 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 '14 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 '14 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 '14 at 05:51
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...

Yubby McFly
  • 26
  • 1
  • Note that FreeIPA does not give you any right to 'escalate' anything as root. You are root already, you have all control over the machine. However, this doesn't give you any right to access any other resources outside of the machine as any user in FreeIPA. In order to do that, you have to actually authenticate as that user to an external resource and you have no credentials to perform such authentication. – abbra Feb 17 '15 at 19:08
0

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

auth       required    pam_localuser.so
Florin Asăvoaie
  • 6,932
  • 22
  • 35
  • But, as local root, I can just as easily edit this out and we're back to square one. – Swartz Apr 29 '14 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 Asăvoaie Apr 29 '14 at 20:25
  • 1
    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 '14 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 Asăvoaie Apr 29 '14 at 20:42
  • Also, you may also be able to do some enhancements on this side with SELinux. – Florin Asăvoaie Apr 29 '14 at 20:43
  • A local admin on a Windows box SHOULD NEVER be able to become any domain user they like especially not a domain admin. This is a basic policy that any AD admin would implement and enforce. I have no choice with FreeIPA in this regard it appears. – Swartz Apr 29 '14 at 21:10
  • 1
    By same token any SELinux policies made on a machine can be undone by local root on that box. Hence, this issue is about FreeIPA. I stress again, NFS has root_squash specifically to counter scenarios similar to this. – Swartz Apr 29 '14 at 21:14