Yes. You hit on the fundamental flaw of NFSv3 and below. Your server has to trust the machines that exported filesystems are mounted on. One of the goals of NFSv4 is to fix these security issues. With NFSv4, which is included with Red Hat Enterprise 4, you can require kerberos security in order to access files. This means that the server will not let you access files that you don't have access to, unless you authenticate to kerberos first. In other words, if you su to a user, but don't kinit as that user, you will not have access to that users files. This also requires you to deny SYSTEM-level authentication, besides having to setup your users for kerberos authentication. Documentation on NFSv4 is somewhat slim right now, but you can look at the following websites for info: http://playground.sun.com/pub/nfsv4/webpage/ http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html http://www.citi.umich.edu/projects/nfsv4/linux/ --James Cooley > On Thu, Jun 30, 2005 at 05:25:03PM -0400, Ryan Golhar wrote: >> But what if someone just enters in an ip address on their laptop to be >> the same as the machine they unplugged...then limiting dhcp to known mac >> addresses doesn't work. >> >> I use this to control who my dhcp server gives ip addresses out to, but >> that doesn't stop anyone from setting the ip address on their own >> laptops... > > About 15 years ago I had a lengthy discussion with one of the leading > security experts at the time. He said that NFS simply stands for "Not > F*ing Secure". The protocol depends on the server trusting the client > not to lie to it. In a hostile environment, you're out of luck unless > things have drastically changed over time. > > It's cases like this where Microsoft actually has a more secure solution > by forcing a workstation to enter a domain administrator's credentials > before joining a domain... Of course, you shouldn't do this with an > untrusted laptop since some bad student could give you his laptop with a > keystroke capture utility nicely installed. > > In a hostile environment, you can't trust the IP address nor the Mac > address. That means that you have to physically control the ports that > somebody can plug into and verify them that way, or force the user to > enter some other set of credentials to authenticate. > > .../Ed > >> -----Original Message----- >> From: redhat-list-bounces@xxxxxxxxxx >> [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Chiu, PCM (Peter) >> Sent: Thursday, June 30, 2005 3:11 AM >> To: General Red Hat Linux discussion list >> Cc: Chiu, PCM (Peter) >> Subject: RE: NIS/NFS question >> >> >> I suppose a similar approach with iptables, is to >> enforce DHCP to known MAC addresses. >> >> Peter >> >> -----Original Message----- >> From: redhat-list-bounces@xxxxxxxxxx >> [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Wayne Pinette >> Sent: 29 June 2005 22:37 >> To: redhat-list@xxxxxxxxxx >> Subject: NIS/NFS question >> >> >> I have a question regarding NIS and was wondering if anyone had any >> ideas. >> >> We are creating a Linux workstation lab for students. We have a central >> linux box which teh students can ssh into from home. The lab is a place >> where they can log in and work on their work. We are using NIS to >> authenticate the workstations and we are nfs mounting the /home >> directory. This is all pretty standard and make sense. Here is the >> problem : >> >> If a student walks into the lab with their laptop running their >> favourite linux to which they have root access, unplugs a workstation, >> plugs in their laptop, hardcodes the worksation's ip, sets ups his >> laptop to nis authenticate and nfs share just like the workstation, logs >> in as root, he can now su to any student id on the system. >> Although I quash root on the nfs share, it does not stop this student >> from getting access to any other students (or instructors) material on >> the server. Although my nis server only trusts a small list of >> ip addresses, it's trust is still only based on ip. Is there a way to >> add some sort of certificate trust to nis or some other mechanism to >> check against before nis will trust a machine on it network other than >> just ip? >> >> Wayner > > -- > Ed Wilts, RHCE > Mounds View, MN, USA > mailto:ewilts@xxxxxxxxxx > Member #1, Red Hat Community Ambassador Program > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
