Re: OpenBSD business model

Peter Fairbrother wrote:
[...]

> Except the shite
> security model, but it's about the best that a *nix can do.

I've had a lot of (well, five) (six now) off-list requests for more on this, so here it is.

The *nix security model is bad. This is a property of all *nixen, not just OpenBSD, so don't take it personally. This is not a flame, and neither was my original post.

To give a trivial example or two, boot a *nix box from bsd.rd, mount a drive - you can access anything on it. Anyone with a root password can access anything on the box (yes, there are OS's that don't have these properties).

To get a little more technical, the body of security-critical software is so large in *nixen that it's impossible to verify it.

The development of *nixen and the associalted software (and especially C) was done with little regard for security, and the legacy of that is that there is a lot of code that's flawed from a security point of view.

OpenBSD try hard to correct it, with code reviews, systrace (if used!), propolis, PROT_* purity, etc., and by and large you do a good job, but bolting security onto a broken model isn't the way to get security.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

For instance, the code review. Sounds great, and in practice it has improved security a lot - but it only takes one flaw, one missed bit of code, and it's broken. Application software doesn't go through the review procedure anyway, except for things like OpenSSH and (I assume) Apache.

Or the reliance on trusted developers. From a recent email: "The main issue we have is validating people so that they get commit access." Trusted, in the security world, is a bad joke, meaning "a part of an otherwise secure system that can break the security of the system".

*nixen have lots of advantages, eg drivers are available, there is a body of software that can be (fairly) easily ported. But the security model is fundamentally flawed.

OpenBSD is doing about the best job possible to make a secure *nix (1), but not to make a secure OS. Try EROS for that (but it's almost unuseable due to lack of development... and lack of the years of work that went into *nixen.

You pays your money (if you buy the CD's, which I do) and takes your choice.

-- 
Peter Fairbrother

(some stuff on how the business model affects security, ignore if you like)

(1) Though it could be improved. If there were more security-inclined
developers (and I can't count the number of good security types and coders
I've met who _won't_ contribute to OpenBSD because of the "business model"),
you might make OpenBSD even better, and more secure.

(2) Theo, on the new security stuff:
"We'll be writing a real paper about all of this later, but perhaps now
people will understand why we are excited about 3.4." (later he said "3.3
too")

But it'll take more than a few months to get it right. 3.3 probably won't do
it, but the release schedule means it will be released anyway.


The open-source security model relies on people inspecting the open source,
but with a release every 6 months a lot of people who might take the time to
do it won't bother, as it's too much work for too little gain.
 
Code maturity is also important for security, and a six-month release cycle
isn't the right way to get it. Afair, this was a cause of the "remote hole".

Just my 2c.