Linked by Thom Holwerda on Thu 21st Jan 2010 19:24 UTC, submitted by Anonymous
OpenBSD "OpenBSD is widely touted as being 'secure by default', something often mentioned by OpenBSD advocates as an example of the security focused approach the OpenBSD project takes. Secure by default refers to the fact that the base system has been audited and considered to be free of vulnerabilities, and that only the minimal services are running by default. This approach has worked well; indeed, leading to 'Only two remote holes in the default install, in a heck of a long time!'. This is a common sense approach, and a secure default configuration should be expected of all operating systems upon an initial install. An argument often made by proponents of OpenBSD is the extensive code auditing performed on the base system to make sure no vulnerabilities are present. The goal is to produce quality code as most vulnerabilities are caused by errors in the source code. This a noble approach, and it has worked well for the OpenBSD project, with the base system having considerably less vulnerabilities than many other operating systems. Used as an indicator to gauge the security of OpenBSD however, it is worthless."
Permalink for comment 405502
To read all comments associated with this story, please click here.
Mark Williamson
Member since:

"mmap at 0" - does this mean being able to map physical address 0 (which would be bad), or simply "use mmap as memory allocation" (which I can't see a reason to disallow)?

For compatibility with various other OS ABIs, Linux *can* allow userspace processes to mmap stuff at virtual address zero which would otherwise usually be left unmapped IIRC. There's a knob in /proc/sys, I think, that lets you control whether this is allowed.

But there was some peculiar interaction whereby this knob wasn't used on RHEL systems systems where SELinux was enabled. RHEL's SELinux itself *could* enforce the same constraint if configured in policy but if it was missing from the policy then the constraint ended up not being enforced at all. Or something like that. This might be RHEL-specific.

Source (which has links to further details and details of the folks who worked on tracking down the security problems - Brad Spengler, Tavis Ormandy and Julien Tinnes):
Specific details on the RHEL problem: had a proper article about this stuff as well but I can't find it.

Disclaimer: This is probably a hopelessly mangled explanation since I only half remember it :-S

Reply Parent Score: 2