Date: Sat, 09 Feb 2002 02:28:10 -0700 From: "Charles Burns" <burnscharlesn@hotmail.com> To: anthony@freebie.atkielski.com Cc: freebsd-questions@freebsd.org Subject: Security of Commercial vs. OSS. Was: Breaking permissions on Windows 2000 Message-ID: <F89WLAWhMvAXiTeLXh500005b1c@hotmail.com>
next in thread | raw e-mail | index | archive | help
> > I don't see the two as being related. > >In theory, they are not; but in practice, they are. The reason for this is >that you simply cannot personally verify every line of code in an operating >system, because there just isn't time. And if you cannot verify each line >personally, you must trust the authors of the code for every line that you >run without verification. And so, in practice, you must trust the authors >of the code you run on your machine. I can see your point that one must trust the authors of the code at some point. It all comes down to who one would choose to trust more, when it is needed. I would not trust, say, Linux developers all that much...nor would most people after looking at some of the code.(comments like: "NFI how I got this to work last night. I don't really understand it even now. Oh well, it works :-)" as much as other sources. I personally would trust the *BSD developers (particularly the OpenBSD developers) far more than Microsoft. The culture is very security minded and focused very tightly on security. Microsoft is a business. For marketing reasons, they generally have a set date to get products out the door. Windows 95 would have been quite the joke had it been released in 1996. Open source developers don't have any type of financial or marketing goal, so the software is generally released when they have it pretty well worked out. As a rule of thumb, I have found that open source tends to be one step above commercial software in quality, meaning pre-alpha open-source software is about alpha Commercial quality, beta is final and final is 2.0. There are, of course, exceptions such as Adobe and Blizzard Entertainment which consistantly churn out really rock-solid software, but I can say that Microsoft is not an exception in many cases having had a MSDN account and beta testing some of their stuff. > > One needn't verify the entire thing. > >If you want to be able to use a system without any need to trust its >authors, you _must_ verify every single line. As long as there is any >unverified code running on your machine, you trust the authors to some >extent. > > I can be reasonably sure that the IDE driver > > isn't going to open a hole on my all-SCSI server. > >Only because you trust the authors of the driver. No, because I don't use that driver nore is it compiled into the kernel. Much (most?) of FreeBSD and any other OS package goes unused. > > With a binary only program, I cannot do that. > >There isn't really any practical difference between a binary-only program >and a source program that you compile and run, unless you read every line >of >the source before compiling it. There are applications and parts of the system that are so extremely thoroughly tested; such as Apache, SaMBa, and the EEPro 100+ driver; software that so many different and widely varying people have thoroughly tested, beaten up, and looked at, that they can generally be considered trustworthy. Where the security advantage of open source comes from, other than the multitude of other people that have looked at the source, is that anything that is 'iffy', such as a new Apache module or a new version of XYZ app, can be examined. Any mistakes made can be corrected or just noted before the app is being put into production. This, a practical use of the source, cannot be done with binaries (unless you're REALLY hardcore) > > Impractical, which it will not always be, > > is better than impossible, no? > >No. In both cases, it boils down to trusting the authors of the code, and >the trustworthiness of the authors is thus more important than being able >to >examine the code. See above, but other than in the case above, agreed. > In fact, it is preferable to have binary-only code from a >perfectly trustworthy source than open-source code from a moderately >trustworthy source, from a security standpoint. The disadvantage of >binary-only code is more economic, legal, and logistic than >security-related. Name one perfectly trustworthy source. Surely you won't mention Microsoft. > > Note that while keeping in mind the security > > record of Microsoftware. > >The security record of Microsoft software is excellent. Err, if you don't count IIS. Other MS software may be arguable. I'm sorry, but IIS's security is world infamous. > > Compare Exchange Server with Qmail or Postfix, > > for example. > >There is no comparison. That's like comparing a mainframe with a >wristwatch. Additionally, there are far more users of Microsoft Exchange >Server than there are of Qmail or Postfix, as far as I know. More users >means more bugs discovered. Exchange is the wristwatch? :-) Seriously though, even MS still uses Qmail for parts of Hotmail (not for security reasons, though, but because it can handle bigger loads than Exchange). Qmail and Postfix do indeed have less users, but consider this case study: Qmail has been around for years and has *never* had a serious security exploit. Ever. There have been rewards offered for finding any such exploit. None have been claimed. Now, note hacker/cracker/geek culture. If such a piece of software is famous for insane security, it would be quite the accomplishment to break it. Most crackers enjoy the brief fame for the 'accomplishment' of breaking into something. Also note that Qmail is open source, so that one needn't even try sending millions of weird packets to test for crashes as they can see for themselves how the thing is designed to the smallest detail. No, Qmail and Exhange are not directly comparable, but both are common mail servers for their platforms. Exchange is all but the only mail platform for Win32. I doubt there are more than a handful of businesses running anything else onan NT mailserver. (Postfix and Qmail have a similar security design, but I know little of Postfix's security record) > > Usually it is the applications and not the OS > > with the majority of the exploits, but your > > point still stands. > >Some applications have even more code than the OS. The above-named >Exchange >Server is one example (I think). Probably. I'm sure IIS has code galore. (not much of which would be bounds checking :-P ) Particularly on Micorsoft platforms, huge apps that do everything seem to be popular vs. the unixy "do one thing and do it well" approach. While I certainly prefer using single programs with a well designed interface (a la Microsoft) to a million smaller ones, the latter does have some security benefits in the Unix world. Actually, Qmail in the example above follows this model in that it is actually several programs that do one specific part of the process of mail serving. No program trusts any of the other programs, so in theory a wouldbe cracker would need to break through several layers before getting anywhere. Seems to work pretty well so far. > > Note that OpenBSD and FreeBSD code (both of which > > have overlap) is frequently audited. I doubt that > > the auditors (who are great people for doing > > something so boring, BTW) dedicate their lives > > to auditing. > >Either way, you end up trusting _someone_. The only way to avoid that is >to >audit every line in the OS yourself. Actually, I would trust the *BSD auditors many orders of magnitude more than myself. I'm nowhere near as skilled with C as any of the major developers and auditors of said systems. Yes, you end up trusting somebody, but most admins I know (MCSEs included) would trust them to Microsoft or Oracle. > > If even 1% of the users of a network app study > > the code, which is very conservative considering > > the average Unix user, that's quite a few people > > who can notice a potential bug. It works. > >It diminishes the likelihood of a bug or backdoor going unnoticed, but it >does not _guarantee_ this. In securityland, there is a strong distinction >between mere probability and actual certainty. There is no certainty. After about 1,000 lines of code it is, in practice, essentially impossible to verify a program. Even "Hello, World!" isn't verifiable in many cases because you would need to verify the compiler's implimentation of stdout, the OS kernel's code that sends the data to the screen, etc. > > Most of the bugs found are never actually exploited > > and are generally never even tested. > >True for all operating systems, including Windows. > > > At a commercial software company, these would > > likely have remained until they were discovered > > by less friendly folk. > >I've seen no evidence at all to indicate that this is true. This is one of those arguments that are impossible to prove, and may indeed be untrue. There are many instances that I can think of, bug I am sure you canthink of many counter-instances. No point in arguing this one. > > Depends on who you ask. > >Most people respect Microsoft, even those who don't care for the company. Respect them for what? Depends. They know business /really/ well. They are great at creative phrasing, marketing, implimentation and sometimes improvement of other's ideas (and sometimes screwing the ideas up such as LDAP), have quite the legal team, know how to make money and sell products. Those things they can be respected for insofar as they warrant actual respect. Respecting them doesn't make the products any better, though. >Microsoft bashers are actually a small but very vocal minority, consisting >mostly of angry young males; and most bashers have become that way by >unquestioningly adopting the opinions of the alpha dogs in their social >groups, rather than by cold, objective analysis of the company. Speaking of cold... I would say that is more true of Linux/Alternative * zealots. As far as Microsoft bashers, it depends on what a microsoft basher is. The above is certainly true of people that have no basis for argument other than "it sucks.", but quite a few people that are willing to say negative things about Microsoft products are in that position because of experiences with various bugs, instability, poor tech support, etc. As far as bashers of Microsoft the company, well, anyone who has been screwed over by a creative legal agreement or business venture has room to talk. No large, public company can claim to stand on moral highground, but MS knows no bounds. I have little doubt that if they could increase their bottom line by one cent by ruining 500 peoples businesses/lives/savings, that they would not hesitate. While I doubt that they are intentionally maleficent, the effect is the same. > The leader >in any industry always engenders envy and dislike on the part of those who >would rather be the leaders themselves, but do not have the competence to >succeed. Such leaders may automatically incur dislike more than the smaller guy, but that does not make the company 'not suck', so to speak. Whether or not Microsoft is a great company with great products, being in a leadership position does not make the company great or have great products. Scientific theories that propose ideas wildly different than the status quo may in general tend to be flatly wrong more often, but the fact that the ideas are very different does not make the ideas wrong. That said, is it really even possible to overcome Microsoft as 'the leader'? Isn't that what the whole antitrust ordeal is about? > > It was noted earlier that Microsoft's "toy" products > > are used in several production environments. > >Yes. That sounds like success and satisfaction to me. If a skilled salesman sells you a mediocre product for the majority of your budget for that type of product, does your use of the product make you satisfied and successful? Additionally, once you take the bait (be it a good or bad thing), Microsoft does their damndest to lock you into the Microsoft way. Example: If you have to submit a document on Word format, does the fact that you use word make you happy with it? > > The INEEL (Idaho National Engineering and Environmental > > Laboratory) for example. They switched to NT from Irix > > and Solaris boxes in the mid 90s and, within 2 years, > > they switched to Linux systems. > >What motivated the switch from Irix and Solaris to Linux? Seems like a >step backward to me. Seems like the same to me as well. The reason was that they now had some very nice Intel hardware and some extremely dated Sun/SGI hardware and didn't particularly want to shell out millions for new toys. Solaris/x86 isn't a particularly good idea and Irix/x86 doesn't exist. >Access, however, is not, IMO, and I would not trust a >production system to Access. It never fails to amaze me how many companies host important data and even huge websitesfrom Access. Makes a good "Do not work here, either management or the IT department is incompetant" red flag. > > ... the boxes crashed (on average) monthly ... > >Crashes on NT are mostly (indeed, almost exclusively) the result of bad >drivers or bug-laden, trusted applications. Whatever it is, it happens more on Windows than on, say, FreeBSD. As far as I have seen, it is all but impossible for a usermode application to accidentally crash FreeBSD and the popular drivers are rock solid (though I haven't verified every line of code myself. Likely i'd be lost). As far as the drivers, they are generally commercially written software which has all the disadvantages discussed above. Oddly, Microsoft seems to be the only company that can consistantly make good drivers for other company's hardware. > > ... and of course the licensing for the software > > was a big turnoff. > >That is a major drawback to any commercial software, although one wonders >how they got to Solaris and Irix if licensing was an issue. I am not familiar with the old licensing adventures with either. I can only speculate. It may have been less of an issue then (recent funding cuts?) Need sleep, Charles Burns _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F89WLAWhMvAXiTeLXh500005b1c>