Slashdot Mirror
Windows to Linux Migration - File Server Security?
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?"
If it works, why are you migrating? If it aint broke, don't fix it.
Some versions of NFS support kerberos authentication. Try that.
After all, I am strangely colored.
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),
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.)
You can probably save yourself a lot of grief and maintenance, by leaving the share wide open but implementing a good security policy.
By educating and training the users, there should be a minimum amount of confusion. But if you want to be 100% sure that files are being maintained, make at least daily backups so that if someone edits the document inadvertently then you can restore it.
Make sure you get a manager and director to approve the security policy and get a signature from each staff member so that they're clear on what files they can view and/or edit.
Hope this helps. That should make the migration a lot easier.
As in the whole migration. Seriously. You don't list a reason, so it could be anything from saving money (in which case you've already failed with the amount of time and effort you're expending and the commensurate costs, including lost productivity, not even beginning to think about ongoing support costs, because you know the OS licensing costs saved have already been way exceeded by the migration costs) to idealism.
...{blah blah blah}... but it's not close to the usability of the Windows setup.
But everything you've described is "we're trying to find a way to emulate this Windows functionality on Linux, and it's really hard". You're taking huge amounts of time, you can't get anything to work properly, and in the process I imagine you're causing your users a lot of aggravation.
I don't even want to know how big the office is, what sort of packages you're trying to migrate, etcetera, but presumably either you're in charge of a very small office, your manager is a Linux idealist or the majority of your office colleagues are Linux idealists, or you made it sound really appealing to your manager. If the first two reasons, I'd be guessing sheer stubbornness is making you carry this on through. If the last, I'd be guessing your manager will be asking some questions sometime soon.
So why are you doing this? Heck, just read the last few sentences...
I've tried using
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?
Mate...again, why, precisely, are you doing this? Now I really do want to know out of sheer curiosity...
NFSv4
Yes, there are advantages to having clued users able to do things on their systems [1] -- which is quite a different thing from having root access to the network stores.
In other words, I don't see the problem unless you've created it.
[1] Example: my system at $WORK. Note that most of the other engineers neither have, nor need, root access and I neither need nor have root access to anything but my own box.
Lacking <sarcasm> tags,
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?
NFS = NO FREAKING SECURITY
/mnt/machine1
The best you can hope for with NFS is to tie NFS-exported directories to individual machines via forced uid/gid mapping for each IP address. (all_squash/anonuid/anongid)
(Using root_squash alone won't do much good if someone uses local-root to su to an alternate UID.)
.
You can mount samba-shared files under Linux...
% mount -t smbfs -o password= '//MACHINE_1/NAME'
(With appropriate values for password.)
.
The real 800lb gorilla here is AFS. Which might be overkill for your organization.
For various reasons, including the lack of per copy cost, the actions of MS in the past, UNIX compatiblity, and so on many orginizations look at Linux. Unfortunately, in some cases it's not a "Well let's see if Linux would be good for us" it's "Windows sucks, we need Linux, make it happen now." There's no thought as to why, other than that it's Linux.
Happened to me at my last job. We needed an Oracle server for a project, had to be Oracle. No problem, we have a site license for it so there's no incrimental cost. We get a server, and then it falls to me to set it up. However I'm told it has to be on Linux. I'm given various reasons, all, none valid. Things like "Well Linux is more secure" though the server will be in private IP space, directly conected to another server. So I start fighting with various LInux distros and Oracle to no end. I finally get fed up with this shit and tell the people demanding Linxu if they want it, they can install it. The UNIX guru comes to try it, fighs with it for like a week and finally calls Oracle since we have support. Their reply? "You need to get a supported OS, until then we can't help you."
See we were trying regular SuSe and Redhat. Part of the whole Linux thing is it's free right? Oracle will have nothing to do with that at all. Supported Linuxes were RHEL, SuSe EL, and UnitedLinux. So we hit a roadbloack. I asked for permission to try Windows XP since that was a supported OS, the system had come with a license and why not. Oracle ended up installing on that fine on the first try and working properly. Then the project was canceled, but that's another story.
Nobody who was demanding Linux there ever gave any thought to if it was the right way to so things, it was just pushing Linux or, I suspect, pushing something not MS.
So I'd bet that's what's going on here. Perhaps the submitter is in a bad situation where management has made an uninformed decision that they must be using Linux, and now he has to try and make it happen, even though it's a problem. Could also be he's a guy who dislikes MS and has used Linux at home, and decided it would be good for work without doing proper research.
Why not give OpenAFS from http://www.openafs.org/ a try? It has its own permissions model, and (if you choose to have it so) is completely Kerberos-5 secured. Local root means literally nothing to AFS. It may be a bit beyond your needs, but in terms of scalability and security it beats NFS any day...
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.
What's wrong with using NIS/+/ldap with automounting nfs homedirs? Root, from arbitrary machines, should have no reason to access mounted homedirs, and the users can still do local root.
How is that hard?
Don't want to automount? Add a line to
The whole super custom complex setups, the kind you're digging yourself a into hole for, are the #1 cause for:
1. Hard to troubleshoot problems/issues.
2. Poorly performing infrastructure.
3. Security vulnerabilities.
4. Networks that are hard to make redundant.
KISS
Really, comparing windows file sharing to NFS and mentioning the word "security" - is the article a troll by someone trying to score points for MS or is the question being asked before reading even the man page?
Both NFS and CIFS/SMB do have serious issues that prevent them from being used on a public network without adult supervision (VPN or similar), so I don't entirely understand the question.
Use NCPFS. All you need is an OES server (Novell) and you can have any number of possible mounts, but NCP would be the easiest. smbfs also works in this situation for shares you define. Both are accessible from Windows or Linux, with or without the Novell client. Permissions are as granular as you can make it and can be administrated from anywhere.
Root access needed is a load. You don't know what you're doing if you're giving it out to anybody except the admin (yourself).
Good luck.
After using plan9, when I cam e back to *nix I thought that file access of the network would be a breeze. How wrong I was. Mind you, I was used to writing 9fs remote_9p_machine and it all being done. Even mounting a *nix box into plan9 follows the same pattern : srvssh nix_box
Unix is written for One Big Server with network services. Exposing the file systems across the LAN is a very unfunny joke and that's why people end up sticking with Samba!
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Windows is utterly opaque -- when something goes wrong, you have almost no way of diagnosing why, nor of fixing it, beyond going through the manufacturer's recommended procedures. You can't use your head to remedy faults using logic, because the hood is welded shut and so you don't have the visibility to be able to do that, no matter how expert you are.
In contrast, Unix systems provide a very high degree of visibility and transparency, and Linux + *BSD systems in particular make that administrator capability total.
There is absolutely no contest.
This isn't a reason that is quoted very often, but it's the only one that matters to me. When a (proprietary) system isn't transparent then I'm not in control, and that means that others are, be they vendors or criminals. That simply isn't acceptable.
First of all, go LDAP with TLS for your authentication. NIS is an insecure hunk of junk. Really, really insecure. Second of all lose the rsync between servers, if you're not using rsync via SSH that's insecure as well. Next drop the NFS. Once again, insecure. If you have no choice, use root_squash, but you're only fooling yourself into thinking there is security. None of the file transferred across the network are encrypted. If someone has root on the box, they can do whatever they want as far as changing their own UID. So what do you get for files? Samba. You could store the data to build a credential file on the LDAP server. User logs on, it builds a credential file, that you could have automagically be used by the automounter, then clear the file after the mount. That's one option. EASY WAY OUT: Use Novell OES Linux for the server and inbetween it and eDirectory it's all magic. If there's one thing that Novell's OES Linux does extremely well, that is it.
RTFM
If you would peruse the sudo documentation, you'd realize it is possible to customize it to allow particular users to execute particular commands as root.
Even without sudo, it's possible to allow only very specific actions as root by using chmod suid magic.
Of course, every time you use either of these methods, your security is lessened with respect to the next vulnerability found in sudo or whatever application you've authorized the user to run as root. But I did not get the impression that the poster was trying to set this up in a super-high-security situation.
In the same spirit one could ask: Why does it have to be Oracle?
If it is giving you all this trouble on Linux, why not choose another SQL server? Or is it ok to be bitten by the Oracle bug?
My UID is prime. Hah!
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.
SSH has quite a well prooven security record and FUSE was deemed stable enough for kernel inclusion. I'm sure you could come up with a good solution using these two.
A properly secured Windows box is more secure than you think.
:)
[ 289 patches, 112 tweaks to services, sixty-eight re-boots, a half-dozen add-on packages -- Norton, AdAware, etc. -- and fourteen hours later... ]
See?
Norton? Why would someone need Norton (presumably Internet Security for the firewall and AV for virus scanning) on a server? Windows comes with a built-in highly configurable firewall (called Routing and Remote Access, not Windows Firewall) and Symantec has an antivirus product specifically for use on servers called Symantec AntiVirus.
You need to check your information; the default installation of Windows Server 2003 with SP1 and all the updates (which the user is prompted to download immediately post-setup, which are batched together and require four clicks to download and install) is pretty secure and requires very little configuration to make it a file server: create the directory, right-click it and share it.
4 clicks to install all patches, no changes to services, one reboot, zero add-on packages, and a half hour later... I'm no Microsoft apologist, but at least I don't drink the Kool-Aid.
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.
Most user data is NFS supplied and not root-enabled. This causes almost no problems.
Can you describe in detail what your users need (or expect, generally a larger list).
Root power is surprisingly rarely needed if your setup is good. Without details, your issues can't be addressed properly. You will memerely receive a lot of recipes for breaking^Wweakening^Wloosening your security to achieve the power you request, without considering other ways to address the underlying problems causing the request.
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
mounting of server directories can only effectively be done with NFS, which is a problem with security because some people really need local root.
Welp, mod me redundant if I missed it but I just all the posts and didn't see the obvious answer...
When sync'ing the user info tweak your script to set the user number to zero on the workstations (or whatever the "local" machine is).
That way username can be "joebob", and user joebob (with a non-zero id) has restricted rights on the NFS host, but locally (with a zero id) user joebob is equivalent to root.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
In university research labs it's common for a user to have root on his or her own machine. I have root access to my machine - it is mine after all. I can mess around with it in any way I want, and if I cock it up, it's my fault and I have to pick up the pieces. It gives me a chance to learn a bit more about how my system works, and to try things out. But I absolutely should not have root access to the rest on the network. I'm too likely to break something important. Local root is useful, network root would be stupid.
You may be interested to know that as of kernel 2.6.16, nfs now supports 1mb read/writes, previously it was only 64kb. This brings it inline with Solaris (if you have any solaris boxes on the network) and will help reduce the protocol & context switch overheads.
Haydn.
Time is an illusion. Lunchtime doubly so. - Douglas Adams
It's the local root thing that's the problem, and I'm not aware of an answer with NFS unless perhaps the Kerberos stuff. You need a system where the user is responsible for authenticating with the server, not the machine. Kerberos can do this very well for all sorts of services. Googling for "nfs kerberos" shows that NFS version 4 can do this and behaves as expected authenticating the individual users through their kerberos logins.
You can use the root_squash option on the NFS server, and that will prevent the server respecting root remotely. This does not help though as all the remote root user needs to do is create a user with the right uid and (s)he can become that user as far as NFS is concerned. Again Kerberos in NFS4 fixes this.
Older versions of NFS come from the old days of secure networks where no-one but the admin staff had root access and no unauthorised machines can connect.
Are your users having their home directories on NFS, or just shares they access? In Windows a lot of this is done by the desktop shell using the SMB file system and the password the user logged on with (or the kerberos ticket if you're in a new Active Directory setup). I've not seen a Windows system with remote home directories. If you're not having remote home directories users can mount shares using the desktop SMB clients in the way they currently work in Windows.
For those saying "Sticking with Windows is easier", setting up and running Active Directory on Windows is not trivial.
Why is that interesting? It was NOT kerberos. It was a MS troll trying to again FUD something.
???
You posted a correction to say that the Windows default with SP1 is "secure"
???
Try running nessus or even nmap against it.
Try referring to NSA guidelines for securing a windows 2003 server environment.
http://www.nsa.gov/snac/downloads_win2003.cfm?Men
Or read some of the SANS whitepapers:
http://www.sans.org/rr/whitepapers/windows/
Windows machines can be hardened to a degree, but never as much as it's possible to harden linux or bsd's because they can be streamlined much much more by tossing out all of the unused components and modifying the components you do use to be slightly nonstandard and less succeptible to known attack vectors.
iami