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."
Sure... but on your machine, you could still change your UID to that of anyone, and access someone else's files........
Basically NFS has no real security model for inhomogenous networks like this... you need something like samba, or maybe ncpfs or coda or AFS might work, I'm not familiar with them...
But samba with automounter would probably be the best bet by far.....
Err.. I meant samba would be the easiest by far, not necessarily the best....
Yet Another Reason For ACLs?
I'm not sure the classic UNIX security makes any sense anymore.
Maybe you could just rm su?
Scuttlemonkey is a troll
root_squash provides "no" real security benefits. Keep in mind any user with root priviliges has the ability to change their UID to any other, completely bypassing root_squash.
* "no" meaning no "absolute" benefits -- it only keeps out the really stupid users for very long, and even then not very long.
Although, back to the original question, why not export each home directory individually, and allow only that user's workstation to mount their homedir? Sure, it's a little more to setup, and can make for a rather large exports file, but if you aren't moving people from workstation to workstation, then it should work fine. You may also look into samba, which would provide the authentication you desire, and have the added benefit of working with any win or macos machines you might have about. AFS may also provide such authentication, but that is pure speculation on my part, as I'm not familer with AFS.
When I was able to do my own spam-armoring, you got a chance to email me. Now you can only hope I see your reply.
At the place I work, we have a similar problem. We have many "unsecured" machines around (in labs), and currently have home directories exported via NFS.
Trying to secure the end machines is not really possible - we don't control all of them, and students (we're a university) often legitimately need bootdisks, or local installs, or laptop access to their home dirs.
NFS trusts the client machine pretty much completely - ie. root can pretend to be any user.
Our solution (not yet implemented) is to have a seperate authentication step (tied to the login program) that the server verifies and sets up an explicit export. However since we haven't finished this, we don't know if it'll work in practice.
Samba would seem like the best bet, but it does screwy things to UNIX file permissions (there's a reason we use UNIX...), and Coda just has two many negative points that make it inappropriate for us.
AFS is a non option for an all-linux shop with no real budget to speak of.
Has anyone solved this yet?
And just to prove the point of how careful you have to be, 'mount' isn't safe. You could create and mount a filesystem with a suid shell on it...
:)
Ahhh... very nice. I didn't think of that.
>maybe only allowing root access to a few programs like mount, etc),
And just to prove the point of how careful you have to be, 'mount' isn't safe. You could create and mount a filesystem with a suid shell on it...
This only works if physical access to the workstations is locked down tight. If somebody uses a boot floppy, or plugs a laptop from home into the ethernet port...
NFS = No File Security.
AFS would work, or Coda. You might be able to monkey something up with a cryptographic file system running on top of NFS.
It's possible, just not with NFS. The problem with NFS is that it leaves user authentication to the client; a protocol that does user authentication on the server could work.
This makes life more complicated, but it's possible.
THe thing here is, if someone REALLY wants to, he/she can circumvent anything you put up to prevent this. If you don't give them root, they will hack the box in single user mode. If you prevent them from running single user mode, they will just put another machine in the net. If you prevent that by allowing only certain MACaddresses, they will find something against that. The real issue here is, get people that aren't interested in violating other persons privacy and if they have to go through "confidential" data, they should know how to handle it.
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)