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!"
Just get a grip on diskslices. You'll laugh at everything else. The installation is beautyfull.
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
Hey, you need a smiley. The folks here are often humor-impaired, and would't recognize irony if it whumped them upside the head. You're most likely to just get a "troll" rating unless you make it obvious that you're writing with tongue in cheek.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Stolen from a slashdot post I saw long ago:
.
If you want x86, then just download it from the OpenBSD ftp site.
wget -r ftp://ftp.openbsd.org/pub/OpenBSD/3.0/i386/ Makes it easy.
Once thats done...
cd ftp.openbsd.org/pub/OpenBSD
then...
mkisofs -v -r -l -L -T -J -V "OpenBSD-3.0" -A "OpenBSD v3.0-Release, Custom ISO, 17-03-2002." -b 3.0/i386/cdrom30.fs -c boot.catalog -o openbsd-i386-3.0.iso -x openbsd-i386-3.0.iso
Burn that ISO!
The recommended method is creating individual partitions for /, swap, /usr, /home, /tmp, and /var. Deciding the appropriate sizes for each of these partitions when you have no experience is probably the hardest part - but there's plenty of recommendations online. Personally, I'd recommend 80MB for /, 300MB for swap, 500MB for /tmp, 1GB for /var and split the rest between /usr and /home (/home is where most of your personal files will be stored and /usr is where most packages are installed).
All of the comands are well doccumented during the install if you type 'help'. The only other thing that could cause some confusion to somebody new is that by default all drive input sizes are by hd sectors - Not Bytes. The simple way to avoid calculating everything is just append all partition sizes with a 'M'. This lets the system know that your number is in Megs, not sectors.
Hope that helps you out some.
My guess would be that the military will either take OpenBSD, combine it with some code from the NSA, and make a really secure OS, or take some code from it and add it to an OS they already use.
And my guess is that they will simply use OpenBSD out of the box, thus incorporating whatever developments are made by the gov't funded OpenBSD programmers.
I need to choose my words wisely here, but the govt isnt the big spender it used to be, at least in terms of developing their own solutions. Especially in the military, there has been a big move to use COTS based components whenever applicable. Command and control systems are running off of NT systems nowadays.
Back when they were running on Legacy systems, yea, alot of applications were made "in house". But you would be surprised if you were to walk through a modern military facitlity or a government agency the amount of x86 based hardware laying around.
I lost my concept of community when my community lost all concept of me.
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
DARPA funding for BSD goes way back -- long before OpenBSD, FreeBSD, and NetBSD existed. One of the most important instances was DARPA's funding of the development of BSD's TCP/IP network stack back in the mid-1980's. This made BSD the first system in wide deployment that supported TCP/IP. It's hard to overestimate the affect that this has had on Unix and the Internet since then.
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!
NetBSD may support more platforms, but OpenBSD covers the most popular ones.
The vehicle analogy is more than somewhat flawed. You mention weapons, but the truth is that all are stationary systems, that can be attacked by anyone, and can't move out of the way. They do not wear down after tons of successful attacks, but rather are either broken with one, or remain perfectly intact at full strength. I could go on, but there's not much point.
As for the logo, I'm pretty sure the blowfish comes from the widespread use of Blowfish encryption in OpenBSD. The master.passwd uses blowfish by default, OpenSSH uses blowfish as one of the top cipher choices, blowfish is used to encrypt the swap partition (if encryption is chosen), etc.
If the OpenBSD team thought they were making a tank, they just might have used a logo of a FREAKING TANK.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.