Weird NFS Security Needs

spankenstein asks: "At work we are trying to switch to using NFS mounted home directories but have run into a problem. All of the technical staff have root access to their machines. It is necesary for this access. However, this leads to extremely easy ways to override NIS and any other "authentication" provided over NFS so almost anyone could mount someone else's ${HOME}. Is there any reasonably secure way of doing this? So far it's looking like Samba is the best answer but that makes no sense in a 90% Linux environment."

Comments

Nope, don't think it's possible

[Tet]

If you're allowing root access to individual boxen, then I can't see any way of preventing access. No matter what you do with NFS (or Samba, for that matter), the user can simply su to the user whose home directory they wish to access, and then access it as the user themselves. I have to ask, though, why do individuals need root access to their personal boxen?

Problem solved: sudo

[dlc]

Have you considered using sudo to give selective root access to users? sudo stands for "superuser do", and allows selective superuser access. sudo lets the admin define, in a shared config file, individual executables and scripts (by full path), and who they run as. You can give a user access to /bin/rpm as root, for example, so they can install packages, without giving them access to any thing else as root. You can also define rights by group and by machine, in addition to by user. Users use their own password to perform the function, so there are no extra passwords to distribute and remember. As an added bonus, sudo logs to syslog not only that user jsmith used sudo, but the entire command line -- very useful for auditing (where su logs only that the user became root).

Technical info: sudo is developed and maintained by Courtesan Consulting; the homepage is at http://www.courtesan.com/sudo/; it is distributed under a BSD-style license; it is at version 1.6.3. It compiles easily on (at least) Linux and Solaris (using gcc and Sun's native crap-piler, er, compiler), and lets you optionally define error message (there are some included and adding your own is simple). Here's a nutshell intrioduction.

I highly recommend it. We use it all the time. It takes a little bit of planning, as well as trial and error, to setup correctly, but once it is set up, it is a huge time saver.

In your situation, you would have to set up the complete config file (called sudoers) on an shared filesystem, make sure sudo is in everyone's path, and then change the root passwords on everyone's machine. You'll get a lot of complaints at first, naturally, and then you'll get a lot of requests like "Why can't I run foobarbaz.pl anymore?", which you would either have to add to the sudoers file or beat down the request.

darren

Cthulhu for President!