An argument against OpenBSD, qmail, et al.

[catch]

Actually you are; you suggested that perhaps QMail and OpenBSD, while not being particularly vulnerable pieces of software, may be being used incorrectly (your confidential email example, as one example of what I'm talking about).

How is this using it incorrectly? Should OpenBSD not be used in instances where users may have access to private information and have some ability to export this information? Should OpenBSD not be used in any situation where an internal user may be malicious or stupid? This really narrows down its use, wouldn't you say?

I think you are somewhat confusing the issue by discussing security from a 1000 ft perspective in the same paragraphs as security from a 10 ft perspective. A lot of people seem to have mistaken your statements as referring to vulnerable software, whereas I do understand you are talking about secure software.

Since I am discussing both validation (security) and verification (vulnerabilities) both are relevant. Unfortunately the two may sometimes be interchangeable.

Consider the trojan example. If OpenBSD had a specification it would state something similar to: "Subjects shall not be granted specific access to a given object unless the permission explicitly (owner) or implicitly (group/world) allow it." In the trojan example, a user is able to access files they did not initially have access to, without the owner intentionally granting them. Is this a security issue? Should the specification have stated that copied and new objects cannot be granted permissions beyond their owner without a formal change management procedure? Or is this a vulnerability issue? The access control system was not robust enough to have prevented this attack?

You could argue the issue either way as either approach would have prevented the specific hole.

The real issue you are trying to put forth here is not anything OpenBSD or QMail have dominion over, and lies wholly under the control of the administrator.

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

If you are simply saying that vulnerability-free software isn't enough to ensure a secure system, well duh, I thought that was obvious.

You'd think this should be obvious... yet the vast, vast majority of security focus is on vulnerabilities. Particularly with the examples of qmail and OpenBSD, just because they have few vulnerabilities they are claimed to be secure.

Quite frequently in my experiences as a developer, I've encountered situations where formal development models fail rather easily. For instance, you get one piece of bad analysis, and an application is broken and probably stays that way until a redesign.

I agree with you here, unfortunately the reasoning behind this is more about the way corporations work and less about how formal models work.
Typically the specification is thrown together by someone who used to be a developer and they were such a good developer that they moved up to the architect/designer level. Unfortunately most of the skills required to be a good developer are not so useful as an architect. I can't tell you how many times I've spoken to engineers from large corporations that have really bizarre specs.

Infact one that I saw recently, the client had a very bizarre spec on the hardware portion of a project. They wanted something like a 120' 3.72" coax cable of some type. (I have no idea how much you know about physics so I'll explain.) A very bad attempt at a poor man's phase matching. They figured if the length of the new cable was the same as the other (of a different type mind you that actually needed to be that long) that the phase would be the same. Unfortunately this isn't true (different dialectrics, etc) and it put the new cable (which only needed to be about 6' long) under the noise floor. On the surface it would seem to have made sense, but not to a person who actually knows how to design such things. Long story short... blame the Peter Principal for your flawed specifications as companies prefer to use their own engineers as architects since "they are already familiar with everything."

Beyond all of this, there are exists several tried, true, and proven security models out there... and if none suit your needs, it has been my experience that a project with a custom formal model laid out by professionals familiar with such things and can develop proof of their model will be a much better and frequently cheaper, product... not to mention having a more predictable development schedule.
A bad model can ruin a project and scar all involved, and that is just plain unfortunate... but when you consider that every model should be expressed as a verifiable equation, there really is no excuse for such mishaps.

cheers,

catch

[barrywilliams]

i started reading your intro post, but then 1/4 way through i raelised you have no clue about OpenBSD - so I can't be arsed reading the rest.

in the environents that I have seen recently, there has been an increase in OpenBSD usage. this might be because of all the recent publiscity Theo got. the US gov. Him getting the Open Source accolade from Stallman himself. who knows.

what sets OpenBSD apart from the rest is the developers and their efforts into the code. it has nothing to do with them being ultra super amazing coders but probably more to do with the fact that they devote alot more time and effort into checking the code that goes into it. so you don't have the same issues crop up as in other coder shops where the coders are foced to work very fast, and as soon as the thing is kind-a done, out it goes and the next project starts work. if anything crops up that is not kosher - no problemo we will release a patch until the thing's life cycle dies.

bah!

got onto their usenet & channels are read some of the communication, you might get a better picture.

[d0pp]

I can't be arsed reading the rest.

Wow...

You know what? At least I am a troll with a ****ing clue. Goddamn... You're cranky AND ignorant.

what sets OpenBSD apart from the rest is the developers and their efforts into the code

There are more things that set OpenBSD apart. Although, with how obviously 1337 you are, you probably know all of them. I mean... just read their usenet posts.

[gore]

You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth".

Oh and "It's Free" yea, as long as you buy the CDs.... Or do the FTP install... No remote wholes in 7 years in the default install.. Does that REALLY say something about an OS that boots up without anything even open to begin with?

I haven't been robbed in over 7 years, maybe because I walk around with an SK-47 and no money.... Wow I'm secure!

Maybe I can be a walking turnip like Theo now and have morons kiss me...

[rcgreen]

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

Man, that's not even a computer issue. I could memorize the doc, write it out longhand,
and put it in the post. There's no technological solution to something that is a moral problem.

[catch]

There's no technological solution to something that is a moral problem.

Aren't essentially all security issues, moral issues? Does this mean we shouldn't bother?

The implicit attack of course is a trojan or otherwise rogue process that attempts to export confidential information.

cheers,

catch

[Galdron]

Originally posted here by gore
You know, **** theo, he took Net BSD, said he didn't like where it was going and they told him not only where it was going but where to stick it, so he went over it, did an "audit" added some **** to it like Open SSH, made a boot up where everything is turned off which any monkey can do in between banana peels, and said "Look what I did I'm secure and the most secure OS on Earth.

So many people reckognize a problem, and go on a tirade about how "insufficient" it is. This guy took it on as a challenge.

This is something more people should do to approach a situation.


Don't bitch about it........FIX IT!


$0.02


P:

[Maestr0]

First, there is no such thing as 100% secure code, and there never will be, anyone who thinks otherwise has lost their ****ing mind and needs to get out of this business.

How many of you knew what a Heap Overflow Attack was five years ago? Would you have though to test if such an attack could violate your security policy having never heard of such an attack? No amount of informal verification can overcome this lack of perfect knowledge and the potential infiniteness of the implicit rules.

Second, how dows FTLS help against this? If you dont know the flaw exists how are you supposed to insure its not there? The full extent of format string vulns werent truly realized until around 2000, and those flaws had existed for years.

Third, even with a FTLS, people are going to make mistakes. Period. Humans write and check the code, while automated tools can go a good way removing some of the common vulnerabilities listed, some of these flaws exploit weak validation in one function that is 11 logical blocks away from the vulnerable function. Finding these flaws takes careful scrutiny from some of the industries best minds who have years of experience. You think every code monkey in the industry has that level of skill, and has the ability to forsee and remove these flaws?

Fourth, in these days of proprietary code almost every large scale project has to rely on functions, libraries and other forms of shared code, to which you do not have access to the source code. Its that or reinvent the wheel a thousand times. It is immpossible to verify this code will behave the way you expect and that it meets your security standards or that you are not inadvertantly introducing a vulnerabilty into your code by including this code, and that includes the operating systems themselves.

I'm not saying stricter guidlines on security practices and formal verification procedures are bad, far from it, but there are no silver bullets, and formal specifications always look good on paper, but as your own examples show, good software can produced without them, and I assure you bad software can produced with them.


-Maestr0

[cacosapo]

OFF TOPIC

Originally posted here by spurious_inode
[B]The enterprise security topics that I am pretty hot on right now are Role Based Access Control (RBAC), and true privilege separation. Unfortunately both of these things have the same problem; they are typically proprietary (e.g. Sun's RBAC) or they don't really 'work' like they should in multiple platforms (e.g. NIS+ netgroups).

Sun RBAC is really a crap. Try to read instead BMC Control-SA software. You will be really surprised how a RBAC can be powerfull. But this is subject for another topic.

[chsh]

Originally posted here by catch
How is this using it incorrectly? Should OpenBSD not be used in instances where users may have access to private information and have some ability to export this information? Should OpenBSD not be used in any situation where an internal user may be malicious or stupid? This really narrows down its use, wouldn't you say?

Erm, I wasn't taking that standpoint catch, which should be rather obvious as below I went on to state such things are implementation specific.

Since I am discussing both validation (security) and verification (vulnerabilities) both are relevant. Unfortunately the two may sometimes be interchangeable.

Consider the trojan example. If OpenBSD had a specification it would state something similar to: "Subjects shall not be granted specific access to a given object unless the permission explicitly (owner) or implicitly (group/world) allow it." In the trojan example, a user is able to access files they did not initially have access to, without the owner intentionally granting them. Is this a security issue? Should the specification have stated that copied and new objects cannot be granted permissions beyond their owner without a formal change management procedure? Or is this a vulnerability issue? The access control system was not robust enough to have prevented this attack?

I think this is rather obviously a security issue (not vulnerability) for two reasons:
1. It requires that some person or vulnerable piece of software running on the OS already had higher privileges to get the trojan access to the rights in question.
2 The operating system itself is still doing its job as intended.

You could argue the issue either way as either approach would have prevented the specific hole.

No, I don't really see how you could. The Operating System is not there to catch network or system design flaws, or really, breaks in third party software. IMO you're looking at situations security wise as totally wrong. You appear to have this idea that security is a wall where certain software introduces holes. It's generally much safer IME to believe that security is a LACK of a wall, and you have to put it up with as few holes as possible. This applies even to existing systems.

How do you figure? How can an administrator ensure that private documents are only emailed to addresses with the rights to view them? This is specifically a design issue.

It's a design issue that has nothing to do with QMail. Your example is bad because it is really taking issue with the RFCs that dictate how E-Mail servers should operate. People have known for a long time there are problems with the system, just like with IPv4. None of these issues have anything to do with QMail. Perhaps a better example might be situations where you can make parts of QMail vulnerable (it's been done courtesy of QMail's awesomely moduled nature, btw). The thing is, at that point, it's no longer QMail that's introducing the vulnerability.

You'd think this should be obvious... yet the vast, vast majority of security focus is on vulnerabilities. Particularly with the examples of qmail and OpenBSD, just because they have few vulnerabilities they are claimed to be secure.

If I were to expand on my wall building example above, as I see it, using something I can count on as secure to a degree (you can never do it fully) lets me the builder keep the wall in good shape. Keep in mind also that the focus on vulnerabilities is largely due to the fact that software isn't going to react badly when you announce that it is a holey piece of shite (*coughIIS5cough*).