NetBSD being a secure OS, yet having a large list of vulnerabilities in its software.

[rocket357]

This happened to OpenBSD in February of 2007...note the dates:

# 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
# 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.

And later on Core managed to upgrade the bug to "arbitrary code" vulnerability:

# 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
# 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.

http://www.coresecurity.com/content/open-bsd-advisorie

[TerryP]

Originally Posted by c_moriarty

I'm assuming that bugs and security issues would be reacted to more quickly in certain Linux distributions (Fedora, OpenSuse, Ubuntu) than they would be in FreeBSD or NetBSD... Isn't that correct?

This is debatable and likely ass-backwards at that.

When FreeBSD or NetBSD have a security issue to fix, they can commit it whenever they need to, and notify all listeners to update their systems. The whole process could take ${time to fix bug} + 5 minutes. This is the advantage of near-total control over your distributions source.

Fedora on the other hand can report the issue to the maintainer and wait for a fix, optionally committing one or more of their programmers to help fix it (not likely for most rpm). Then wait on that patch to be included by the upstream maintainer (Linux kernel, Samba, etc), and push it out to all listeners. The whole process could take ${time to report bug} + ${time for upstream to fix bug} + ${time for fedora maintainers to notice bug fix} + ${time to make new RPM}. This is the disadvantage that your product is made up largely of other peoples products.



Stuff in the ports collection works the same way as Fedora. In the case of Debian folk, the process may look more like: Ugh, bug. Fix it -> maybe tell upstream -> give all users own patched version of code -> upstream tells us we created 5 more bugs and have brain damage. No offense to other Debs .




If you don't like compiliation from source, you will want

• To relax your interest in security, source and its integrity is GOD.
• To not use a SOURCE based OS.
• To find a distribution with a well defined security policy and a Rapid Response Team that sleeps on the desk of upstream security issues.

If you just don't like the time it takes to compile stuff from source, buy a faster computer. If you think that's stupid, let me point a finger to a box across the room that has a 500Mhz CPU and note it compiles a hell of a lot slower than the multiple multi-core Xeon processors the build box at work uses for compiles.

[qmemo]

Originally Posted by TerryP

If you don't like compiliation from source, you will want

• To relax your interest in security, source and its integrity is GOD.
• To not use a SOURCE based OS.
• To find a distribution with a well defined security policy and a Rapid Response Team that sleeps on the desk of upstream security issues.

just out of curiosity, which OS/OSs fits that profile ?

[TerryP]

If you find one, let me know!

[qmemo]

THOUGHT SO

[c_moriarty]

Well, right now Fedora 14 has been out for quite a while.
When I install Fedora 14 right now and update it it has 850+ updates. Software is also updated very regularly (not that much at once, of course, but as far as how long it takes before a few pieces of software come up as needing updating, it usually takes 2 or 3 days).
When I had NetBSD installed, I just let the vulnerable packages be installed and waited for at least 3 days and nothing had changed except one update to Python, which still left it with a vulnerability.
That seems like a very dramatic difference in response, to me.

[qmemo]

@c_moriarty
Re-Read the entire post, the answer you're looking for is out there && if you were just re-stating what you have already asked about and the honourable users/admins answered you, then I do not know what the heck I can say about that :P

[rocket357]

Originally Posted by c_moriarty

When I had NetBSD installed, I just let the vulnerable packages be installed and waited for at least 3 days and nothing had changed except one update to Python, which still left it with a vulnerability.
That seems like a very dramatic difference in response, to me.

How many of the vulnerabilities are in core NetBSD? Do some research...

Search CERT for vulnerabilities. I just did, and here are the numbers:

Vulnerability warnings:
OpenBSD - 295
Solaris - 306
NetBSD - 319
FreeBSD - 389
Mac OS X - 397
Windows - 1110
Linux - 1400

Or perhaps the National Vulnerability Database:

OpenBSD - 165
NetBSD - 186
FreeBSD - 432
Solaris - 680
Mac OS X - 1450
Windows - 2600
Linux - 3462

Which one looks better now?

[ocicat]

Originally Posted by c_moriarty

When I install Fedora 14 right now and update it it has 850+ updates.
...
When I had NetBSD installed, I just let the vulnerable packages be installed and waited for at least 3 days and nothing had changed except one update to Python, which still left it with a vulnerability.

Again, there are a number of fallacies to your argument.

• Software updates do not get published only as a result of identfied software vulnerabilities or identified solutions. Software updates can occur because some other piece of software has been updated, & this cascades into a number of libraries, etc. needing to be updated as well. Red Hat apparently does this piecemeal -- releasing updates as they are deemed ready. The *BSD projects tend to aggregate applications changes to formal releases.
• Most Linux distributions attempt to emulate Windows in being a complete desktop environment -- meaning that a lot of extraneous applications have been installed which the user doesn't know about. Many of these "updates" are upgrading applications which are not even being used.
  
  In contrast, most of the *BSD family are installed in a minimalist fashion & the user must consciously add chosen applications. While this does not mean that the user will understand all that is added, there is a higher probability that they have some idea. More fundamental to this thread, the number applications potentially needing updates is smaller. The 850 number originally quoted doesn't necessarily translate. It really appears that you are comparing apples to oranges.

It appears that you have made up your mind & are more comfortable with the piecemeal policy implemented by many Linux distributions. Great. This is your choice. Choice in the marketplace is a good thing, but I challenge you to look at this list of 850 updates & answer whether these are all pertinent to your particular situation.