“OpenBSD is an ultra-secure, freely available, multi-platform BSD-based UNIX-like operating system. And is arguably the most secure operating system in the world. After using OpenBSD for over 9 years I decided to place online some useful information for first time users of OpenBSD. The information here covers the current release of OpenBSD.”
Very nice. Good looking easy to navigate page. Hell, I bet an NT admin cound install OpenBSD now
.
-nX
The Changelog of their upcoming 3.8 release can be found here:
http://www.openbsd.org/38.html
However, I heard on many forums on the Web that OpenBSD is not as scalable (performance-wise) as Linux, and that’s one of the reasons why its adoption has been hampered. Anyone know if there’s any truth to this?
Yes, OpenBSD is a nice os but you are correct, it does not scale as well as Linux, NetBSD, or FreeBSD, also, networking performance tends to be poor.
OpenBSD is great for a low volume server, but it does not handle massive ammounts of traffic well (although I believe this is improving).
OpenBSD has a lot of potential but the developers tend to be very closed minded to new things.
“Yes, OpenBSD is a nice os but you are correct, it does not scale as well as Linux, NetBSD, or FreeBSD, also, networking performance tends to be poor.
OpenBSD is great for a low volume server, but it does not handle massive ammounts of traffic well (although I believe this is improving).”
There’s only one caveat I would add to that — for very complex firewall rulesets, in my experience OpenBSD’s PF can handle more packets per second than Linux’s IPTables on the same machine. This is only for really crazy rulesets where the limiting factor is in-kernel packet classification performance rather than network driver performance, in most other situations I agree that Linux would probably handle high load better.
Depends on your definition of “does not scale”. Many people, including me, are using OpenBSD for pretty large servers, firewalls and routers.
Also, networking performance is not poor anymore and you could argue that at never was “poor”. At some point in time it was lagging in certain aspects (nothing that I ever noticed) but those problems has been fixed for almost a year.
“OpenBSD is great for a low volume server, but it does not handle massive ammounts of traffic well”
Obviously not true since it is used in many places to handle massive amounts of traffic. Of course, “massive” is a pretty vague term.
“OpenBSD has a lot of potential but the developers tend to be very closed minded to new things.”
This is just bullshit, plain and simple.
“OpenBSD has a lot of potential but the developers tend to be very closed minded to new things.”
I’m not sure if you intended the above quote as criticism, but to add my 2 cents…
The OpenBSD team is quite the opposite from how you described them. Their development practices are NOT closed minded but extremely disciplined with regards to “security by design” and what is allowed to be included into their code.
Gotta respect that.
> OpenBSD has a lot of potential but the developers tend
> to be very closed minded to new things.
Well, and why are the OBSD guys the only people that actively support such nifty security features like pro police, and other stuff?
There are similar capabilitys available for other Operating Systems, however the most popular Linux Distributions seem to totally overlook these.
I’d actually love to see some of the stuff from the Debian based Adamantix Distribution in the default Debian. Proactive security is not an option, it is obligotary.
“However, I heard on many forums on the Web that OpenBSD is not as scalable (performance-wise) as Linux, and that’s one of the reasons why its adoption has been hampered. Anyone know if there’s any truth to this?”
Yes, actually. OpenBSD is an amazing OS, and has probably the best quality control in the industry, but it is lacking in a few areas. It does not currently have a multi-threaded kernel, it does not have a unified filesystem/VM buffer cache, and it’s SMP locking is currently a single kernel lock, that greatly impacts performace on SMP hardware.
These will be addressed in time, I’m sure, ut for right now, the lack of these features does impact overall OpenBSD performance.
http://bulk.fefe.de/scalability/
Note that this benchmark suite is getting quite old and might not be representative of the current reality. Still, it can give you ideas from where it came and where it might be going.
Personally, I have hesitated between OpenBSD and NetBSD but I think I will settle with the latter with the OpenBSD utilities (OpenSSL, OpenSSH…).
Yeah, which you only get on OpenBSD…
*LOL* .. I guess that’s why I’m using them on GNU/linux.
The OpenBSD utilities runs on other systems than just OpenBSD.
dylansmrjones
kristian AT herkild DOT dk
Check out http://www.undeadly.org/cgi?action=article&sid=20050720120007 to see an 84-node OpenBSD cluster in action.
“Personally, I have hesitated between OpenBSD and NetBSD but I think I will settle with the latter with the OpenBSD utilities (OpenSSL, OpenSSH…).”
Despite the name, OpenSSL isn’t actually an offshoot project of OpenBSD like OpenSSH is.
http://en.wikipedia.org/wiki/OpenSSL#Misconceptions
Ah, that’s why they never made a “p” release… Well, I stand corrected.
Thanks to whoever posted that link, http://www.wbglinks.net/pages/openbsd/ sure is an eye opener to me. I never really saw OpenBSD in such an easy to understand manner. I’m going to give it a try tonight, wish me luck.
they audit their code for vulnerabilities before release.
If only this was standard practice.
– Jesse McNelis
It seems the OpenBSD programmers want the most security they can get using traditional techniques (e.g. “C”).
If the OpenBSD folks really cared about security and correctness, they’d use things like static typechecking and runtime boundschecking to ensure that they eliminate all buffer overflows — or other methods that you can prove will eliminate those classes of errors.
They won’t do this. I think this is the sort of thing that leads to them being called “close-minded”.
Unfortunatley, OS folks (Olin Shivers excepted) tend to be disinclined to such methods.
The oddest are folks like Dawson Engler, who used very lispy techniques (run-time code generation), but in “C”, in his exokernel. This got done away with — the extra speed wasn’t worth it, and non-ninjas couldn’t maintain it.
> If the OpenBSD folks really cared about security and correctness, they’d use things like static typechecking and runtime boundschecking to ensure that they eliminate all buffer overflows — or other methods that you can prove will eliminate those classes of errors.
First, they are doing runtime bounds checking (totally on the heap; partially on the stack).
Second, they are using static checking tools, too (they even developed some themselves !)
Third, static type checking does not prove anything anyway; it can detect errors but it will not prove a program does not contain errors. Indeed, there are methods to prove programs but it is a very lenghty (if ever doable) process on huge codebases such as OpenBSD’s.
Fourth, nothing will ever replace careful code reviews by human developers.
Fifth, it is a real-world project; not a university playground project.
Sixth, they probably have more experience in designing and maintaining secure software than you have, so they know better what suits their needs.
“First, they are doing runtime bounds checking (totally on the heap; partially on the stack). ”
That’s better than nothing. But much better would be writing critical programs that mustn’t have buffer overflows in a language that can be statically typechecked (and running with a runtime to make sure that array indexing errors don’t happen). You can get that any number of ways (e.g. use ML), but using “C” (even with ad hoc checks) is not as complete.
Although static type checking doesn’t fix everything, given that half of all security problems are due to buffer overflows, static type checking (or even dynamic) eliminates half of them, once and for all. If your goal is to critical systems correct (not just typesafe), you’ll probably be using a notation (language) different from “C” — you’ll want something that works better with your automated proof technology. This has been done already, for cryptographic protocols. But again, that’s not what OpenBSD folks want — they just want to hack “C”, as best as they can.
Your bit about it being a “real world” project is specious — that’s the same “logic” that MSFT uses: although OpenBSD does some critical things better than MSFT, because it is a marginal project (not quite a “university playground project” — but close) it is acceptable to ignore what it does better than Windows.
My original point is that although OpenBSD says security is their primary goal, that’s clearly not the case. If that was their only goal, their methods would be more attuned to the problem.
So, do you have a magic recipe to instantly convert *millions* of lines of legacy C source code to a “safe” language ? 🙂 And will this “safer” language correctly compile to all the targets OpenBSD currently (and in the future will) supports ?
Anyway, security is not a language problem it is a specifications problem.
And regarding C, it is the worst language except all of the others when it comes to systems programming. If you know of potential successors to C (that is, languages for systems programming designed to efficiently implement safe and potentially concurrent/real-time programs), please indicate them (honestly, I am very interested in those languages; I have already heard of ML but maybe there are better ones).
If your goal is to eliminate buffer overflows, you’d start with the critical stuff — stuff that runs at ring 0 and the stuff in userland that runs with root priviledges. I’m not sure how big that is.
You could rewrite ALL that code in a safe language, except for the drivers, which just have to work correctly. If you do that, you are done. If you want to do that, you probably start with the work these guys did:
http://www.cs.utah.edu/flux/
and just use their drivers. You write all the other crap (the kernel) in any modern language — just not “C”. This isn’t as awful as it sounds, because modern languages come with things like continuations, which make threads trivial:
http://citeseer.ist.psu.edu/wand80continuationbased.html
If you know what you are doing, it takes only a few hours to get ML or lisp running on top of bare hardware (using the drivers and boot loader of the OS Kit). Olin Shivers is the guy to talk to, and he’d probably be happy to hear from you.
If you use SML, I think you are covered in terms of platforms — but CAML has even better coverage. Or you use a system that translates the modern language to C+runtime (e.g. “bigloo”), which gives the most coverage, because it only needs a “C” compiler.
If that task is too big, you take the Coverity approach: write a tool to analyze the C code and identify potential errors. You might detect less errors statically (but use a runtime that does more dynamic checks). Or you force the programs to conform to a restricted language that the analyzer can read and confirm is OK. You could keep “C” in this case. If you can’t handle everything, you flag certain suspect parts of the program, and leave it for the humans to go and independently verify that all of those bits are OK.
I would figure that at some point the OpenBSD folks will be doing the second method.
As for actually using the Os Kit techniques, I’m guessing it would most matter in building embedded systems (e.g. a router) running on cheap hardware. The program is small (so there is less to rewrite). You’d want the modern language so that you easily could prototype/implement algorithms to get better performance. The average x86 OS fails both tests: the program to rewrite is too big to be worth it, and it is so powerful that performance is not key.
That kind of software testing happened in the first year of OpenBSD’s existance, quit trolling.
Infact, Coverity’s run through OpenBSD before and found it to be the best system for already being secure – do you not read or choose to troll?
You demand that I stop “trolling” — but I’m not trolling. Although you’ve been insulting, I’ll answer sincerely.
Coverity didn’t “test” anything. They used static analysis on the source code to identify some problems.
You seem a bit unclear on the benefits of static analysis vs. testing. To summarize, static analysis is different from testing in that you do it once and you get your information. With testing, the information trickles in as you test more and more things.
That’s the point of using programming language based methods: do it right and you never have to worry about buffer overflows.
I’m thinking particularly of the ssh flaw — that was a real hassle. Had ssh been written in a modern language, it wouldn’t have caused problems for the non-OpenBSD running sshd users.
Also, even though Coverity went over the source once, there are reasons why it could pay to do similar efforts again:
1. Coverity didn’t analyze everything — there are new kinds of flaws to look for.
2. The program has changed since it was analyzed. Perhaps there are new flaws to be found.
The fact that Coverity said that OpenBSD back then was a good product doesn’t mean much now — that’s in the past.
My original point is the same: if Theo wanted the most secure OS possible, he’d be using a different programming language. Instead, his goal seems to be to build the most secure OS he can, using “C”. That’s a laudable goal and I’m glad he pursues it.
I prefer NetBSD over them all but i would sooner use OpenBSD for firewalling tasks over linux anyday. In a firewall capacity having it scale is not that much of an issue.