Slashdot Mirror

← Back to Stories (view on slashdot.org)

Windows to Linux Migration - File Server Security?

Posted by ryuzaki0 on from the user-level-shares dept.

Circuit Breaker asks: "I'm in the slow process of migrating my office from Windows to Linux. The servers have been Linux machines for quite a while now: Samba serves as PDC/BDC (not using Active Directory yet), and the Samba config is mirrored with rsync; all works well. No, it's time for the workstations, and all is NOT well. User lists are synchronized with NIS, which sort-of works, and will probably work better once we implement LDAP; but it seems that mounting of server directories can only effectively be done with NFS, which is a problem with security because some people really need local root. I've tried using NFS, CIFS and SSHFS, through pam_mount, automount, and independently, but it's not close to the usability of the Windows setup. It's either mounted per user, which requires a lot of work, or by root, in which case local root users bypass any remote permissions. How do you set up mounting directories that is easy to use like Windows -- everything automounted, but security settings are still respected for each user, even when local roots are involved?"

15 of 103 comments (clear)

  1. NFS with Kerberos by poopdeville · · Score: 3, Informative

    Some versions of NFS support kerberos authentication. Try that.

    --
    After all, I am strangely colored.
    1. Re:NFS with Kerberos by CRCulver · · Score: 2, Informative

      Agreed, Kerberos can be an excellent solution. The author of this story should see O'Reilly's Kerberos: The Definitive Guide or a similar introduction.

  2. NFS options by dbarclay10 · · Score: 4, Informative

    Recent NFS kernel implementations (for instance, whatever I have installed on my Debian/Sid boxen) have a few options which might be useful.

    First, in /etc/exports, you can do per-IP-address UID/GID squashing. 'man 5 exports' considered helpful. For instance (Slashdot will mangle this),

    /home/devel/fbar 10.60.55.20(rw,all_squash,anonuid=1001,anongid=100 1) 10.60.55.30(rw,all_squash,anonuid=1002,anongid=100 2)

    That will make the NFS connection from 10.60.55.20 have all access go via UID/GID 1001, and all accesses from 10.60.55.30 go via UID/GID 1002. This is most applicable when using single-user endpoints/workstations.

    Newer kernels (late 2.6.x-series) appear to have support for Kerberos and similar; of course, if you haven't even done LDAP yet (what's your excuse? If you're replacing Windows machines in an NT4 configuration, you should at least be migrating to something LDAP-based), then Kerberos is probably out of your league. Fix that.

    --

    Barclay family motto:
    Aut agere aut mori.
    (Either action or death.)
    1. Re:NFS options by hazem · · Score: 2, Informative

      Doesn't nfs have "root_squash" on by default?

      Where I once worked, our drives were all mounted via nfs. I could be on a local linux box and become root, but that didn't give me root access to the mounted drive. In fact, as root, I couldn't even see my own user files on the remote machine. If I wanted to do root-like things on the remote end, I had to log in there to do it. I've always assumed this was a defult way that NFS worked.

      This was more than 8 years ago, so I don't think it's anything new.

    2. Re:NFS options by hazem · · Score: 2, Informative

      This entire "ask slashdot" article is moot because of that.

      I'm glad to hear that. I was afraid it was just my faulty memory - remembering what wasn't.

      Maybe this guy has his nfs servers' exports file set with "no_root_squash" - which can be handy while trying to get things working - but never turned it off when it was done?

      I think for added security on the file server, all accounts but a select few had their home and shell set to /dev/null in the passwd file. That machine, a sequent running dynix, couldn't do NIS, so we had to maintain a separate passwd file for all accounts anyway. That way, people couldn't actually log into the file server itself.

      I just realized one issue, though. In that old setup, on a local machine, once you were root, you could su to another user and then have access to their files on the file-server.

  3. one word by Yonder+Way · · Score: 2, Informative

    NFSv4

  4. Fish? by dcapel · · Score: 2, Informative

    As I am certainly not a sysadmin, take with a grain of salt, but if you gave everyone konqueror (KDE browser), you could use fish to do it.

    Fish is a file-system-over-ssh setup, that only requires ssh access, with perl being optional. It respects all the permissions a ssh account would.

    Konqueror also has Kioslave for a crapload of other protocols, including nfs, so it would be worth looking into even if you don't like fish.

    http://www.garni.ch/fish/
    kde.org

    --
    DYWYPI?
  5. Re:If it works now by Anonymous Coward · · Score: 1, Informative

    Because when it breaks, as it inevitably will with some newly discovered vulnerability, it will be down for quite a while? Or, worse yet, pwned for quite a while with no knowledge of it?

  6. Re:If it works now by erroneus · · Score: 3, Informative

    Ever got hit with a BSA audit? That alone will convince you of exactly how tyrannical those bastards can be. Beyond that, it may be as simple as they are tired of paying for software licenses for software that leaves them virtually no protection against intrusion and is quite famous for its insecurity and unreliability. (I'm not saying anything is better, just that it's famous for its exploitability and that many working exploits are still unknown to the white-hat security crowd.)

    Pick your favorite reason. But ultimately, whatever the reason, I'm sure they have a good one and have decided the pains involved with migrating over are worth moving away from what they are using now.

  7. smbmount by paugq · · Score: 3, Informative

    Ever heard of smbmount?

    Yes, it's part of the Samba package.

    Yes, it does exactly what it suggests: mounts a Samba share (the same thing you were doing when you were using Windows)

    So, point one: you do not need to use NFS

    Now let's go for point two. And I will not extend here. Just a tip: man fstab, then go to the fourth field (options) and look for help on the "user" option.

    All your problems fixed.

  8. Re:What I don't understand by Schraegstrichpunkt · · Score: 2, Informative

    Um... that means having root access.

    --
    http://outcampaign.org/
  9. Re:Because someone got bitten by the Linux bug by Bert64 · · Score: 2, Informative

    You can use CentOS, which is fully compatible with RHEL.. Or Solaris, i believe Solaris is well supported by Oracle.

    As for running Oracle on windows, it's far more secure to run it on Unix...

    Oracle on windows runs as SYSTEM, whereas on unix it runs under it's own "oracle" account. Any vulnerability found in Oracle becomes far more serious on windows than on unix.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  10. Maybe this is naive by hey! · · Score: 2, Informative

    but perhaps you'd do better talking to a Novell sales rep than Slashdot? I mean this is their core business after all, and if Linux is a requirement, they are a Linux vendor.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  11. Re:What is your problem with NFS? by stevef · · Score: 2, Informative

    I think if you read some of the other posts, you'll get this point... but NFS using AUTH_SYS RPC authentication (as opposed to rpcsec_gss) provides literally NO file security. Yes, you can sqaush root or map it to another UID. But without giving up a lot of functionality (supplemental groups for example, using the solution suggested above about all_squash,anonuid=xxxx,anongid=yyyy) any user with root access on a client can do:

        $ su -
        # su - someuser

    And have all access as 'someuser'.

    Steve

  12. root is root is root is root by canuck57 · · Score: 2, Informative

    How do you set up mounting directories that is easy to use like Windows -- everything automounted, but security settings are still respected for each user, even when local roots are involved?"

    For directories the use of auto mount functions is best.

    But as the title of this suggests - root is root is root ...

    It is generally overstated 100% of the time that many users need local root for anything. They should be using "sudo" if they need to cancel print jobs, or add users. Indiscriminate delegation of root is insecure and a bad practice. Please examine the "local" need for root, I think you will find it is not needed. The sudo config file can also be rsync'ed.

    In fact, in my environment UNIX Admins don't have the root password except for 2. The other admins use sudo to a shell. Users use sudo for printer management. The "identity management" uses sudo. Even when users want to mount directories they use sudo. Want to shutdown the machine or make backups, use sudo.

    Only trusted and a few admins get interactive command line access as root.

    I do concede, Windows is easier as in fact almost everything with the system runs as the admin including the users. Down right insecure. And can't be made secure and still run. UNIX/Linux is not this way but takes some rational thought.

    Over NFS, consider keeping the nosuid/non-root access. Consider using groups to control access. So if a normal user ID has membership in group1, and the directory is read-write to group1 they have access. You might say, users who create files in this directory don't set the groups right... then you need to support the setgid bit on directories and umask settings. scrimant delegation of root is isecure and a bad practice.