1

I've set up kerberos with NFS and it's working fine.

However there seems to be a problem with the way it works, any kerberos client seems to be able to access any directory (if they take the right ip)

On the NFS server (192.168.1.12):

$ exportfs -v
/data/mail 192.168.1.13(rw,wdelay,root_squash,no_subtree_check,mountpoint,sec=krb5,rw,secure,no_all_squash)
/data/web  192.168.1.14(rw,wdelay,root_squash,no_subtree_check,mountpoint,sec=krb5,rw,secure,no_all_squash)

I'm hosting mail and web on different servers. The idea is that if 1 gets compromised an attacker won't have access to the other.

So I've set up nfs and kerberos, so mail.example.com (.13) can mount /data/mail and web.example.com (.14) can mount /data/web and neither can mount the other. So far so good. However I then changed the IP on web.example.com to .13 and I was able to mount /data/mail.

This is what it looks like on the web.example.com:

ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2      nfs/web.example.com@example.com
   2    2      nfs/web.example.com@example.com

And on mail.example.com:

ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2     nfs/mail.example.com@example.com
   2    2     nfs/mail.example.com@example.com

This is what /etc/hosts looks like on the NFS server:

192.168.1.11 kdc.example.com
192.168.1.13 mail.example.com
192.168.1.14 web.example.com

I was expecting that since web.example.com has a ticket that identifies it as web.example.com, it wouldn't be able to mount /data/mail even if it took the ip of mail.example.com. It seems though that as long as you have any valid kerberos ticket and the right ip you can mount any directory. That kind of defeats the point of kerberos for me as this isn't a network I expect someone to plug into. Is that really the only threat that kerberos with NFS protects against or have I misconfigured something?

confused_nfs
  • 11
  • 2

1 Answers1

0

sec=krb5 doesn't stop any system will a valid ticket from mounting, but that's not it's job.

It will prevent access to files unauthorized clients (uid/gid based rather than ip). Assuming you having done a silly thing like make a root@EXAMPLE.COM, you may just need to tighten your file permissions.

Even with root_squash a remote root could change their euid to something with proper access as far as sec=sys is concerned. The same is not true for any of the krb5 options. Of course, this is all for not if the files/directories have permissions allowing others, e.g. 775 is going to allow reading, but 770 will not.

Side note: You ought to use at least use sec=krb5i, if not sec=krb5p.

84104
  • 12,698
  • 6
  • 43
  • 75