Slashdot Mirror
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."
The system that we have at Uni. is such that you
may have root on the machine you are sitting at
but you won't have the same priviliges on an NFS
mounted filesystem. grep the NFS docs for the
phrase "export root".
Because Unix has a crude "all or nothing" security model - you're either the sysadmin, or you aren't. More mature operating systemd (VMS, for example) allow very fine-grained control over system privileges.
That's not strictly true. While it doesn't have the fine grained security of, say, VMS (at least, not without using the various capabilities options available), it's not necessarily all or nothing. You can do an awful lot with sensible use of groups. In my experience, 99% of the times that people claim they need root access, they don't. It's just the quick and easy way out, so they take it.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I'm aware of several possible solutions, each with its own problems.
/etc/exports file. This works best if each system can be assigned to a single person, but even if you have a few shared systems in a lab it may be an acceptable solution.
1) Explicitly tie the home directory to specific machine(s) in the
2) Encrypt everything. If you are using the loopback filesystem encryption, you can NFS mount the home directory someplace else, then mount it via loopback over the user's home directory. Depending upon your level of paranoia, it could be mounted and unmounted as the user logs in, or it could be automatically mounted during the system boot. (This requires that the script know the password.) One potential downside is that you must specify how much space to allocate to the user up front... but then again this is an effective form of quotas, ensuring backups fit media, etc.
3) In a completely different direction, you should also evaluate Secure NFS. The recent glibc libraries include support for secure RPC, and I believe secure NFS ports are in progress. Once available, everyone should switch to secure NFS anyway to eliminate many of the problems associated with individuals having root access on their own system. (E.g., as a consultant I usually bring my own Linux laptop to the site... and I am not willing to surrender my root access to the typical IT drone.) Unfortunately, I don't know if secure NFS addresses your specific problem - the keys may be tied to the system, not the exported file system.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
- Local users get sudo access to certain things. No need for local root.
- man 5 exports, and they setup your NFS server to squash root (under Linux, it's default, and you have to override with no_root_squash). For example, I use "/inst 192.168.0.0/255.255.255.0(ro,root_squash)" for my Slackware install NFS share. No need to export shares that allow root to muck up things.
Either way, you stop handing out root privileges like it's christmass -- a definite security benefit---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
If you're not extreeeeemly careful with sudo (maybe only allowing root access to a few programs like mount, etc), you're handing someone who knows what they're doing root.
/bin/sh /bin/rootshell; chmod 4755 /bin/rootshell" and they have root). Also, this means they can't install their own software - else they could replace the NFS server and related stuff with trojaned copies. That means more maintenance in most cases.
First off, many programs provide shell escapes:
[lloyd@shirley lloyd]$ dc
!/bin/sh
bash$
and there are more where that came from. Give someone a root shell and all is lost (an easy "cp
Also, if the people are techie types they will tend to get pissed off if you take away root on their personal machines. And unless you take care to lock down every machine very tight, they'll do things like booting into single user mode, use boot disks, etc.
Personally I don't see the need for this at all, unless it's common for people to go from one office to the other editing files on their home machines. Just a big PITA (Pain In The Ass). If you happen to be on someone else's machine, ssh to your own.
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?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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!
(darren)