A second remote hole for OpenBSD [LWN.net]

A second remote hole for OpenBSD

Posted Mar 15, 2007 12:01 UTC (Thu) by k8to (subscriber, #15413)
In reply to: A second remote hole for OpenBSD by bluefoxicy
Parent article: A second remote hole for OpenBSD

I believe OpenBSD does enable RPC by default. At least it did at some point in its history and did not incur any holes. I find this impressive myself.

But I think the "no default remote holes" is really trying to draw attention to two different things. OpenBSD has good engineering in the security department and tends to avoid compromises and exploits. We are all aware of this aspect of it, though some feel this sloganing is not very indicitave of that fact. But I think it is _also_ drawing attention to the conservative installation policy. Perhaps we are ignoring this aspect because the limitation of exposure is now the default thinking across most Linux variants and most Unix admins, but I can assure you it was not 10 years ago.

In other words, it may be that this slogan has simply gotten a bit out of date in that most unixes no longer foolishly turn on all kinds of services open to the world. Or at least most Free unixes.

(Log in to post comments)

it's just a beta

Posted Mar 16, 2007 23:39 UTC (Fri) by gvy (guest, #11981) [Link]

> Fedora
One should know he's in er... testbed when one installs Fedora. Consider bringing up IPv6 by default, which is even worse a security setup/maintenance nightmare than I would have though night before.

There are more OpenBSD-like Linux distros like Owl and ALT, where basesystem is additionally audited and tools like control(8) are in place to facilitate retaining admin-specified permissions on potentionally privileged binaries -- like "public/wheel/wheelonly/restricted" for su(8). Those that wouldn't crash-dive into 2.6 kernels and apache 2.0 when that would really be too much grief for reasonable sysadmins.

Disclaimer: I participate in this spring's ALTLinux release, as usual, but have long disliked RHL and Fedora for practical reasons (with much respect to Red Hat, of course).