security VS reliability .. what implicature ?

[daemonfowl]

Hi BDS Lovers !!

Security VS Reliability ..

while reading the errata page a week ago , a question came into my mind concerning the dividing line between a security issue , and a reliability issue ..
what does each involve ? what can a reliability fix be which a sec fix can't and vice versa ?
I'm sure the OpenBSD Team does not swap the two terms , nor do they use them gratuitously..

[jggimi]

Per the Computing Dictionary:

• reliability definition
  
  system
  An attribute of any system that consistently produces the same results, preferably meeting or exceeding its specifications. The term may be qualified, e.g software reliability, reliable communication.
• security definition
  
  security
  Protection against unauthorized access to, or alteration of, information and system resources including CPUs, storage devices, and programs....

The security definition continues with additional inclusions, such as confidentiality, authentication, non-repudiation and more; I will leave it to you to do your own research at http://dictionary.reference.com if you are interested in further definition.


As for OpenBSD, let us look at this simple Venn Diagram, linked from Wikipedia for expediency:



Assume that the set on the left is Reliability, and the set on the right is Security. The union of the two is where Reliability and Security are the same. In software terms, this is often areas where coding errors impact both. The effort to eliminate those problems is described as a drive for code correctness.

OpenBSD's security goals are described in www.openbsd.org/security.html, where the Project's Audit program is described. The text discusses the effort to establish and maintain code correctness:

"We are not so much looking for security holes, as we are looking for basic software bugs....During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable."

In summary, then, while the size of the union of the two sets is non-deterministic, I believe it is quite large, and I appreciate the Project's effort to strive for correctness as a cornerstone of both proactive security and reliability.

[daemonfowl]

Thanks very much Jgimmi !!
I bet the intersectional sphere is the outcome of the OpenBSD Team's strife to put coding parameters back on track .. so .. reliability is code correctness and security is system-wide correctness and both make up what might be technically labelled {a mature & stable OS} .. I am right here ? am I right to say that Tanenbaum diapproves of linux kernel because of this very issue ? code correctness .. while praising NetBSD .. the more one tries to patch and fix issues the more it gets worse until it reaches windows-like cases .. underneath .. I remember he used the word spaghetti .. as analogy ..
In what way am I wrong to characterize MacOsX (for instance) as a {reliabe+insecure} OS ?

[jggimi]

I honestly don't know, Daemonfowl. I perceive knf(9) and the audit program as ways to manage both problem/error sets, beyond their union. But these alone do nothing for third party applications (ports/packages), and in many cases, that's what we depend upon.

We rely on security technologies developed by and included with OpenBSD to help protect us from bugs in the OS or in third party applications, and those may have security implications. Example technologies that come to mind: ProPolice, W^X, strlcopy, malloc randomness. There are more. Most of these will function without modifications to third party software. Some, like strlcopy and its sister function strlcat, require active implementation in the source code, either by the port maintainer or conducted in upstream development by the 3rd party.

Some of these technologies will stop a flawed application from functioning, reducing the application's reliability but increasing the security and reliability of the overall system. This would be in a problem space where, from the flawed application user's perspective, the sets do not have a union.

---

I have no experience as a user of OS X (other than casually using someone else's workstation for short periods) and therefore do not know anything about either its reliability or its security. I know that it has closed source components, and, like any closed source program, reliability can be subjective, and perhaps anecdotal.

I can't talk to Andrew T.'s public pronouncements, since I haven't read them.

[daemonfowl]

Some of these technologies will stop a flawed application from functioning, reducing the application's reliability but increasing the security and reliability of the overall system

@Jgimmi , thanks again !!

concerning Tanenbaum's statement , look here please :
http://lwn.net/Articles/467852/

If you want to change the memory manager, only one module is affected. Changing it in Linux is far more complicated because it is all spaghetti down there.

as for Mac .. here is 1 reason why I mentioned it :
http://newsgroups.derkeiler.com/Arch.../msg00778.html
http://www.zdnet.com/blog/security/q...ie-miller/2941

People can easily get infatuated with Mac .. it's like Pandora's charm .. even Larry Wall courted the OS : "Apple has always been, tried to be, at least, the arbiter of good taste" .
as far as usability is concerned .. I confess Mac is super-easy super-user-friendly (yet a GUI-jailed user-friendliness ) .. that it allows fast data transfer (usb , firewire .. ) .. that it offers a superfast (but also super-expolitable) Safari .. that it has a charming GUI .. Yet .. for some , an fvwm with an xsetroot -solid springgreen would outmatch all GUIs ..
Diogenes once said : " What a lot of things I don't need .. " :-)

[ocicat]

Originally Posted by daemonfowl

am I right to say that Tanenbaum diapproves of linux kernel because of this very issue ?

My suspicion is that you are reading what you want into Tanenbaum's statements. To understand Tanenbaum's beef is to go back & read the original newsgroup argument they had back in the early '90's:

http://en.wikipedia.org/wiki/Tanenba...orvalds_debate

Much of their argument centered around Tanenbaum advocating microkernel design as being the next step in OS implementation while Torvalds advocated a simpler monolithic structure because it is easier to implement. Much of their debate was fueled by their respective egos, & because the feud was so public, this may have led to the rise of Linux because:

• many OS enthusiasts read the newsgroups in which both pontificated their agendas.
• making the Linux kernel free (as in GNU free...) enticed many to play with it since there was no charge to do so.

While Tanenbaum has a point in the links provided earlier in this thread, I also suspect he is not totally unbiased given the debate taking place twenty years ago.

[jggimi]

"The spaghetti down there" I think may have been a reference to the scheduler. I'm getting that from the huge comments, I haven't started to read the interview... But from them, I can see that everyone responding appears to interprets the interview from their own history; and their own biases.