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 405319
To read all comments associated with this story, please click here.
Mark Williamson
Member since:

The article is actually pretty interesting as many of the points raised had some insight behind them. That said, whilst the article argues that removing all bugs is not a substitute for a powerful security framework, it's also the case that a powerful security framework is not a substitute for removing bugs! Specifically, if any (kernel, probably) bugs creep in that enable you to influence supervisor-mode code in malicious ways or to execute your own code in supervisor mode then there is nothing a security model can do - if you can run code at the highest machine privilege level then you really can do anything, no matter what user ID or security framework you're running under.

It's true that a security framework can constrain e.g. processes running as root that get compromised, in order to prevent them from causing more widespread damage. But if you don't have proper auditing of *all* kernel code, from the system call interface through your USB feather duster driver, to your memory management and filesystem code, you can safely assume that somebody will be able to find a way past it.

Reply Score: 5