Real Authentication in NFS
I get asked a lot about what can be done to prevent the following:
What is happening is that user jim has set the permissions on his data to 0700 meaning only he, the owner, should get access. But someone on the NFS client with knowledge of the super-user password can become root (user id 0), and then become jim and circumvent jim's protections. The reason why this works is that the NFS server is accepting AUTH_SYS credentials, which are basically, a user id, and 1 to 17 group ids. Simply su'ing to jim causes the NFS client in the kernel to pick up jim's user id and group ids.
Some people have suggested if a more secure directory service like LDAP is used, especially if its configured to use Kerberos V5 authentication, that this is providing Kerberos authentication and so will defeat the attack. No, that is not the case. All that does is make sure the user using LDAP is authenticated via Kerberos (and the LDAP server is authenticated to the user via Kerberos). While this is a good thing, it does absolutely nothing to prevent the scenario above.
The only thing today that prevents the scenario is to use Kerberos V5 (or some other strong authentication system, but Kerberos V5 is what most vendors have) authentication in the NFS traffic itself. This means exporting the volume with option sec=krb5 (or krb5i, or krb5p), and without anon=0 and without root=.
What happens is that even if the attacker su'es to jim, unless he knows jim's Kerberos password, he cannot become user jim over the NFS connection. Even attempting to access /home/jim as super-user, even with Kerberos credentials for super-user, is defeated, because super-user, uid 0, will be mapped to user nobody (since anon=0 and root= are absent in the export options).
Restricting access knowledge of the super-user password, while an excellent practice, is no panacea either. This is because synthetic, user-level NFS clients aren't rocket science to write, and they can be written so that any uid can be specified in the AUTH_SYS credential. There are "nfs shell" programs out there for anyone to download. While the one I've tried isn't written to allow arbitrary user ids to be inserted into the credentials of the NFS requests, it wouldn't be hard to change it.
You might find the following links interesting:
nfs client% cd /home/jim
/home/jim: Permission denied
nfs client% ls -ld /home/jim
drwx------ 2 jim grp1 117 Feb 24 07:48 /home/jim/
nfs client% su
Password:
nfs client# su jim
nfs client% cd /home/jim
/home/jim
What is happening is that user jim has set the permissions on his data to 0700 meaning only he, the owner, should get access. But someone on the NFS client with knowledge of the super-user password can become root (user id 0), and then become jim and circumvent jim's protections. The reason why this works is that the NFS server is accepting AUTH_SYS credentials, which are basically, a user id, and 1 to 17 group ids. Simply su'ing to jim causes the NFS client in the kernel to pick up jim's user id and group ids.
Some people have suggested if a more secure directory service like LDAP is used, especially if its configured to use Kerberos V5 authentication, that this is providing Kerberos authentication and so will defeat the attack. No, that is not the case. All that does is make sure the user using LDAP is authenticated via Kerberos (and the LDAP server is authenticated to the user via Kerberos). While this is a good thing, it does absolutely nothing to prevent the scenario above.
The only thing today that prevents the scenario is to use Kerberos V5 (or some other strong authentication system, but Kerberos V5 is what most vendors have) authentication in the NFS traffic itself. This means exporting the volume with option sec=krb5 (or krb5i, or krb5p), and without anon=0 and without root=.
What happens is that even if the attacker su'es to jim, unless he knows jim's Kerberos password, he cannot become user jim over the NFS connection. Even attempting to access /home/jim as super-user, even with Kerberos credentials for super-user, is defeated, because super-user, uid 0, will be mapped to user nobody (since anon=0 and root= are absent in the export options).
Restricting access knowledge of the super-user password, while an excellent practice, is no panacea either. This is because synthetic, user-level NFS clients aren't rocket science to write, and they can be written so that any uid can be specified in the AUTH_SYS credential. There are "nfs shell" programs out there for anyone to download. While the one I've tried isn't written to allow arbitrary user ids to be inserted into the credentials of the NFS requests, it wouldn't be hard to change it.
You might find the following links interesting:
posted by Mike Eisler at 2/24/2006 07:44:00 AM
14 Comments:
One thing that has me confused about NetApp's Kerberos support is the keytab creation. What encryption types should be used to build the keytab? Also, does NetApp require a root principle like Solaris did prior to 10?
Thanks Mike!
P.S., very informative blog!
> What encryption types should be used to build the keytab?
ONTAP's NFS server supports des-cbc-md5. If using an MIT KDC that supports other types, do the following:
# kadmin.local
kadmin.local: ank -e des-cbc-md5:normal -randkey nfs/filer.lab.netapp.com
kadmin.local: xst -k /tmp/filer.keytab -e des-cbc-md5:normal nfs/filer.lab.netapp.com
> Also, does NetApp require a root principle like Solaris did prior to 10?
Actually even prior to Solaris 10, the Solaris NFS server would allow an NFSv3 mount if root didn't have Kerberos credentials. ONTAP is the same way. However, if using NFSv4, because NFSv4 has no separate mount protocol, an NFSv4 server cannot distinguish a mount from a LOOKUP. If a volume is exported with sec=krb5, then the NFSv4 requests need to be using Kerberos. Since UNIX clients usually require one to be superuser to do an NFS mount, superuser (root) needs to have credentials. Root credentials aren't required, but whatever uid the credentials map to has to have search permissions for the path name.
Hi Mike
I'm having a problem with linux client and Netapp server. The root doesn't have access to files owned by "root" when using kerberos.. The exported volume has anon=0, and without kerberos the mapping works. On the client root does not have nfs-principal listed, only krbtgt.
What's wrong here?
I'm having a problem with linux client and Netapp server. The root doesn't have access to files owned by "root" when using kerberos.. The exported volume has anon=0, and without kerberos the mapping works. On the client root does not have nfs-principal listed, only krbtgt.
It's hard to say what is going on. Does klist show an nfs service ticket? What principal does klist show?
actually, root doesn't get any principal even when mounting with krb5... this is driving me crazy, I'd assume this to be automatic :)
I can run 'kinit -k' to get the host-principal, but after that I'm stuck.
ok, tried with solaris10-client, and it works there. It seems that root user doesn't get a root/host@REALM principal on linux, so the fault is in the linux-tools.
ok, tried with solaris10-client, and it works there. It seems that root
I would expect Solaris to work. :-)
user doesn't get a root/host@REALM principal on linux, so the fault is in the linux-tools.
I strongly suggest you subscribe to
the Linux NFSv4 mailing list
(see http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 ) and post details about your problem on that list.
yes, I've been on that list for some time now, and the problem has been reported earlier today ;)
Unless, of course, the user you're su'ing to already has a credential cache on that machine. I guess that the OS-X way of in-memory caches is the way to go :)
Unless, of course, the user you're su'ing to already has a credential cache on that machine.
Niall,
Certainly one can do things in the operating system to make it more difficult. For example, one could assign the Kerberos credentials to a process group, which then makes it impossible for a simple "su" command to use someone else's Kerberos credentials. You allude that OSX apparently puts Kerberos creds in memory. These sorts of things don't make it impossible for an attacker, but merely make it more difficult.
Once you give the cleverest attacker physical access or super user access (and the former basically leads to the latter) to a machine you are using, all bets are off. With super-user access I could probe the kernel for any in-kernel credentials and copy them to the super-user's in-kernel credentials. With super-user access I could replace the kinit program with one that captures the Kerberos passwords the user types.
The bottom line is that you have to manage your credentials the same way you manage your bank ATM card, including being wary of using your card with unfamiliar ATMs. The conventional implementation of Kerberized NFS on NFS clients is a major leap in difficulty being presented to the attacker. If the user sticks to clients he has reason to believe are safe, he has much less chance of being compromised than he does with AUTH_SYS, which doesn't require the legitimate user to log into the machine the attacker is launching his attack from.
I am having trouble using nfsv4 and krb5 with a Netapp server and an AIX client. The mount command (using sec=krb5,vers=4) succeeds and results in an nfs/server@realm principal being added on the client. However when I try to access the mounted filesystem I get a permission denied error. A packet trace shows that an RPC request is being denied by the server:
Reject State: AUTH_ERROR (1)
Auth State: client must begin new session (2)
I also don't see any kerberos traffic going over the wire. In particular I never see the Netapp try to contact the KDC. I suspect there is a problem with the krb5.conf or keytab file on the server, but its not clear to me how to confirm this. I have verified that I can use the keytab to obtain credentials for the nfs principal on another host. 'nfs setup' ran without problems on the filer and nothing bad is showing up in the logs. The AIX client can mount and access an NFS filesystem on a Linux server using nfsv4 and krb5 with no problems, so I think things are configured correctly on the client side. Any insight you can share would be appreciated.
Thanks
I am having trouble using nfsv4 and krb5 with a Netapp server and an AIX client.
I'm sorry to hear that.
There's not much to go on here. Knowing the ONTAP version you are
running might help me help you. That said, I would try NFSv3 over Kerberos first just to try eliminate a variable. If you find that succeeds, then to ket NFSv4 to work, make sure that the NFS export
restrictions on the top level exports are a superset of the export restrictions on the path you are mounting. For example, if you have /vol/vol0 exported with sec=sys, /vol/vol0/home exported with sec=krb5, and you are trying to mount /vol/vol0/home/stuff, then NFSv4 clients won't be able to mount. Instead specify sec=sys:krb5 on /vol/vol0.
If switching to NFSv3 makes no difference, then some things to look at include:
- are the clocks on the KDC, NFS server and NFS client in synch?
- What is the value of the nfs.rpcsec.ctx.idle option? Some NFS clients don't cope with NFS servers deleting Kerberos contexts that have gone idle. New versions of ONTAP are less aggressive about clearing idle contexts.
- are you using single DES when you create and extract the nfs/ Kerberos V5 principal? (If you are using AD as your KDC, this will happen automatically).
Mike,
Thanks for your reply.
Knowing the ONTAP version you are running might help me help you.
I am running version 7.1.
That said, I would try NFSv3 over Kerberos first just to try eliminate a variable.
Using NFSv3 and sec=krb5 the mount fails with a permission denied error. Using NFSv3 or NFSv4 and sec=sys the mount suceeds.
Instead specify sec=sys:krb5 on /vol/vol0.
That is what I have specified. Note:
rsh server exportfs -c client /vol/vol0 root krb5
exportfs: client has root access to /vol/vol0
rsh server exportfs -c client /vol/vol0/nfsv4test root krb5
exportfs: client has root access to /vol/vol0/nfsv4test
rw access checks out similarly.
If switching to NFSv3 makes no difference, then some things to look at include:
- are the clocks on the KDC, NFS server and NFS client in synch?
Yes, using ntp.
- What is the value of the nfs.rpcsec.ctx.idle option?
360
- are you using single DES when you create and extract the nfs/ Kerberos V5 principal? (If you are using AD as your KDC, this will happen automatically).
Yes, the encryption type is des-cbc-crc, although I am using a UNIX KDC.
The thing that most troubles me is that packet traces never show any traffic between the filer and the KDC, either when 'nfs setup' is run, or when a client attempts an access or mount. Therefore I suspect a problem with the krb5.conf. This is what my krb5.conf look like:
[libdefaults]
default_realm = EXAMPLE.COM
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
default_keytab_name = /etc/krb5.keytab
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com:88
}
[domain_realm]
.example.com = EXAMPLE.COM
And my /etc/exports:
/vol/vol0 -sec=krb5:sys,rw=client.example.com,root=client.example.com,anon=0
/vol/vol0/nfsv4test -sec=krb5:sys,rw=client.example.com,root=client.example.com,anon=0
- are the clocks on the KDC, NFS server and NFS client in synch?
Yes, using ntp.
Humor me and make sure the
clocks are all with a few seconds
of each other by running the
date command.
Since you are running ONTAP 7.1,
the bug I was thinking of should be
fixed. Nonetheless, try upping
nfs.rpcsec.ctx.idle to 3600 and
nfs.rpcsec.ctx.high to 1024.
Yes, the encryption type is des-cbc-crc, although I am using a UNIX KDC.
You extracted the nfs server
principal into the keytab as:
xst -k /tmp/filer.keytab -e des-cbc-md5:normal nfs/filer.example.com
?
The thing that most troubles me is that packet traces never show any traffic between the filer and the KDC, either when 'nfs setup' is run, or when a client attempts an access or mount. Therefore I suspect a
When using an MIT KDC this is
expected. The Kerberos authentication protocol doesn't require a Kerberized server to
talk to the KDC. The ticket
the client gets from the KDC and
sends to the NFS server has
information encrypted with the
server's key. If the server can
successfully decrypt it, that
authenticates the client.
If none of my ideas pan out,
then I suggest you
open a case with NetApp Global
Support.
<< Home