"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."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-08-08
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).
Member since: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.
Member since:
"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.