OpenBSD 4.8 Released

Mortimer.CA writes "The release of OpenBSD 4.8 has been announced. Highlights include ACPI suspend/resume, better hardware support, OpenBGPD/OpenOSPFD/routing daemon improvements, inclusion of OpenSSH 5.5, etc. Nothing revolutionary, just the usual steady improving of the system. A detailed ChangeLog is available, as usual. Work, of course, has already started on the next release, which should be ready in May, according to the steady six-month release cycle."

Comments

Re:OSNews? Thom Holwerda? Seriously?

[TheRaven64]

For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack.

The OpenBSD base system includes a version of Apache that has been heavily audited (fixing a lot of bugs that didn't seem to get fixed in the main branch until years later - look for 'does not affect OpenBSD' in security advisory notes) and runs in chroot by default.

Is lighttpd any more secure on OpenBSD than on Linux? No

As I recall, lighttpd runs in a chroot by default on OpenBSD, but I could be wrong. On top of this, it has (probably not a full list, just the things I remember):

• Address space randomisation, making return-to-libc attacks harder. Linux now includes a weaker version of this.
• OpenBSD's malloc() has an aggressive policy about returning memory to the kernel, which trades some performance for making it much harder to exploit use-after-free bugs.
• The OpenBSD system compiler enables stack canaries by default and they are enabled for all OpenBSD packages, making stack-smashing attacks basically impossible.
• W^X policy means that you can't map a page as both writable and executable at the same time. This is implemented even on x86, where it requires some convoluted stuff with segmentation because there is no native support in the page tables. This makes anything with a JIT compiler marginally harder to write and makes arbitrary code execution holes much harder. Linux can enforce something like this only on newer systems that have support for the NX bit in page tables.
• The network stack uses strong random numbers for a lot of TCP/IP header fields, making things like connection hijacking or SYN flood attacks harder (you said you were running a networked app, right?).

And the best thing? You don't need to configure or even understand any of these for them to work. That's what 'secure by default' means - no faffing with SELinux configuration, no optional security measures that people turn off because they're too hard to get right.

I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.

In practice, SELinux is usually disabled. In the few places it is enabled, it makes the attack surface larger and has led to exploitable bugs that are not present in Linux-without-SELinux.