Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Linux not appropriate for critical security applications
- Thread starter screwloose
- Start date
- Status
MasterRacker
New member
Nice counterpoint to the "Linux should be used for everything" crowd. Everything has it limitations and it place. There is no "one size fits all" operating system.
Jeff
The future is already here - it's just not widely distributed yet...
Jeff
The future is already here - it's just not widely distributed yet...
sleipnir214
Programmer
Although I agree with the spirit of the article (namely that no piece of OS software is good for every application), I could take the advice of the article more to heart if it were not a multipage advertisement for the author's company's OS product.
Want the best answers? Ask the best questions!
TANSTAAFL!!
Want the best answers? Ask the best questions!
TANSTAAFL!!
The article is basically saying that the open-source model is inappropriate for operating systems used in guidance systems for tanks, planes and bombs. It also sounds like a lot of the noise is being generated by proprietary software vendors that currently make these products and feel threatened by Linux. (Sound familiar?)
I personally don't care whether Linux is used in tanks, planes and bombs, but the fact that it seems to be the *only* publically known OS in that domain is kind of impressive.
News and views of some obscure guy
I personally don't care whether Linux is used in tanks, planes and bombs, but the fact that it seems to be the *only* publically known OS in that domain is kind of impressive.
News and views of some obscure guy
MasterRacker
New member
sleipnir, good point.
I am glad though to hear some other criticisms though. Linux is far from perfect and I get tired of hearing from the rabid masses chanting how Linux is manna from the gods, the greatest thing since beer in a can, the only OS, blah, blah, blah,
The BSDs are also Unix variants, just as free as Linux and faster and more secure from what I've read, yet you never hear a peep about them.
I don't care what they use, as long at it truly is secure.
Jeff
The future is already here - it's just not widely distributed yet...
I am glad though to hear some other criticisms though. Linux is far from perfect and I get tired of hearing from the rabid masses chanting how Linux is manna from the gods, the greatest thing since beer in a can, the only OS, blah, blah, blah,
The BSDs are also Unix variants, just as free as Linux and faster and more secure from what I've read, yet you never hear a peep about them.
I don't care what they use, as long at it truly is secure.
Jeff
The future is already here - it's just not widely distributed yet...
sleipnir214
Programmer
The quotes in the article are talking about a great number of different things.
One is the inappropriate use of general-purpose OSes. Win32, Solaris, Linux, BSD and other general-purpose OSes are completely inappropriate for avionics use. At the very least, a flight-critical operating system must be realtime. This, of course, eliminates nearly all general-purpose OSes. Very few realtime OSes are certified under the FAA's strictest guidelines (DO-178B Level A): LynxOS-178, CsLEOS, and INTEGRITY-178 are the few I could quickly find.
Second is the overall security of the OS. Some in the article are saying that the entire open-source model is incapable of producing software that can be certifiably secure, with the implication that the programmers providing the source code cannot be sufficiently vetted. Interestingly, those same people do not support their opinions with facts and logic. What they also seem to ignore is that open-source is not a development methodology, but rather a publication methodology.
Want the best answers? Ask the best questions!
TANSTAAFL!!
One is the inappropriate use of general-purpose OSes. Win32, Solaris, Linux, BSD and other general-purpose OSes are completely inappropriate for avionics use. At the very least, a flight-critical operating system must be realtime. This, of course, eliminates nearly all general-purpose OSes. Very few realtime OSes are certified under the FAA's strictest guidelines (DO-178B Level A): LynxOS-178, CsLEOS, and INTEGRITY-178 are the few I could quickly find.
Second is the overall security of the OS. Some in the article are saying that the entire open-source model is incapable of producing software that can be certifiably secure, with the implication that the programmers providing the source code cannot be sufficiently vetted. Interestingly, those same people do not support their opinions with facts and logic. What they also seem to ignore is that open-source is not a development methodology, but rather a publication methodology.
Want the best answers? Ask the best questions!
TANSTAAFL!!
MasterRacker
New member
More good points. I wan't paying attention to the realtime aspect of it. I remember doing some reading about realtime OSes a few years ago when I was working with an automation company. You're right, no general purpose OS handle a realtime control system.
Looking at development from an espionage/sabotage standponit, a mole could conceivably get onto any project.
Jeff
The future is already here - it's just not widely distributed yet...
Looking at development from an espionage/sabotage standponit, a mole could conceivably get onto any project.
Jeff
The future is already here - it's just not widely distributed yet...
But (in spite of the Linux spin) the point of the article is that the security hole is in the open source model itself. BSD and Linux are equally suspect in this case because anybody can introduce backdoors into code running on military equipment.
News and views of some obscure guy
sleipnir214
Programmer
petey:
I disagree. It is neither harder nor easier to add backdoors to Linux than it is to any code base that has remote developers.
Unlike the halcyon days of Linus Torvalds' release of Linux kernel version 1.0, in the current development model, the kernel development administrators will only accept code from programmers they have vetted. And code that does come from vetted programmers must be submitted with cryptographic signatures.
And BSD code submission policies vary by the BSD derivative. While FreeBSD and NetBSD will accept code submisions, the OpenBSD derivative is actually open source with closed development. The progamming team doesn't accept code submissions.
Want the best answers? Ask the best questions!
TANSTAAFL!!
I disagree. It is neither harder nor easier to add backdoors to Linux than it is to any code base that has remote developers.
Unlike the halcyon days of Linus Torvalds' release of Linux kernel version 1.0, in the current development model, the kernel development administrators will only accept code from programmers they have vetted. And code that does come from vetted programmers must be submitted with cryptographic signatures.
And BSD code submission policies vary by the BSD derivative. While FreeBSD and NetBSD will accept code submisions, the OpenBSD derivative is actually open source with closed development. The progamming team doesn't accept code submissions.
Want the best answers? Ask the best questions!
TANSTAAFL!!
sleipnir214, I was just trying to state the case, not that I necessarily agree with it. In my view, both the open source community and the corporation try to add value by improving the security of their products. Both have strict standards they abide by to keep the code clean and secure. Both consist of people with individual ideas of right and wrong. Both are basically opposed to the other. The corporation, however, has money to influence intellectuals, sponsor studies and publish articles that lean in their favor. I think this article exists because of that fact.
News and views of some obscure guy
News and views of some obscure guy
sleipnir214
Programmer
petey:
Again, I disagree.
The open source community and corporations are not necessarily in competition with each other. On example is MySQL AB, where you have a corporation that produces open-source software. MySQL AB is in it for the money, yet it produces open source code.
Want the best answers? Ask the best questions!
TANSTAAFL!!
Again, I disagree.
The open source community and corporations are not necessarily in competition with each other. On example is MySQL AB, where you have a corporation that produces open-source software. MySQL AB is in it for the money, yet it produces open source code.
Want the best answers? Ask the best questions!
TANSTAAFL!!
MasterRacker
New member
I don't particularly care for the "buy our stuff" flavor of the article either, but the point is valid. The point is that open-source doesn't automatically mean security.
Open-source code can be secure, closed commercial code can be secure. Neither is guaranteeed to be secure just because of how it was developed.
Jeff
The future is already here - it's just not widely distributed yet...
Open-source code can be secure, closed commercial code can be secure. Neither is guaranteeed to be secure just because of how it was developed.
Jeff
The future is already here - it's just not widely distributed yet...
sleipnir214
Programmer
Or more exactly, the open source development model does not, contrary to the article, guaranty that the software produced will be insecure.
In fact, there is no such thing as an "open source development model". Open source is a publication methodology, not a development methodology. There are lots of ways to develop an open source product.
All it would take is for the developers of Lynx-178 to open-source their software, and then the development methodologies specified by DO-178B become a possible methodology for developing open source software.
Want the best answers? Ask the best questions!
TANSTAAFL!!
In fact, there is no such thing as an "open source development model". Open source is a publication methodology, not a development methodology. There are lots of ways to develop an open source product.
All it would take is for the developers of Lynx-178 to open-source their software, and then the development methodologies specified by DO-178B become a possible methodology for developing open source software.
Want the best answers? Ask the best questions!
TANSTAAFL!!
You're right. I meant with regards to the overall philosophy of how they look at software development, but obviously that doesn't apply to each corporation, or to each open source project.
Not sure I follow. Microsoft's idea of shared source might be more of a publication methodology, but OSS theorists like ESR or James Duncan Davidson often promote adoption of what they would call an OSS development model in shops that do proprietary software development.
News and views of some obscure guy
sleipnir214
Programmer
The universe of open source projects demonstrates a wide range of possible development methodologies.
It's all a matter of promiscuity.
There is the openly-promiscuous development methodology employed by Linus Torvalds early in the development of Linux. Accept code from everybody. In the early stages of a project, this can get the code base growing very quickly.
There is the non-promiscuous development methodology employed by the programmers of OpenBSD. Accept code from no one. This gives the core programmers absolute control over the project, but at the expense of their having to do all programming themselves.
There is the partially-promiscuous development methodology employed currently by the Linux kernel development team. Accept code only from a large, but limited, base of progammers.
Want the best answers? Ask the best questions!
TANSTAAFL!!
It's all a matter of promiscuity.
There is the openly-promiscuous development methodology employed by Linus Torvalds early in the development of Linux. Accept code from everybody. In the early stages of a project, this can get the code base growing very quickly.
There is the non-promiscuous development methodology employed by the programmers of OpenBSD. Accept code from no one. This gives the core programmers absolute control over the project, but at the expense of their having to do all programming themselves.
There is the partially-promiscuous development methodology employed currently by the Linux kernel development team. Accept code only from a large, but limited, base of progammers.
Want the best answers? Ask the best questions!
TANSTAAFL!!
I think what you said, sleipnir214, captures what the article is about. Certain people feel open source (Linux being the primary example) is "promiscuous" because so many developers contribute to it. But proprietary shops can also have lots of people contributing to the code. The crux of the argument, maybe, is that proprietary shops produce more secure software because they have better security clearance, background checks, etc.
This is not a given, however, because (for example) the CIA was infiltrated by spies during the '60s and '70s in spite of their rigorous background checks. If the stakes are high enough, somebody will eventually worm their way into trusted circles. I think the peer-review of Linux's open source model, where thousands of experts review the code on a daily basis, is no worse than the strictures of proprietary software in this case.
News and views of some obscure guy
This is not a given, however, because (for example) the CIA was infiltrated by spies during the '60s and '70s in spite of their rigorous background checks. If the stakes are high enough, somebody will eventually worm their way into trusted circles. I think the peer-review of Linux's open source model, where thousands of experts review the code on a daily basis, is no worse than the strictures of proprietary software in this case.
News and views of some obscure guy
CajunCenturion
Programmer
I think there seems to be an assumption that just because someone wants to contribute towards the development of an open source project means that they can and will. That is not the case. Code may be submitted by anyone, but does not means their code will be in the project. Only that code which the primary development team feels appropriate will be included.
petey Your points about the CIA being inflitrated is one of the best reasons to go open source. If the code is open source then you can see the code, I can see the code, and everyone else can see the code. The inflitrator cannot hide their code. If you, or I, or anyone else sees the security hole, we can point it out, or submit a fix. It is considerable more difficult to hide a security hole when thousands of programmers can see it and evaluate it.
That is not the case in a proprietary development shop. The inflitrator only needs to hide their malicious code from the rest of the internal development team. How can you and I be sure that the code is secure if we cannot see it?
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
petey Your points about the CIA being inflitrated is one of the best reasons to go open source. If the code is open source then you can see the code, I can see the code, and everyone else can see the code. The inflitrator cannot hide their code. If you, or I, or anyone else sees the security hole, we can point it out, or submit a fix. It is considerable more difficult to hide a security hole when thousands of programmers can see it and evaluate it.
That is not the case in a proprietary development shop. The inflitrator only needs to hide their malicious code from the rest of the internal development team. How can you and I be sure that the code is secure if we cannot see it?
Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein
octothorpe
Programmer
On a related note:
I personally find it hard to believe that any OS built upon the x86 hardware platform, which is very interrupt driven, could be reliable enough for real-time systems.
Of course, I suppose that with the increasing processing speed available to the hardware, perhaps a system that can simply guarantee processing within X timespan could be suitable for some soft-real-time applications.
I personally find it hard to believe that any OS built upon the x86 hardware platform, which is very interrupt driven, could be reliable enough for real-time systems.
Of course, I suppose that with the increasing processing speed available to the hardware, perhaps a system that can simply guarantee processing within X timespan could be suitable for some soft-real-time applications.
iceman2654
Programmer
Personally I believe going with just one model (open source vs closed source) would be kinda hard. We can see it right now...there's so much friction. I also believe that these two models have their pros and cons as stated above. Maybe convergence would be a good but idealistic solution? For example most of the OS will stay open source but since most of the world is based on free market etc etc, things such as security alogrithms and components can be privately made so it can be sold. Stuff like that. Any thoughts?
sleipnir214
Programmer
octothorpe:
There are a number of real-time OSes for x86, Lynx and QNX being two notable examples.
iceman2654:
There's convergence going on every day. Corel just announced yesterday the pending release of WordPerfect Suite 12 for Linux. That's a closed-source product running on an open-source OS.
But I think you're confusing licensing with publication methodology. There is no reason right now why an open-source OS cannot use close-source code -- except for the fact that the close-source code often happens to be for-pay code. A Linux distributor cannot buy code licences for every person who might decide to download his OS.
Want the best answers? Ask the best questions!
TANSTAAFL!!
There are a number of real-time OSes for x86, Lynx and QNX being two notable examples.
iceman2654:
There's convergence going on every day. Corel just announced yesterday the pending release of WordPerfect Suite 12 for Linux. That's a closed-source product running on an open-source OS.
But I think you're confusing licensing with publication methodology. There is no reason right now why an open-source OS cannot use close-source code -- except for the fact that the close-source code often happens to be for-pay code. A Linux distributor cannot buy code licences for every person who might decide to download his OS.
Want the best answers? Ask the best questions!
TANSTAAFL!!
- Status
Similar threads
- Locked
- Question
- Locked
- Question