Dear Bruce, >> NFS has always had the root_squash option, to protect against a remote >> and possibly evil root. NFS should also protect all privileged, or at >> least all root-equivalent, UIDs and GIDs. Many UNIX distributions have >> root-equivalent GIDs, groups whose members could easily become root, >> some listed in http://bugs.debian.org/299007#219 . > > Hm. It depends on what you're using the exports for, I suppose. If the > server exports something it doesn't itself use for anything important > then the server should be safe against clients. The clients though may > be able to attack each other if say /usr/bin is mounted over NFS and > is writeable by some non-root group. OK, I guess that's what you're > saying. Sorry, no. There would be some protection if users could not log in to the server or some clients. My setup includes user login access to the server and to clients, so the attacker creating a setgid (group staff or disk or similar) /users/my/file is sufficient for a compromise of the server or any clients. There would be some protection if the server or clients had the relevant filesystems mounted nosuid or noexec, but in my setup users need to be able to create setuid-to-themselves executables. >> Currently, NFS has no ways to protect privileged UIDs and GIDs other >> than root himself. Such options should be implemented, to make NFS >> safer and more useful. As I understand it, the hold-up is not within >> NFS code, but with kernel interfaces not supporting lists of squashed >> entities. I am asking you to devise and implement such interfaces. > > That's not a small project, so we'd need a volunteer. As Neil says > kerberos might also help. I realize this is not an easy project. I will investigate NFSv4 and kerberos. Thanks, Paul Paul Szabo psz@xxxxxxxxxxxxxxxxx http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
