Slashdot Mirror
OpenBSD: Hackers Meet Soldiers
BSDForums writes "OpenBSD has a well-deserved reputation for fanatical security. Why is the U.S. military funding it? What do you get out of it? Cameron Laird and George Peter Staplin investigate and talk to Theo de Raadt, the creator, overseer, and taskmaster of the OpenBSD project!"
Ok, before I get started, let me say that OpenBSD developers and users have no patience for people who aren't willing to read documentation, since they pride themselves on it (even man pages) being extremely well written and kept up to date. If it's not, file a bug, and _IT WILL GET FIXED_ (of course if it's just _your_ problem, then don't file a bug regarding the project, file one in your own bugtracking system as something you need to work on).
That said, the following FAQ explains the installation process far better than anyone writing you email ever will be able to, including a complete install process in grey, which has example responses in bold [for the most part]. If you can't get it from this, then you aren't reading, and it doesn't matter if someone writes you an email message with the same thing (written more poorly no doubt). If you can't read and follow instructions, then OpenBSD is not for you, and honestly - you shouldn't bother.
Most people don't have this problem, but there are always some feeble minded folks who think that life is easier if they're spoonfed on IRC and the like. To such people: you aren't welcome. The answer to this attitude has already been given: don't ask questions that already have explicit, clear answers publically available.
If you have a problem with the instructions (not enough detail supplied, typos, etc.) then please let the OpenBSD developers know about them in order that they may be corrected. If _you_ have a problem, in that you can't understand them, well... maybe it's _JUST YOUR PROBLEM_. It might be something that you need to work on. Of course, there is an opportunity for things to be unclear, and in such cases - again, submit a bug: "such and such statement regarding fdisk is unclear, suggest more detail on partitioning so that xyz is unabiguous"
Now, if you -want- to install OpenBSD, go read:
http://www.openbsd.org/faq/faq4.html
Why not? They've tried it with Windows nt, which didn't work, so maybe there's more trust in open systems since then.
Unless OpenBSD has the magic ability to "do what the programmer meant, not what he wrote" when encountering a divide by zero, the Navy's application would have crashed in exactly the same way on OpenBSD too.
If you want to criticize NT, fine, go ahead, but you don't have to make stuff up.
And DARPA is also funding Reiserfs v4 development.
-- kryps
Way offtopic here now, but it was Ken Thompson, not Donald Knuth. Here's the discussion in question: Reflections on Trusting Trust.
Also a summary entry in the Jargon File, for those who don't want to read the paper: http://www.catb.org/~esr/jargon/html/entry/back-do or.html
This is actually a very simple thing to do. Any OS designed for minicomputer-class hardware (e.g. VAX, RISC or 386+ CPUs) will include this magic ability (including NT). Such OSes will only crash if there is a bug in the OS itself, or in code that is treated as part of the OS.
One of the flaws with UNIX and NT, as compared to systems like VMS (with four protection modes) and Multics (with up to sixty-four protection rings), is the existence of only two protection modes: User and Kernel. This means that code which requires elevated privileges must be given the same privileges as the kernel itself, since Kernel mode is the only alternative to User mode.
This problem of only two protection modes is deeper than the OS design, however. Most RISC CPUs provide only two modes (the x86 provides four rings; the VAX provided four modes), so in order for an OS to be portable to such architectures, it must be limited to two modes like UNIX. This is probably why NT, which was designed by the architect of the four-mode VMS system, itself only supports two modes (like UNIX).
Remember that UNIX was considered very buggy and unstable in the 1980s, where as VMS (which is a younger system) was seen as rock solid. This reflects the design advantages of VMS, in being tied to the VAX architecture, with its four protection modes and robust instruction set, but that reliance on the VAX architecture was also a major weakness: unlike UNIX, VMS could not be ported to most RISC architectures, or the 386, and so only runs on VAX and Alpha. Both of these architectures support the four modes it requires, but are now niche CPUs with declining user bases. This limited hardware support was the most important reason for the decline of VMS, where as the portability of UNIX and NT were very important factors in their success.
UNIX, BSD, Linux and Windows 2000/XP show that a system with only two protection modes can eventually become stable, through simplified design and/or extensive testing on supported hardware configurations over time, but there is always the risk that new hardware will introduce new device-driver bugs, which automatically become new kernel bugs, thereby reducing any of the OSes to an unstable disaster again. The broader the hardware support is, the likelier it is this will happen.
If Linux had been created back in the 8088 days, either today's Linux would be incompatible with its legacy apps, or its stability would be comparable to Win9x.
Linux, as we know it, could never have been created on an 8088. In fact, the minimum x86 processor necessary for Linux is the 386. Linux, like Unix, requires virtual memory, preferably page based, and memory protection.
Linus deliberately set out to create himself an OS that followed the Unix model. He was unhappy with the Unix-like x86 OS implementations of the time and created his own. He clearly had in mind that his system would do as Unix does, not just look like Unix. You can make DOS look like Unix if you install enough GNU utilities, but it is fundamentally not Unix.
In a very real sense the stability of Linux, as derived from Unix, is by design, not simply because the coders are somehow better. By design, Linux proper can not operate on an 8088, and for good reason.
Note: today there are derivatives of Linux that can operate without hardware support of virtual memory. One important example is uCLinux. On systems without memory protection or VM support in hardware, the kernel suffers the same vulnerabilities to failures in user-land code as would DOS. These appeal of these systems is that they provide the POSIX API on very limited VM-less platforms.
Maw! Fire up the karma burner!
Not really.
If you need to read from a device, a user account can be given access to a device entry. If you need access to a file, a user account can be given access to a file.
Do you understand what happens when you access the device entry? Your user-mode code, running under whichever account, makes a request to a kernel-mode device driver, which then controls the hardware. The device driver runs in kernel mode, with the same privileges as the kernel itself. On a system with more than two privilege levels, the device driver could run with more privileges than user code, but fewer than the kernel.
Then there is privlidge seperation. You can write a small, secure piece of code that runs as root, and invokes other, more complicated programs, with only the limited privlidges that program needs. Then there is systrace, which is simply a flexible, universal version of priv. sep., but nothing stopped you from doing the same before systrace came about.
There is also cylant, which has a purpose similiar to systrace, but go a bit of a different way about the same goal.
You are confusing software permissions (e.g. user access rights) with hardware privilege levels.
You VMSers really get on my nerves (yes, all 5 of you). Just because the kernel doesn't have the different levels of access built into it, does NOT mean that you are limited to two levels. It's just such a popular method because people are lazy... VMS would be just as vulnerable if admins got lazy and used only 2 of the privlidge modes.
This is fundamentally wrong. A hardware privilege level is not the same thing as a user account.
So, your claim that VMS and multics have better security
I did not claim this. I claimed that a system which offers more than two privilege levels allows device drivers to run with more limited privileges than the kernel, thereby allowing for a more robust architecture.
is like saying that MS-DOS can't be networked... Just because it isn't built-in doesn't make it impossible. In fact, I find Unix more secure because of the fact that privlidge seperation *is* seperate from the kernel. Then again, you can still be lazy and not make use of it.
Your comments dont make sense, and show that you dont understand difference between hardware privilege levels and user accounts. UNIX relies on hardware privilege levels, just like other OSes.