Submitting a review for consideration is easy; please first read Slashdot's book review guidelines. Updated: 2008114 by samzenpus
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
MBTF My Ass (Score:2, Interesting)
I hope that was just CNet editorialization, and isn't indicative of the rest of this paper.
Re:MBTF My Ass (Score:3, Insightful)
The Manufacturer's Estimated Time Before Failure is for physical goods - things that naturally wear out. Not software, which is at the very least a loose mathematical desctiption of a repeatable process.
Read the paper, there's a link to a PDF in the story.
The paper does indeed use an MTBF-type model to analyze bugs, and there is a significant body of research which supports this approach. As the author says:
It's certainly not obvious that this model invented for physical goods applies to software, but there is substantial research to show that it does. If you can really demonstrate otherwise, I highly recommend that you get familiar with the literature and then publish your own research paper that explains why it is not an appropriate model. If you can propose a significantly better one, you'll have advanced the state of software engineering and you'll probably be well on your way to a cushy professorship somewhere.
Re:MBTF My Ass (Score:2)
Ehrm, BULLSHIT.
By your logic, ALL vulnerabilities don't exist until someone discovers them.. at which point, one has to ask, if they didn't exist, then how were they found?
"If you can't see something, then that means that it doesn't exist."
No, the vulnerability always existed, just because nobody found it doesn't mean that it wasn't there.
Windows operating systems re-configure themselves. (Score:3, Informative)
"... why do my Win2k installs slow down to a crawl after a few weeks..."
Windows operating systems re-configure themselves without telling the user. Bill believes he knows better than you.
I find bugs and insufficiencies in open source software. But generally open source software impresses me as an attempt to do a good job.
In contrast, Microsoft software seems just sloppy. For example, Microsoft's Internet Explorer has 18 unpatched security bugs [jscript.dk] (when this was written). These active security risks are different from the recent 15 that have already been fixed. This is sloppiness, not mistakes, and I don't find anything like it in the open source world.
In case the
By the way, when Windows becomes slow because it re-configured itself, try this:
Re:Windows operating systems re-configure themselv (Score:3, Interesting)
"Do tell us not just that he's wrong, but why."
The mathematics is absolutely stupid! The author assumes that bugs are a random event. But they aren't. Bugs are heavily influenced by sociological factors that affect the outcome by more than a factor of ten. A lot of the bugs you seen in Microsoft Internet Explorer, for example, come from the sloppy practices of programmers who are not particularly interested in what they are doing and who are pushed to a tight schedule, so when they see that something needs to be re-written, they can't re-write it, because they don't have time.
Remember when Microsoft released Windows 2000? Someone inside Microsoft said that there were still 63,000 bugs (or known shortcomings) in their database. There was no time to finish the job, and Windows 2000 and Windows XP are still quirky. I just reported a bug in Windows XP, again, which I first saw in Windows 98. All of those operating systems re-configure themselves without telling the user. The company just doesn't care enough to do a good job.
Bugs in software are caused by social factors that we cannot measure. Some programmers write far tighter code than others. Compare the security bugs in OpenBSD [openbsd.org] and in Windows. OpenBSD is far more secure because the people who control it say they want it that way. Microsoft just announced a greater interest in security, but will the company actually devote resources to fixing the code? That's a sociological issue for a company that has always put money first.
It is impossible to test reliability into software, or anything! Reliability is due to design decisions, or the lack of them.
The author says,
"Reliability growth models seek to make this more precise. Suppose that the probability that the i-th bug remains undetected after t random tests is e-Eit. The models cited above show that, after a long period of testing and bug removal, the net effect of the remaining bugs will under certain assumptions converge to a polynomial rather than exponential distribution. In particular, the probability E of a security failure at time t, at which time n bugs have been removed, is [Equation that Slashdot cannot display: E = 1X i=n+1 e-Eit ~~ K=t] over a wide range of values of t. I give in the appendix a brief proof of why this is the case, following the analysis by Brady, Anderson and Ball [7]. For present purposes, note that this explains the slow reliability growth observed in practice."
He is just pulling your leg, and probably his own. Note the word "random" in the second sentence. In mathematics that is a technical term, a precisely defined term, and it doesn't apply here.
The author is just grabbing attention, and it worked. Now he has something to put on his resume, an article in CNET (by someone who doesn't understand the mathematics, but assumes that it must be okay, because it looks so impressive).
Show me the equation that has a term that explains the difference between OpenBSD [openbsd.org] (Five years without a remote hole in the default install!) and Windows XP [jscript.dk] (zero seconds).
Give the source code of Internet Exploder to the OpenBSD coders, and we will see how random bugs are. They could do what they already did with BSD, examine the code for poor practices, and re-design the parts that need it. Then all the "randomness" would stop happening, as if (in the view of some) by magic.
Might be controversial (Score:3, Insightful)
How secure is an out of the box mandrake install ? or a windows 2000 ?
A good admin who is a pro will work hard to secure his servers and patch and look after them - a bad admin is a bad admin regardless of the OS
Re:Might be controversial (Score:4, Insightful)
Parent
Re:Might be controversial (Score:4, Insightful)
Many years ago, anyone who wanted to drive a car also had to be a mechanic. Things needed constantly tweaking, they would break down often and were difficult to start and keep running. These days, if someone had a car that kept breaking down, you wouldn't say to them "well, that's your fault. You're obviously not a good mechanic", you'd say "go out and buy yourself a better car, mate".
Don't blame the administrators for the primitive state of current computer technology.
Parent
Re:Might be controversial (Score:3, Insightful)
Answer- Mandrake is more secure than Windows... (Score:3, Interesting)
Windows does none of this. Everything but the kitchen sink is installed and running. It's hard to tell what's running, especially if you're not familiar with Windows' cryptic names for all the services. There are no good explanations of what services really are or what they do. Everything is buried 3-4 levels deep, and poorly organized. Unless you're already familiar with it, it's much harder to figure out than Mandrake.
So yes, Mandrake is more secure. Part of this is the installation itself- it goes through the appropriate steps to build in some security. The other part is general usability. Mandrake wins here, too.
Don't get me wrong, not all Linux distros are as good in this respect. IMO, Redhat is about as bad as Windows, though it's getting better. Others might be a complete disaster.
Re:Answer- Mandrake is more secure than Windows... (Score:4, Interesting)
Windows, OTOH, starts with the assumption that a complete idiot will be installing it. If networking is crippled by default, it will probably remain crippled until the user returns the computer because it "won't do X". And it makes the almost-reasonable assumption that with an idiot setting it up and using it, the box won't contain anything worth a good cracker's time. And these assumptions are almost OK; the problem is that (1) when the box is used for something serious, it's hard for even a professional administrator to keep up with all the changes needed to make a system secure, (2) they've made the home system default so wide open that serious crackers can take over hundreds of them at a time and use them in assaults on important targets, and (3) MS is so sloppy that everything is a lot more exposed than they intended...
Parent
Security Bugs are inevitable (Score:4, Insightful)
Re:Security Bugs are inevitable (Score:5, Insightful)
A flaw is an error in judgement. A bug is an error in coding. The original poster ended his statement that Open Source has lots of bugs. This is unrelated to security unless they are specifically security related bugs.
In any event, the speed at which you can lock down the Fort HAS to be a consideration.
I mean, We have planes flying in Iraq and Afganistan right now. They are being shot at all the time, but they move fast enough to get out of the way. OpenSource moves faster than closed source so I can't possible see how the article writer concluded they were equal.
Equally buggy, yes. Equally secure, puhleez.
Parent
Re:Security Bugs are inevitable (Score:2)
That attitude is a big dangerous IMO.. That is an excuse for programmers to have bad/lazy coding habits and not program with security in mind..
Developing a good coding habit and learn and use all known techniques for creating secure code is the only good way to minimize security bugs.
Even in the year 2002, it's still common to find unchecked strcpy's in newly released code..
WHen you write software you should design it to be run as root on sensitive boxes without a firewall. But then you should run it chroot as a restricted user with minimal permissions anyway...
And of course, release securityfixes as fast as possible if bugs ARE found...
Re:Security Bugs are inevitable (Score:3, Insightful)
Of course not... (Score:3, Insightful)
The main difference lies in the speed and motivation to fix the bugs. Open source bugs can be fixed by anyone, but closed source bugs need to be fixed by vendors who are afraid to even admit they exist, for fear of losing customers.
Re:Of course not... (Score:5, Insightful)
Open source bugs can be fixed by anyone, but closed source bugs need to be fixed by vendors [...]
Correction: open source bugs can be fixed by anyone with requisite knowledge, talent, and time. This would include things such as familiarity with the particular software package, affected platforms, and programming language and the energy and ability to ferret out the bug(s) and apply an appropriate fix. Then one has to factor in that package maintainers may or may not readily allow outside submission (e.g., bigotry, internal/peer review, etc.) of fixes, which may slow, hamper, or block the transmission of fixes. Add into this issues of trust, where a "fix" is offered by someone who lacks proper credentials (official or "street") to someone who has no clue how to evaluate the original issue or the proposed remedy.
Granted, given the nature of open source software, the population of people who may repair a bug may be larger than that for closed applications, but that doesn't force into being an army of people with the inclination or skills to do so, or an effective and trustworthy means to distribute said fixes.
I favor the potential for open source to improve response time to bugs, but I don't think one can claim "anyone" can address issues in an appropriate manner. There's no reason a skillful and organized firm couldn't address security concerns for a closed application it offers with any less celerity than maintainers of an open application.
Parent
Security (Score:3, Insightful)
Buglist (Score:2, Insightful)
Just my two cents.
Duh... (Score:5, Insightful)
Re:Duh... (Score:3, Insightful)
Well said. Likewise
Another viewpoint (Score:3, Interesting)
This is certainly true, however there is a large amount of security appears to come from the community / vendor around the code too. Yes, I'm generalising, but open source programmers treat security problems as security issues, rather than as a PR problem. Even though the apache team ( rightly, in my opinion ) criticized ISS for the manner of their reporting, they did also release a full disclosure release, and a suitable, working patch within 36 hours of the issue going public.
I don't see many vendors responding that quickly, although, to be fair, the apache team did know about the vulnerablity already.
It's all about the "Window of Exposure" really. Go to Bruce Scheiners Cryptogram page [counterpane.com] to see some excellent arguments about peer review, and the whole window of exposure idea.
Re:Another viewpoint (Score:2, Interesting)
This is contradictory to the rest of your post. You mention window of exposure. While you might argue the window of exposure starts with public disclosure, it really does not.
A flaw that is found in a piece of software often was there for years. The window of exposure actually starts when the flaw is introduced, since from that point forward, there is the possibility of a person or group having knowledge of the flaw and not releasing it.
It's entirely possible that there is a blackhat group or groups, which we will probably never discover, that is harboring hundreds or thousands of unreleased vulnerabilites. Such a group would have immense power, the ability to disrupt the information systems of nearly every company on the planet, on a whim, or when hired to do so.
Open source, with it's ease of finding flaws, reduces this "true window" of exposure.
It's easy to fall into the trap of believing that all security threats are script kiddies running tools against well known vulernabilities, since the majority of the attacks reported are of that nature, but that doesn't mean that the threat of a true blackhat group doesn't exist, and couldn't be devestating.
Re:Another viewpoint (Score:3, Informative)
Open source, with it's ease of finding flaws, reduces this "true window" of exposure.
No, this is wrong.
Open Source INCREASES the window of expousure. With open source everybody, the good "examiner/reviewer" and the bad attacker, has he ability to find a flaw by analyzing source as soon as the source is released.
With closed source the attacker needs to analyze the assembly code or needs to drive black box attacks from the outside.
The "window of exposure" is in both caes the same, the flawed system has "a flaw" since it is installed and running somewhere and such it is open for an attack even if no one ever will know how to attack it.
If YOU like to distinguish between (hypotetical) window of exposure and true window of exposure you have to conclude that the true window of exposure is in OSS bigger.
angel'o'sphere
Multics VM/Paging PW Redux and Real World (Score:3, Insightful)
Well, Duh (Score:2, Insightful)
Granted, it may be easier to find and fix bugs in open-source software, but that doesn't mean that a well-designed, well-coded, throughly-tested closed source program can't be relatively bug-free and secure.
Equally secure? (Score:2, Insightful)
He also says (S3.4)
He then links (maybe speciously) the DRM stuff surrounding TCPA as one of the micro-effects which might skew things. I tend not to agree with him, but you don't go publicly disagreeing with Ross Anderson without thinking lots and reading lots more.
Disclaimer: I work for HP, and have an interest in the Trusted Computing Platform, so I'm probably biased.
--Ng
Maybe... (Score:4, Interesting)
Pros:
Closed-source: No one can see your code, thus eliminating obvious exploits (buffer overflows, race conditioning, etc.) from being quickly jumped on. Less chance that an external developer will accidentally or intentionally misuse some of your libraries or otherwise write in exploitable code.
Open-source: Everyone can see your code, thus allowing a multitude of additional glass-box testers to help patch things more quickly to adapt around problems a project leader may/may not see. Quick turnaround on patching of code.
Cons:
Closed-source: Limited field of testers; slower turnaround on bug/exploit fixes when even reported (can go on unreported for months, or even when reported, may be ignored or shelved indefinitely).
Open-source: Since everyone can see your code, some black-hat punk is invariably going to find some exploit and blast your distributions for it. Also, QA is nigh impossible to timely enforce when 100's of developers submit patches, sometimes anonymously.
Opinion: Both may seem to be even; however, the timeliness of a fix can make all the difference in security, and waiting days vs. weeks or months for a patch can make or break an information-driven business. Also, even if an open-source project is patched with an exploit ingrained, there will still be a quick turnaround on patching it, as there is for any bug. IANA genius, but at least from a business standpoint, it would seem that quick and usually-reliable beats slow but usually-guaranteed.
Re:Maybe... (Score:3, Interesting)
For example, more valuable data is stored on MS machines than Linux boxes right now. Of course they're going to sharpen their skills hacking the MS box more.
In my opinion it also has something to do with the MS-hate common in the hacker communities.
(I know using MS as an example is not a good one since their software...well, let's not go that way. But my point is, it depends a lot on what the black hats want to do.)
HA HA HA HA (Score:2, Insightful)
If he truely said this... Then the report is laughable.
1) Windows is open-source, because the bugs are easy to find. But you can not fix them.
2) He changes all common meanings, so the report can be used as FUD.
Is he a CS major or MS major? (Martketing Science)
Re:HA HA HA HA (Score:3, Informative)
If he truely said this... Then the report is laughable.
It doesn't take long to verify, you know....
Acroread->Search->"Idealizing"
No occurences of 'Idealizing' were found in the document.
Conclusion: wherever that text comes from, it's not the paper being discussed. More luck next time.
(-1, Lazy) for not doing the search yourself
Which tend to be patched faster? (Score:4, Insightful)
Oversimplified, abstract, and useless (Score:5, Insightful)
I am not sure how much value this has. There are a lot of other considerations.
With open source you have the source, so you can do something about bugs, you can fix them. And you can also look for potential issues in the code. You are in control of your own security. And a potential attacker has no idea what you've done with your particular implementation.
With closed source you are completely dependent on the vendor to provide fixes. First you have to prove to them that something is wrong, then, if you are lucky, after some period of time, the will provide a udpate which may or may not fix your particular problem. They may not be as motivated as you would be to fix the problem.
I'll take the Open Source choice any time. That way the people who care about security are the ones in control of security, an arrangement that is likely to work better than any other.
But at least "he acknowledged that real-world considerations could easily skew his conclusions. "
The old saying... (Score:2, Insightful)
In theory, there's no difference between theory and practice. In practice, there is.
Supporters in the Linux community have maintained that open-source programs are more secure, while Microsoft's senior vice president for Windows, Jim Allchin, argued in court that opening up Windows code would undermine security.
The two things are nowhere near the same. 'Open source development' is not at all the same thing as 'closed source development, opened up later.'
People complain about posting without reading, but that's it--if it's from news.com/ZD/etc., it's wrong. :-)
That should read (Score:3, Interesting)
All software has security vulnerabilities. Software with vulnerabilites is secure as long as nobody knows about the vulnerabalities or nobody exploits the vulnerabilities. Security is a process, not a state. To run a secure system, you have to know as much about the vulnerabilities as the hackers. You have to patch your systems. You have to manage your risk.
All it takes is one hole in some piece of software that you are running. If somebody knows about it and hacks you you are insecure. There are channels for discussing security vulnerabilities for both open and closed source software. Holes in both open and closed source software get patched. In that respect they are equally secure. There are more holes in both. It doesn't matter how many holes, it only takes one. In that respect they are equally insecure.
Insightful article from IBM Research on this topic (Score:2)
While the article is over 2 years old, the logic behind the man's reasonning is still very actual and he raises some good points.
Security isn't the only advantage of OSS (Score:2)
Maybe it's more secure, maybe it isn't. I think security depends as much on the humans who set up and use the system as it does the software. But security is just one selling point.
If you don't have the source, you can't modify the code. All you can do is configure. (Well, unless you like hacking binary.) But if you have the source, you can de-bug, add features, remove unwanted features, etc.
And if you don't have the knowledge, skill, or desire to do this on your own, does it hurt you any to have the source available?
There's another sense in which having the source code makes you more secure: you're not tied to the vendor. If they go out of business, you don't have to go shopping for a new vendor who has a similar product that you'll have to migrate to in order to enjoy upgrades, patches, and tech support. If they decide to add features to a new version that you don't like, you can branch the code off and keep your house version however you like it.
There's a zillion reasons to prefer open source software. It's not just about security.
Re:Security isn't the only advantage of OSS (Score:3, Interesting)
This is an interesting point. In my own efforts to get open source software used around the office, source has always been a non-issue.
Having the source, its kinda been like, "ohh, we get the source too? Well. yeah, thats great or something"
When we look at new software, its basically about it being "free" as in "free from cost". Essentially it doesn't matter how minor or major a bug, we will never, ever, ever modify the source. In fact, we never ever compile from source to begin with. we just grab the binaries and go.
So surprisingly, I think you'd find in many cases in the "business world", no one cares at all about having the source - unless they explicitly intend to modify it.
Yes, I know that having the source can help in many cases - the product falls from popularity into disfavor and disrepair, you have a specific bug you want to fix, etc. But unless you have skilled C/C++ hackers on the payroll, having the source is pretty much an academic discussion.
Thats no say it doesnt affect overall security and stability - it probably does - but for an individual company, or an individual person, its really moot about 99% of the time.
Bugs are inevitable, of course (Score:2)
The other great thing about OS is you -yourself- can fix the bug. No, not everyone is a kernel-hacker, but theres many bugs in small programs too.
IE: Not too long after I had first installed linux, I found out I couldn't play a certain DVD with any DVD player (Ogle, MPlayer, Xine, etc) although they played all of the others ones perfectly. The program was libdvdread (I believe) was dying on a failed (and completely unnecessary) assert(). So I opened up the sources, commented that line, recompiled, and wa-la, I could watch it now.
So, yeah, there will always be bugs; some OS products may even have more because they're made by people in their spare time (ie: apps like Ogle); but regardless, because there's many more eyes on it, bugs can (and generally are) fixed a lot quicker....
bugtraq reference (Score:5, Insightful)
All this shows is that open source software has had more bugs discovered and fixed than we would have liked there to have been in the first place. It has no relation at all to the number of remaining undiscovered bugs, and therefore no relation to the security of the software in question.
It's simple:
Assumptions:
1) When written, open source and closed source software have on average the same number of security bugs.
Observasions:
1) The number of security bigs in a piece of software only decreases when they are fixed.
2) A security bug is typically fixed after, and as a result of it being discovered. (they can be fixed by accident, but i will neglect this as it's irrelivent anyway)
3) Closed source software and open source software can both have bugs discovered by trial and error style cracking.
4) Open source software can have bugs discovered due the sheer numbers of people with access to the source.
Conclusion:
1) I conclude that open source sofware will tend to have any bugs discovered more quickly because there are more ways to discover them, and all ways available to closed source are also available to open source.
Can anyone fault my reasoning? It seems to me that both start equal on average, but open source will tend to have the bugs removed more quickly.
Re:bugtraq reference (Score:4, Insightful)
True, but just because they can doesn't mean that they do. One of the great myths about open source is that *anyone* can just dip in and discover a bug and how to fix it. That simply isn't true.
I can find bugs in closed and open source bugs in exactly the same way, by using the product until something wrong or unexpected happens. But just because I have access to the source doesn't mean that I could actually fix the bug.
If you look at projects such as Apache and Mozilla, they tend to have a number of people who know the code very very well and a few that given a couple of hours might be able to work something out and a very large number of people who, in the whole grand scale of things, are of no use at all in providing a fix to a bug.
This contrasts to a large number of individuals in an organisation who know the code very well and work with it day in day out.
Finally let us not forget that whenever people talk about security they often use Apache and IIS as their examples. Be aware that these are not really good examples. Not all OSS projects are of Apache's quality and not all closed projects are of IIS' quality.
You've ended up picking one of the best in the OSS world vs one of the worst in the closed world. It would be a little like compairing Ford's best car with Vauxhalls worst. Just because the Ford won all the time, does it mean that all Ford's are always better than all Vauxhalls?
(I think Vauxhall is Opal in the US)
Parent
Re:bugtraq reference (Score:3, Interesting)
Doesn't that really mean that the bugs will just be discovered more slowly?
It is harder to find bugs by trial and error than by reviewing the source.
Can you explain how you arrived at that conclusion.
MS patches most bugs in their products before their is an exploit
How can you know that unless you have access to internal Microsoft information? Almost without exception the updates that I have seen from Microsoft are a reaction to problems found by others. The patches I assume you are talking about are the ones MS fix and we never hear of. How do you know they exist?
I accept your point though that the "2 ways" I talked about of discovering bugs for OSS applies to all people, not just white-hats.
To be fair. (Score:2)
As always, the answer is..."It depends" (Score:3, Insightful)
Open Source software often depends on a somewhat less uniform and disciplined (but can often independently more disciplined than their commercial counterparts). There is usually less formal organization. This is where it really depends on the quality of work of the people working on these projects.
Because Open Source projects are less sensitive to the market and the bottom line (in general, except for the projects undertaken by commercial entities), they are not as likely to have quality problems because of lack of time.
But to say that Open Source projects have less bugs because more eyes are looking at them is a pretty big assumption. Just because more eyes can look at something doesn't mean more eyes will. The bugs can stay in Open Source projects for years before someone finds a problem - in this case, I'd say it depends on how popular this project is and how attractive is it to people who will look at code and look for problems and can understand what to look for.
If anything, in a short-cycled, less popular piece of software, a commercial software can have better quality than an open source one if the commercial developers are disciplined and dedicated. It is simply a matter of time.
A more practical view (Score:5, Insightful)
1. Bind hole (root exploit at the time, now it's chroot'd and running as named.named)
2. ftpd (root exploit, I turned ftpd off)
3. telnetd (root exploit, turned it off, too)
4. openssh (root exploit, simply recompile of new version)
5. current Apache bug, which even if it's an exploit is far from root or anything else useful
That comes down to a problem to be fixed every 6 months or so. This is real world. It doesn't matter a rat's ass to me what all shows up on Bugtraq, what matters is if someone is going to be able to hack my boxes. Most of the "bugs" aren't going to leave me open to remote exploit.
Given that, it's ludicrous to say that my setup is no more secure than a Windows/IIS setup. IIS updates come out weekly, sometimes requiring reboots. I literally don't have the time that it would take to run Windows here.
And IIS is probably the most-hacked piece of Windows. Want to compare it to Apache? Apache runs as nobody.nobody on most systems, or perhaps www.www. How about IIS? Hack Apache and you're an unprivileged user who'll have to rehack the box from the inside. Hack IIS and you're the Administrator. Even if Apache was as exploitable as IIS, it still wouldn't be as big a deal.
Michael
It's Exactly like the Movie Spider-Man (Score:5, Insightful)
Look... why is it that highly paid movie editors who poured over Spider-Man for many months with millions of dollars, couldn't find what the movie viewing public did in the opening weekend? According to movie-mistakes.com:
That sound remarkably familiar to Eric Raymond's Cathedral and the Bazaar? When Spider-Man was checked for bugs by the highly paid editor (programming team) and none were found, did they not exist. Is the movie inherently more flawed when the bugs were found and reported by the viewing public (open source programmers)?
Closed doesn't stay that way. (Score:3, Insightful)
doesn't mean the source code is not available.
Crackers aren't afraid to decompile code, or use social engineering to obtain it.
Non disclosures mean nothing to someone who is writing a virus.
But it does stop the white hats.
That asymmetry makes a big difference in the analysis.
In open source the white hats and black hats are on equal footing.
In closed source, the black hats have an advantage somewhere
between alpha and 0, depending on how hard it is to obtain the source.
Historically, it's been proven over and over that obtaining the source is much easier than the original designers thought,
which is the reason security through obscurity is treated with such derision in the crypto community.
Most bugs are found by people running the code.
Most security holes are found by people who are looking for them.
Since Black hats have no real difficulty obtaining the source,
"Closed" source gives them a huge advantage over their white hat counter parts.
-- this is not a
security orthogonal to development model (Score:3, Interesting)
I suspect that you can generalize this to security, as well. OpenBSD focuses on security, and it shows. Microsoft doesn't, and it shows. This is not a matter of proprietary v. free.
Re:In Other News (Score:2, Interesting)
I mostly agree with him however I like open source software for more reasons than just the fact its "more secure". Often OSS software isn't in fact more secure or reliable. Look at mozilla. Its a great project but its not as nice as IE by a long shot. Anyone using 1.1a in Linux will know that [e.g. me! while at the same time 0.9.9 works fine... ???]
tom
Re:security and OS's (Score:3, Insightful)
The Mac Classic (as far as I know) does not offer a web server, network databasing, remote shells, etc. If it does, the Mac OS (9 or before that the Classic runs on) is not stable enough to provide these service reliably: there's no memory protection, and there's no way to log in remotely to fix problems. If those services were provided on the Mac Classic, you would have seen remote root exploits happening.
Another way of putting it -- what can you do on a rooted Mac Classic? That's like somebody rooting my watch. There's nothing to do with my watch once it's been rooted, and in any case, my watch doesn't really offer the ability for remote control, much less a root environment versus a non-admin environment. Whoever's sitting at my watch (or whoever my watch is sitting on) has control, and there is no other option.
Also, root exploits are not the only exploits. Crashing a computer remotely is an exploit also (one thing root exploits are used to achieve). Even if the Mac Classic does not offer a remote shell (as far as I know), how hard is it to crash remotely? I worked in a Macintosh computer lab, where the Apples went down constantly because of bad network data. We sometimes couldn't put particular protocols on the ethernet because OS 6/7 couldn't handle it. I suspect that if people tried, it would not have been that hard. (I'm not anti-Apple -- I think that most every kind of computer has appropriate uses).
Since Mac OS X offers the afore-mentioned services, I suspect that if its use increases, we'll start to see remote exploits happening. This has nothing to do with it being Unix based -- it's a result of what I said before -- any system which offers services or grants selective access based on an identification can and will be exploited.