A question was circulating in an internal discussion forum the other day, and based upon some feedback, it seemed like my response was helpful and might be worthy of a wider audience.
The question (parahprased)
I think we all know that UNIX users want access to the root account on their local machines (outside of sudo) but how does that work with Kerberos?
On NFS client systems, if the root user is just a non-Kerberos local user, is that a security loophole?
Is there a centralized (or standardized) approach to allow a root user in your Kerberos (AD/LDAP) environment?
What are other customers doing for root account access in their Kerberos environments?
I hope that made sense…
I’ve been musing on this one in the back of my head all day, so bear with me:
Let’s start with an abstract analogy. Do you ever leave home with just a wireless garage door opener and no physical key to your house? What happens if the house loses power when you’re out or if the batteries die in the garage door opener? I’m guessing there are no spare batteries in your glovebox?
The same concept applies to any client or server OS; there should always be a local way to get in the door. Windows has this with the local administrator account, with a well-known SID. Similarly Unix provides the root user with a UID and GID of 0.
How does it apply to Isilon?
The idea of providing root access to users over NFS implies that we want to disregard all access-checking on the Isilon file system, and hand over the keys. Given this, mapping root to root on NFS Exports is a really bad idea, except for a management workstation or two.
Another way of saying this is that root should always be squashed on exports. Why? Because as the original question alluded to, controlling who is root on a whole subnet of IPs is practically impossible. I could su to root on my Mac laptop, and I’d get in with root access to the data, assuming my IP is in a range with said access. How should you handle this in an NFS export on Isilon? Rather than mapping root to root, use the root clients list for those few IPs or hostnames that you want to give true root access to, and put everybody else into the R/W clients list with root mapped to the default of ‘nobody’.
In reality, Kerberos doesn’t really enter into the discussion here; root is and will always be a local account. Yes, it’s inherently insecure; therefore don’t give root access to exports unless absolutely necessary because keeping it away from users is far more difficult. In this way NFS is certainly less secure than Windows with Active Directory, because Local ‘Administrator’ and an AD Domain ‘Administrator’ are different SIDs, whereas the UNIX Local ‘root’ and NFS Server ‘root’ both have a UID of 0. Even if you could move root off to some other authentication provider such as AD, LDAP, NIS or MIT Kerberos, would it be a good idea?
I’ll leave that as a rhetorical question.
Please post feedback below. This is meant as a logical argument and not a definitive technical guide. What do you see in your environment?
Senior Solution Architect
EMC Isilon | Offer & Enablement Team
P.S. Some external references to back up the claims made above:
1. The Debian Handbook, Section 18.104.22.168, reference the section: "Caution: Broken Authentication"
2. Microsoft KB 243330: Well Known Security Identifiers (SIDs)
3. Ubuntu Help Pages, reference the section "Downsides of using Sudo"