Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Weird NFS Security Needs 20

Posted by Cliff from the getting-it-working dept.
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."
This discussion has been archived. No new comments can be posted.

Weird NFS Security Needs More

Weird NFS Security Needs

Comments Filter:
  • 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?

  • 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.
  • You'll want to be careful when you set this up though, as if you're not careful users can gain root access very easily. For anything you want to allow via sudo, you'll want to make sure it has no buffer overflows or a way to run arbitrary code. I'd recommend checking the source for anything you want to allow, looking for dangerous syscalls such as strcpy() and memcpy() (Basically any syscall that doesn't do bounds checking) and as a further measure, compile them all with Stackguard. For scripts, you don't want to allow anything the user has access to modify, and probably don't want to give them read access either. And make sure all your scripts use dynamic filenames for any temp files, as you don't want to give the user a race condition they could use to gain elevated priviledges.

    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.

  • 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. :)
  • Yet Another Reason For ACLs?

    ACLs won't do any good in this case, its not that the permissions are deficient, its that NFS has a flawed design when it comes to security: it completely trusts the client to take care of enforcing the permissions. so even if you had acls it won't do any good since the client root can ignore them anyway. Its already been mentioned that you can squash root but that only works when all files are owned by root, which is not very useful for home directories.

    I'm not sure the classic UNIX security makes any sense anymore.

    I don't think its classic unix security that is the problem here, its the classic NFS non-security that is the problem. any system which trusts the client for authentication/permission enforcement is fundementally flawed.

    I think you might be thinking along the lines that `all powerful root' does not make sense any more, and in some cases it does not which is why there are some capability based systems (trusted irix and such) where uid 0 is just another account. Trusted IRIX has this available as an option but i suspect (i have no real numbers) that most IRIX users configure it WITH the all powerful super-user enabled, simply because administering a fully capability based system with no root is much more difficult and thus more time consuming. (i could be wrong here but that is the impression i get)

    Maybe you could just rm su?

    as has been mentioned revoking root access in this case is probably not an option. even if it were they would have to deal with loads of physical access problems. the network, the workstations etc etc.

    --
    ln -s /dev/null .signature
  • >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".
  • I have to ask, though, why do individuals need root access to their personal boxen?

    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.

  • Because Unix has a crude "all or nothing" security model - you're either the sysadmin, or you aren't.

    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.

  • I'm aware of several possible solutions, each with its own problems.

    1) Explicitly tie the home directory to specific machine(s) in the /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.

    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.
  • Two wonderful solutions (probably more are possible):
    • 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 :-)
    ---
  • 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.

    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 /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.

    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?

  • Problem solved: sudo (Score:3)

    by dlc ( 41988 ) <dlc@NOsPAM.sevenroot.org> on Tuesday April 11, 2000 @02:32AM (#1140835) Homepage

    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 [courtesan.com]; the homepage is at http://www.courtesan.com/sudo/ [courtesan.com]; it is distributed under a BSD-style license [courtesan.com]; it is at version 1.6.3 [courtesan.com]. 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 [courtesan.com] 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! [cthulhu.org]

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close