Study Finds Windows More Secure Than Linux 796
cfelde writes "A Windows Web server is more secure than a similarly set-up Linux server, according to a study presented yesterday by two Florida researchers." In addition to the Seattle Times article, there is also coverage on VNUnet. From the article: "The researchers, appearing at the RSA Conference of computer-security professionals, discussed the findings in an event, 'Security Showdown: Windows vs. Linux.' One of them, a Linux fan, runs an open-source server at home; the other is a Microsoft enthusiast. They wanted to cut through the near-religious arguments about which system is better from a security standpoint."
Integrity? (Score:5, Informative)
Well, apparently this is the second time Microsoft has come out on top of a research project by Mr. Richard Ford [fit.edu].
http://www.virusbtn.com/magazine/articles/letters/ 2004/01_01.xml [virusbtn.com]
Apparently there was some question to the validity of an earlier project because it was sponsored by Microsoft.
However, I would like to note that both researchers seem very well educated, especially in computer security. And, additionally, they both note that a lot more could be done to lock down the Linux server.
Re:Integrity? (Score:2, Informative)
From the website of the sponsor (Score:2, Informative)
I'll allow you to jump to your own conclusions.
Re:Hardly scientific isn't it? (Score:1, Informative)
If you are going to make a comment about the validity of the data, at least RTFA you ignorant clod.
"They compared Windows Server 2003 and Red Hat Enterprise Server 3 running databases, scripting engines and Web servers (Microsoft's on one, the open source Apache on the other). "
How many people run RH Enterprise Server at home?
Re:Integrity? (Score:2, Informative)
Re:Newsflash... ONE Linux Fan.. (Score:5, Informative)
Um, no. Your average system administrator earns about $62k has at least 2 years experience, and generally a bachelors degree in a related field. At least according to most industry figures. [salary.com]
The job title also entails tweaking system configurations for security, evaluating patches, etc. etc.
Need Details--cause this shows common Errors (Score:2, Informative)
They need to explain exactly what they did to come to this determination. As I read it, they compared default setups... which avoids the "security is a process, not a product" debate.
However, it sounds like they compared the number of reported vulnerabilities as if they were apples and apples--which is a big error. Open Source should yield discovery of more vulnerabilities--the more, the better it's working.
On the other hand, if critical vulnerabilities are not being patched as quickly as for Windows then that would be a problem. What are the statistics on that?
Matthew
Re:Enthusiast?! (Score:3, Informative)
Re:Not only that, but I find this quote odd.. (Score:2, Informative)
http://www.microsoft.com/resources/sharedsource
Joke aside, it is possible. But you must have a good reason I guess. And "I want to see if IE can be removed from the kernel" probably isn't one of them.
Re:More FUD (Score:2, Informative)
My guess is that someone else in the program has Microsoft funding for his project, but you could be right. In any case, the OP's assertion is incorrect.
True article, false title. Redhat != Linux (Score:3, Informative)
So, the research is very true - a straight redhat install with no outside packages does have longer windows of vulnerability than a straight Windows install with no outside packages. But the person writing the article told a MAJOR LIE when summarizing it for the article, by attributing the long windows of time to linux in general, when really it's a problem with just redhat.
Re:Newsflash... ONE Linux Fan.. (Score:3, Informative)
Exactly. Regardless of the validity of the study the Linux community should be taking this the same way they've taken other comparisons in the past: as a spur to make the changes and improvements necessary to make Linux simply that much better than the opposition.
Right now that means, if you're a developer, you ought to be spending a little time learning about SELinux and how it works. SELinux provides a framework for security, but it is only as secure as the applications running in that framework. If the applications respect and take advantage of it, it is a huge gain, if they don't then it provides little real improvement.
One of the big security claims for Linux over Windows is user accounts. The fact is that both Windows and Linux have differing user accounts with differing permissions. On Windows, however, there are many applications that don't care about user accounts - they expect Administrator level access. On Linux non root accounts are fundamental and almost all the (user) applications understand that they can't expect to be root. That means that on Windows the user accounts and permissions, despite being implemented and available, don't provide too as much security as they do on Linux.
Right now SELinux is the same way - there's a new security framework (roles, mandatory access controls), but the applications ignore it: they fail to respect the new boundaries, or they fail to take advantage of the compartmentalization of lowest privilege systems that SELinux allows. The community needs to take the step toward embracing this new, better, security framework.
Claims like this study should be the spur to get the community to do that! Help spread awareness of the task...
Jedidiah.
Unhardened Apache versus unhardened IIS... (Score:1, Informative)
Re:A lot more could certainly be done... (Score:5, Informative)
Of course, running anything chrooted usually requires making a list of subprocesses that the program calls, and linking them into the program's directory tree. You'd want to do this in this case, because web servers typically do invoke some subprocesses. Not always, of course; some web sites are completely static. In any case, this doesn't require any sort of patch; just a list of what files are needed in the chroot area.
So what's in the OpenBSD chroot patch? What sort of vulnerability existed without it?
Re:These studies are pointless. Both can be secure (Score:5, Informative)
Re:Integrity? (Score:2, Informative)
Insighfull? Not really. (Score:3, Informative)
Sure most people will have 1 server handling all tasks running somewhere outside their reach but there are ways around having every damn service in the world open to the entire world.
I've seen it in action (Score:3, Informative)
The faculty that ran the *nix based services had almost no complaints of intrusion or other security problems from the "global" IS department of the university, while some of the windows using faculties were being threatened with losing their internet access because of too many security breaches.
No, this isn't a study. But it's evidence of how it works in the real world.
The reason I think *nix is more secure is because of how configurable it is. You can configure almost anything. Hell, you could write your own TCP drivers if you felt like it (not that I've ever known anyone to do that). On Windows you're limited to the security options given to you from the vendor. Or you have to pay a 3rd party for their innovation... With *nix the power is in your hands.
'Out of the box' software/systems are usually never ready for production environments right? But sufficiently tweaked most systems can be reasonably secure and centrally manageable. I just think that level of tweakability is higher with *nix.
Bruce Schneier on Linux security (Score:5, Informative)
Bruce Schneier [schneier.com]
Posted on January 06, 2005 at 01:45 PM
------------
Different methodology, different results. My money's on Schneier.
Related article (Score:3, Informative)
Re:More FUD (Score:5, Informative)
Having read TFA, the "study" consisted of counting security flaws for RH and Windows, and comparing how long it took to issue patches -- from the date of the vulnerability being announced. This is really shallow; we've seen lots of such studies and laughed at them. I note the spin put on this is "One of them, a Linux fan, runs an open-source server at home..." which makes it look like a Linux zealot has been hacked in his own home, while the happy Windows guy is unscathed. In fact, it was all hypothetical, there were no trials of real servers (none mentioned anyway), just "potential" vulnerabilities in default setups.
Re:More FUD (Score:4, Informative)
Did you read the article? The server tested is Windows 2003. The web server is IIS 6.0. These "many exploits" that you refer to, which ones are they? Last time I checked there were no reported remote exploits for IIS 6.0. There ARE exploits for 2003 as a platform, but not for 6.0 as a product.
Re:Knock Knock Joke (Score:3, Informative)
Re:Knock Knock Joke (Score:1, Informative)
Re:A lot more could certainly be done... (Score:3, Informative)
Ehh no. If you want to bind to low network points, you can do that as root and then setuid(3) to another low-privilege user, or by getting a file-descriptor from another (more privileged) process, or you could get that capability granted to you by a startup-script, or another process. For web-servers, almost everybody would use the simplest solution: setuid(3).
Since the Windows security model is completely different (ie: it's more complicated than unix's "if UID != 0 then apply_security()"), the concept of chroot doesn't really need to exist.
No. The problem you mentioned isn't why chroot is useful. chroot isn't needed on unix either (in theory). Since most web-servers on unix runs as some non-privileged user anyway (as opposed to IIS which has system privileges), you are extremely way off the target.
chroot is there simply because all software has bugs. Even if there is a critical security hole in e.g. the operating system, that results in a remote vulnerability, and someone takes advantage of this, they still can't escape from the chroot'ed environment. Unless there are holes in the chroot functionality too (which could be true).
Good security practice is to do a total overkill, i.e you build your security in layers. You have one (or more) firewall(s), preferably both at the packet filtering level and the application level. You run every service with as few privileges as possible. You put them in a chrooted environment. You lock down everything you don't need. You run it on a dedicated machine (and/or use something like UML). And then you can start worrying about keeping up-to-date on patches.
By the way, the unix security model you described might have been correct in the 70's. It isn't anymore. Different unixes might do different things, but most certainly everyone will at least have various ways of escaping the need to be root to do useful stuff, e.g. capabilities, passing of file-descriptors, etc...
Re:A lot more could certainly be done... (Score:3, Informative)
chroot doesn't affect a processes namespace, it just affects path name resolution so one can easily escape the chroot with "/..".
This can only work if you are root user in a chroot environment -- what any sane secure design avoids or limits to a small, secure part of code. And no one places setuid binaries into chroot environment, so privileges elevation can be only a result of a kernel bug -- what is not unheard of (recently patched in Linux), but is a very uncommon compared to other vulnerabilities.
Re:More FUD (Score:2, Informative)
regards,
Steve