I would expect the exports option of root_squash or all_squash should block all root access. But as your students are "clever" enough to fake hardware addresses, shouldn't you separate their home filestores from that of their tutors' into different servers, assuming the tutors are not using the same room to plug their laptops/desktops. Peter -----Original Message----- From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Jurvis LaSalle Sent: 30 June 2005 12:48 To: golharam@xxxxxxxxx; General Red Hat Linux discussion list Subject: Re: NIS/NFS question On Jun 29, 2005, at 9:28 PM, Ryan Golhar wrote: > Hi Wayne, > > We have actually done exactly what you are doing. We've since > switched to LDAP to encrypt passwords sent over the wire. But the > problem you are referring to is the same we have now. I wouldn't have > enough thought of it if you didn't mention it. > > I believe you can use iptables with --mac-source to control access by > MAC address. > > Right now, we only allow our linux machines to nfs mount /home on the > server by iptables: > > -A ADDRESS-FILTER -s xxx.xxx.xxx.xxx -j ACCEPT > > Making it > > -A ADDRESS-FILTER -s xxx.xxx.xxx.xxx --mac-source XX:XX:XX:XX:XX:XX -j > ACCEPT > > Should do the trick. Let me know what happens and what you decide to > do... > > Ryan > Hi, I have a very similar lab setup using NIS and NFS. I've pondered these scenarios as well and I came to the conclusion that the MAC address is not a saving grace. While the network here is switched and the dhcp server does reserve IP addresses for specific MAC addresses (until the spare IP pool is exhausted anyway), any student with an account in the lab can use arp or ifconfig to figure out the MAC addresses. Sure you can chmod 550 any of the half dozen utilities that will spit out MAC addresses, but if you're like me and you're providing a development environment to aspiring CS majors, you would be really disappointed with the kids if they couldn't download a compiled utility or compile the source themselves to do it anyway. No, I assume they can find out the MAC address, unplug the box to be impersonated, force the NIC on their laptop to use the knicked MAC and get assigned the privileged ip (phew!). In short, it's a war I can't see a way to win. If someone has a magic bullet they're holding back that can lock this lab down, I'd love to hear it... (and supergluing the ethernet cable to the box is NOT a solution!) Instead, I make sure to hang around the labs and get to know the bright kids. The ones that love to hack and tinker are my favorites and I hire them to proctor the lab as quick as I can. I figure if you can't beat 'em, make sure to get them on your side. And log everything! There will be no record of a student logging in in box20:/var/log/wtmp when someone when someone has impersonated that box to mess with his stuff (which will show up in nfs_server's logs). Since you already know the bright kids, the list of suspects shouldn't be that long... hoping I made sense, JL -- 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
