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!"
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.
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.