Slashdot Mirror
OpenBSD 3.5 Released
pgilman writes "The word just hit the announce@openbsd.org mailing list: "We are pleased to announce the official release of OpenBSD 3.5.
We remain proud of OpenBSD's record of eight years with only a single remote hole in the default install. As in our previous releases, 3.5 provides significant improvements, including new features, in nearly all areas of the system" including security, hardware support, software ports, and lots more. Support the project if you can by ordering the cds, or grab it from the net (use a mirror!). Thanks to Theo and the whole team!"
I use Linux on almost all my systems, but nothing can cut the security I get using OpenBSD on my firewalls and routers. I can't wait for SMP support to be working.
Chose only the packages you will be using, not the ones you might use some day but aren't absolutely needing it. Usually a port that has an absolutely horrible track record might not make it in, or if it has a gaping security problem it might be marked as BROKEN.
Use common sense, chose packages of software you have faith in to not suck.
- Configure, maintain and secure your routing protocols and interfaces in one easy to read and edit configuration file.
- Store the configuration in solid-state flash memory.
- Upgrade the entire OS by TFTP'ing a single file.
- Provide support for many types of LAN and WAN interfaces (DSx, hardware accelerated ATM segmentation and reassembly, etc.)
- Provide support for layer 2/3 QoS packet tagging in hardware (on ALL WAN interface types i.e. ATM, Frame, DSx) to reduce CPU load on distribution routers.
- Handle IPv4 traffic routing in hardware, with the OS just maintaining flow state information.
- Provide support for the plethora of legacy protocols that are on corporate networks (DLSw, X.25, etc.)
When the only tool you have is a hammer, everything looks like a nail.-Pat
What was it?
OpenSSH.
Tarsnap: Online backups for the truly paranoid
OpenBSD (and all the rest) don't need moving parts, except for the power supply fan. VIA Eden chips can run without a fan, and there are other chips from other architechtures with similar specs. The hard drive can be replaced by a flash IDE drive if your space requirements are small enough.
Cisco still wins on speed when all you're doing is routing, and in many other situations, but the firewall isn't that impressive.
Not necessarily, it runs on a lot of different architectures... Xeon's, Opterons, PowerPC, MIPS, etc. If you didn't have to patch, uptimes of years wouldn't be a problem.
I rarely criticize things I don't care about.
I found this part of the release notes particulary interesting:
OpenSSL now directly uses the new AES instructions some VIA C3 processors provide, increasing AES to 780MBytes/second (so you get to see a fan-less cpu performing AES more than 10x faster than the fastest cpu currently sold).
I don't know if the fanless assertion is right (the AES instruction is available in the newer (step 8?) Nehemiah processors, which I don't think there is a fanless version yet on the market.) Of course someone will prove me wrong.
Now all VIA needs to do is make a network centric Nano-ITX board (drop the video, audio, firewire, usb, etc etc, and add in two more good ethernet ports), and this could be a serious IPsec/VPN platform.
-truth
I had a steady B+ in my AI class until I failed the Turing test...
ok....
Very recently the head of our IT department decided that we were going to switch every one of our networks over to Windows XP Professional.
Hmmm.... ok. I guess that's possible.
We had previously been running OpenBSD on all our quad processor Xeons.
*bzzzzzt* You are either lying or dumb. Why install OpenBSD, which I admittedly love and am not biased against, on a quad processor system when SMP is in like alpha stage, beta at best? Because you're trolling or have no idea what you are doing. Next!
-truth
I had a steady B+ in my AI class until I failed the Turing test...
Let's begin hacking this one apart :P
:P not.
1) Devry... nice..
2) A company capable of buying quad xeon hardware doesn't sound like the kind of cmopany that needs to resort to running a workstation OS--XP Professional--on a server. Plus, Windows XP will only use 2 CPUs maximum.
3) Like mentioned before, you'd never run OpenBSD on an SMP box in a production scenario
4) What kind of password? The Windows XP password has nothing to do with Dell. If you mean the BIOS password, that has nothing to do with Windows.
5) Microsoft's multi-user computing (read: NT Domains/Active Directory) is actually quite good.
6) If your server had three years of uptime, there was probably (I'm sure there wasn't but I don't want to be wrong) no OpenBSD SMP support (not even beta) 3 years ago... I wonder how your boss feels about a server having 75% of its computing power being unused.
There's more wrong with your post, but why bohter...
You have to take into account OpenBSD has privsep, stack protection, W^X memory, and a myriad of other security features not present in most other *nix systems.
Taken together, a large chunck of potential remote exploits become much less serious problems because the exploit isn't capable of root'ing an OpenBSD box. Sure, a DoS vulnerability is nothing to sneeze at, but it sure beats getting rooted. Same vulnerability will that will root a linux box, will often only annoy the living hell out of an Open box, and you'll still see a patch faster for OpenBSD.
--Nuintari
slashdot : where an opinion can be wrong.
Yes, lack of security holes makes anything secure, this is quite obvious. However, how can you know you don't have any security holes? The answer is simple: you cannot.
If you call chroot a poor kludge, you're obviously not a security guy. Granted, it's not perfect, but it does help a little. Ever heard of the principle of the least privilege? The idea, that programs shouldn't be allowed to do anything except what they need to do? Well, taken to the extreme, this would mean:
- Program should declare what syscalls it uses, what libraries it needs, etc, and no other syscalls/libraries would be allowed.
- Program should declare what kind of access it needs to the filesystem to function. No other parts of the "real" filesystem should be visible in the program's namespace at all.
- Same for every other resource such as sockets, etc...
This could be achieved through a manifest file of some sort, which the kernel would read and interpret. It could be part of the program image itself. This would be truly beautiful, however anything that implements any of the above is a GOOD thing.
You're saying chroot is giving a false sense of security. So, shouldn't the people be educated about what it solves and what it doesn't, then? Obviously it's a good feature, it just isn't intended to be a solution to everything. Just a solution to one problem: filesystem namespace visibility.
Configure, maintain and secure your routing protocols and interfaces in one easy to read and edit configuration file.
.doc file, no matter how it is done.
:). And they have some tech support, too.
One file, more files, what is the difference? If the config files are well organized, which they are, there is no reason to have it all in one file.
Store the configuration in solid-state flash memory.
Get a CompactFlash card and a CF-to-IDE adapter.
Upgrade the entire OS by TFTP'ing a single file.
Could be done, you would need twice as much disk (CF) space as you need for a single installation, then download the new OS, unpack it on a free partition, swich default partition for booting, reboot. Ok, perhaps noone has done this until now. Perhaps it's because noone really needs it, not even the people who use OpenBSD on all their routers.
Provide support for many types of LAN and WAN interfaces (DSx, hardware accelerated ATM segmentation and reassembly, etc.)
Provide support for layer 2/3 QoS packet tagging in hardware (on ALL WAN interface types i.e. ATM, Frame, DSx) to reduce CPU load on distribution routers.
Handle IPv4 traffic routing in hardware, with the OS just maintaining flow state information.
Why do you need to do all this in hardware? Most of this stuff can be done in software a strong enough CPU and IO. The rest that can't be done in software is probably not used by majority of Cisco users (see below for more).
Really, you are building these requirements in such a way that OpenBSD cannot comply. It's a bit like saying that OpenOffice will replace MS Office if the third submenu in the 'File' menu is 'Open', when you click on it, go 102 pixels down and 53 pixels left, click, select the third option, and it reads 'Microsoft Word (.doc)'. What you really need is that it opens a
Provide support for the plethora of legacy protocols that are on corporate networks (DLSw, X.25, etc.)
Not everyone needs those, and the majority who do not can use OpenBSD. The rest will probably use Cisco anyway, but it may just not be enough for Cisco to survive. Thus "Cisco killer".
In fact I don't think this will happen, as the strong Cisco feature is that they sell everything in one package, unpack and plug and play
The only really special thing about Cisco hardware as compared to a PC is that their backplane has traditionally been much faster than anything a PC has had to offer, and they have offered network cards (or blades in the Cisco parlance) with more ports (since they are larger) and with additional processors on the cards which do routing themselves. (Layer 3 switch blades, for example.) It's nothing you couldn't do on a PC, though, there just hasn't been a reason to. The most modern PCs have an extremely fast bus however, in the form of 66MHz/64 bit PCI, and now PCI-Express is coming along and the wider versions of that are even faster from what I understand.
Anyway, since when do routers not have moving parts? Every Cisco product beyond the SOHO level has at least one cooling fan. A cat5k (I pick on it a lot because it's what I have most experience with) has, like, eight plus one per power supply. Meanwhile, there are PCs without any moving parts - A cisco PIX 520 would be one of these, if it didn't have a power supply fan, because it's just a PC in a custom rack case, with an expansion card with a flash ram disk on it, and some Intel EEPro 100/B Management Adapters in it. (Someone told me once that tulips work too, as they were used in older pix 520s, but I've never seen that before.)
So the short form is "no", the computer architecture won't make an OpenBSD router less stable than a Cisco one. The only thing that might would be OpenBSD itself.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
There are unofficial ISO complilations of OpenBSD available is you want to search around for a bit. Or you could buy the official 3 CD pack and support the project that way.
/i386 for run of the mill x86 cpus ), and set them up on a local web or ftp server. 'dd' the boot floppy image to a spare disk ( floppy35.fs will suit 90% of cases ), boot up with this on the system, and simply follow the prompts for the ftp/http install. Or you could simply do a ftp install from a local OpenBSD mirror across the internet.
I think the easiest way to do an installation ( I ran 3.5 up on an old p-166 this evening ) is to download the arch-specific install files ( ie everything under
For detailed info on the install, see the FAQ.
The Errata page should be checked regularly too. Unlike the 3.4 release that had a number of bugfixes that needed to be applied as soon as it was officially released, 3.5 has no need for further patching at this point in time.