I don't really have time to answer your other points, but systrace is in the base system, and to my knowledge it has never been in ports. So yes if you do a fresh install of OpenBSD 3.2 or later you will get systrace.

See eg http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/systrace.c

The problem is not a lack of an implementation, but not any implementation will do. It has to be suitable, and meet the OpenBSD project goals.

AppArmour and RSBAC are GPL. Trusted BSD is rather large, relies on some FreeBSDisms, and IMO is overengineered, I think it would be quite a hard sell, but there may be useful ideas. The fact is that even if something useful can be pulled out of Trusted BSD, someone is going to have to put in the time and do it. The reason they might do this, thankless or not, is because they want some sort of MAC in OpenBSD :-).

I think there is a fair amount of FUD on both sides. A few people do try to make out that MAC is a critical security component, when in fact it is merely a useful tool, and as all discussions so far show, it is far from being universally loved or adopted.

systrace is a good example of my point, despite being attacked by some developers, it was added to the kernel and base system, and recent discussions on removing it have decided to leave it alone despite its problems because it is useful as a ports debugging tool.

With due respect, I think both you and the author of the "insecure" article have some fundamental misunderstandings about OpenBSD and the way the project works.

Just to note I don't speak for the project here, this is just my impressions from being involved for a short time.

Firstly, jokes about theocracy aside, OpenBSD is not a dictatorship. There are a lot of developers, and they don't all agree about everything.

So, even if some OpenBSD developers say they are skeptical about MAC, it doesn't mean all are, or that there is no way to salvage it, or that any code involving the term MAC would be dismissed out of hand. It just means that as it is now, well, they are skeptical. And nobody has appeared with suitable code to change minds. And perhaps that developers are tired of hearing about it from people who manifestly aren't going to contribute.

Secondly, in OpenBSD, contribution drives everything. People who write articles or feature requests or posts on Slashdot are taken much less seriously (if they are taken seriously at all) than people who contribute to the project. Many other OSS projects are the same, but in OpenBSD it is very plain.

Thirdly - and this is something most people seem to miss - any MAC implementation must meet the projects' goals (which are something that no current implementation I have seen does, and certainly not one which anyone has submitted code to implement in OpenBSD). At least it must: be good code; be appropriately licensed; be simple and understandable; be documented; and (important!) be secure by default.

So, if you sit down, design and write a MAC framework that meets those criteria, it will be properly considered. You will have to fight your corner, of course, and make a case that persuades others why it is useful, and accept review and make changes if necessary, but if you are prepared to do the work it will be taken seriously - it may not be accepted, but it will be given a lot more weight than writing an article about it.

The fact is that until someone is prepared to stop talking and hack on MAC support, this whole thing is really a nonissue inside the project. All developers have their own interests (sometimes many of them) and at the moment it is clear none of them care enough about MAC (whether it has benefits or not) strongly enough to get involved.

Of course you can order a CD and then download. Buying a CD is a way of supporting the project, not just an installation mechanism.

It is a volunteer project - there is only one full time developer - and like all such it is a compromise between support and new features, and it happens that at the moment most people prefer doing development rather than maintenance. If everyone was interested in maintenance, OpenBSD releases might have a longer lifetime, but development pace would be considerably slower.

The fact is that as OpenBSD, unlike Linux, does not have large commercial backers, so unless people donate their time and money to work on the things they consider important, it becomes unlikely to happen. Perhaps you would like to donate some of your time to supporting older releases? I can say with some confidence that if you prefer just to complain, most OpenBSD users and developers will care very little for your opinions.

Note that there are commercial organizations providing OpenBSD support if you require it.

I don't know where you get your ideas about poor hardware support, OpenBSD hardware support is not hugely worse than, for example, FreeBSD, and better in some areas.