Thnaks for clarifying that.

Wow, what article did you read?

The article does address "PID randomization, ASLR, and extensive support for chroots" as well as secure levels. There is a whole section devoted to these technologies. The whole point is that are all aimed at preventing attacks from happening, and that there is no way to sufficient lock down a system in the event someone does get in.

An EACL at the kernel level is not any more of a bolt on solution than rewriting Apache to have privielge sepration or adding in executable space protection. OpenBSD is only useful as long as you don't stray outside the tiny base system of audited code. If you run 3rd party software which has a hole that gets exploited, then you're FUBAR

You may not agree with the article, but don't say the author did not address the protections available already within OpenBSD when he clearly did.

I understand that any MAC implementation for OpenBSD must of course be compatable and meet OpenBSD guidelines. IMO, that is a secondary problem at the moment. The first problem is that the team of developers are outright hostile and do not understand MAC.

Until that is resolved, no one in their right mind would try and write anything MAC related for OpenBSD. I suspect the developers don't wish to resolve it however, and are happy with their stance.

I agree there may be FUD on both sides, but having too much faithe in MAC is hardly FUD, while dismissing it without understanding it certainly is. I could understand the project not wanting to implement MAC as not being useful to their target audience...but to dismiss and attack it is just stupid.

Anyway, I thought systrace was not in the base system, but in ports? Are you saying that if I do a fresh install of OpenBSD 4.7 and don't install any ports, I will have systrace available to use?

Nope. Not at all similar in terms of capabilites. Securelevels are a pale imitation of what you can do with MAC, not even close.
If you really think securelevls are at all close to MAC, then you really don't understand MAC.

It's not putting up walls, it's enforcing secure policy and good practice, and sometimes the law.

Sepeartion of duty, read up on it.

Hi, I really appreciate your reply. Thanks.

I understand your point, and that OpenBSD is not a dictatorship and that there are some interested in MAC, but just skeptical, and I have to disagree.

I am quite sure without exception, on the mailing lists on the big debate in 2007 and that insecure article that without exception every lead developer stated that MAC is at best does not offer any additional security, and at worse is false security actually making things worse.

It is such a poor understanding of such an import security technology that it makes me sad for the project that is meant to be focused around security.

Not a single lead developer...Theo, Bob Beck, marc Espie etc...they were not skeptical, they outright acctacked it and dismissed it...just spreading FUD.

I understand that someone would be heard if they were to actually contribute and show something rather than whining or discussing it, but if this is the episode given by the representative developers and the user community, why would anyone even begin such a thankless task?

Let us not forget, they have the trustedbsd project at their disposal, as well as other software like apparmor and rsbac which is meant to be portable. The problem is not the lack of an implementation, but an outright fear and rejection of MAC for bringing unneccesary complexity to the table.

Just look at systrace, most of the lead developers attacked it, despite some of the users finding it useful/interesting. Given the cold reception minimac got, I would hae to see the reaction someone attempting to port TrustedBSD or so would receive.

It would be pretty funny though if someone were to fork OpenBSD as SecureOpenBSD with MAC...

Until the developers and to a lesser extent the suers bother to understand MAC and stop outright attacking and dismissing it, I can't imagine anyone even considering writing a MAC framework for OpenBSD. It truly does seem a thankless task, which is a shame as it would significantly enhance OpenBSD's capabilities and usefulness to outside of the firewall/router scenario.

MAC will most certainly keep an exploit from destroying users permissions. You can think of it as permissions not being based on users, but perr application/objects.

Lets say a user exploits Firefox...you would think the exploit would have full access to the users files right? Nope, not so. With MAC, there could be only write access to a downloads directory, no execute access except for a whitelist of files, and only append access for the rest. If the exploit tryied to delete anything, it would fail. Can OpenBSD do anything remotely similar?

Unfortunatly for the examples you gave, neither OpenBSD nor MAC can do much to protect against something like a database, where it is a program that handles storing records outside of the filesystem, and thus scope of the OS and MAC.

Hi, I should have been clearer. When I say it is a story slashdot should have ran, I meant ran as well, certianly as a seperate story.

I do think the issue is interesting and deserving of its own discussion though.

(I think there are about 200 comments, but only the initial comment is counted)

I also think the article is more than just pointing out the lack of access controls, it is also against the secure by default policy, strl calls, lack of ways to lock down a system, lack of auditing etc...

The reason access controls are needed for a secure system is because access controls are about more than containing external intruders....

How so? They limit their auditing to the base system. Securelevels and DAC are not sufficient to lockdown a system, as where MAC can prevent damage from being done in most cases. I'm not ignorant of OpenBSD and Unix security, and use OpenBSD quite a bit and agree with the article in general.

1. The fact that the OS code is audited is nice, but can't protect against other insecure software. If you run postfix which isn't audited, and it has a hole and the attacker gets root, then there is nothing to stop them.

2. An example from a commenter on the blog is that he needed to prevent root from reading users files. OpenBSD is almost the only OS left that can't meet this requirement.

3. Auditing, along the lines of what OpenBSM provides. This isn't related to MAC, yet the team still doesn't implement it...

It isn't unusable to start with, your just attacking it because you personally don't like it. Additionally, an argument for MAC is not bolting features on after the fact. If it is properly implemented, it is in the kernel to start with. Unlike, say, rewriting Apache over 10 years to have privilege separation, which is adding it on after the fact.

Ahh, so nothing is incorrect, you just don't understand MAC

The archaic UNIX security model is exactly that, archaic. There are needs it cannot meet, and something like MAC is needed.

It does provide increased security by enforcing proper separation of duty and privilege correctly, not adding it in later as OpenBSD has done.

I love OpenBSD, but to dismiss MAC as a waste of time just serves to discredit yourself.

Ubuntu is not unusable regardless of what features they decide to leave out, while the argument is made that OpenBSD is insecure because of features they do leave out. So, the analogy doesn't quite work.

What in the article isn't true?

It would just be nice if they extended their definition of security to be more than preemptive bug fixing.
The article I linked to above is a good discussion of this. Given how they flat out reject MAC, and the reasons they give for doing so, it seems they know very little about actual security.