Date: Sat, 9 Feb 2002 08:27:37 +0100 From: "Anthony Atkielski" <anthony@freebie.atkielski.com> To: "Charles Burns" <burnscharlesn@hotmail.com> Cc: "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: Re: Breaking permissions on Windows 2000 (Server Edition) Message-ID: <017901c1b13b$40662f70$0a00000a@atkielski.com> References: <F8qwjGHIcrw7pUMMQkO0001c720@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Charles writes: > 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'm sure that the major FreeBSD programmers are > great people, but what does ones personal > trustworthiness have to do with the trust- > worthiness of their products? Their code? See above. > I may not know/trust the baker at Jack's Bagel > Bistro in Santa Barbara, CA--but that doesn't > mean that I can't trust the bagels--especially > if I can see the ingredients and make sure there > are no bugs in the flower and whatnot ... Unless you can verify and test the ingredients yourself, and observe Jack at every step of the production process, you must trust him. That typically is not possible, just as it is typically not possible to verify every line of code in an OS. > 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. > 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. > 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. 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. > Note that while keeping in mind the security > record of Microsoftware. The security record of Microsoft software is excellent. > 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. > 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). > 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. > 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. > 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. > Depends on who you ask. Most people respect Microsoft, even those who don't care for the company. 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. 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. > It was noted earlier that Microsoft's "toy" products > are used in several production environments. Yes. That sounds like success and satisfaction to me. > 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. > The MS SQL servers couldn't handle the load when > certain types of queries were used ... MS has never been strong in database management. They largely designed their DBMS software from the ground up, not actually having any experience with other systems, as far as I know. As a result, they've made all the mistakes that other DBMS authors had made and corrected years earlier. Even so, SQL Server is a pretty good product, though still behind some of the competition. Access, however, is not, IMO, and I would not trust a production system to Access. > ... the boxes crashed (on average) monthly ... Crashes on NT are mostly (indeed, almost exclusively) the result of bad drivers or bug-laden, trusted applications. > ... 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 have found that Windows is a mediocre server > platform but a good desktop platform, and I have > found the opposite to be true of Unix. My findings are identical. 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?017901c1b13b$40662f70$0a00000a>