Slashdot Mirror
Linux and DII/COE Compliance?
swestbrook asks: "I would like to know if there are any efforts out there to submit a Linux distribution or the kernel at large for U.S. governmental testing to see if it will be certified to be Defense Information Infrastructure Common Operating Environment (DII/COE) compliant. I am a program manager for a very small program in the U.S. Air Force and would like to be able to use Linux as a possible platform for my standard systems. However, I cannot because regulations require me to use only operating systems that are DII/COE compliant. Information on DII/COE compliance can be found at here.
Until it is officially certified I can not rehost applications on a Linux platform. Any information would be greatly appreciated."
I tried to convice the company for which I used to work (General Dynamics) to go through this process. Unfortunately, they wouldn't go for it.
One of the issues is that you cannot get a DII/COE certification just for the sake of the certification. There must be a product or a contract vehicle that requires Linux. Your product may be a perfect fit.
One also must have sponsorship in the military. A company can't just go and ask for DII/COE compliance for a product without having a 'friend' go before the DII/COE folk.
The Linux distribution vendors are missing something here, though. The first company to get a particular product certified automaticaly becomes the sole source provider for that product. If anyone else wants to build a DII/COE compliant system, they must get the product from the vendor that did the DII/COE compliance. So, if Red Hat were to manage to get DII/COE compliance for thier distribution, anyone who wanted to build a DII/COE compliant system based on Linux would have to get the OS from Red Hat. This will be a bit different than the other commercial UNIXes, though. HP is the sole source for HP-UX. Red Hat would be the sole source for Red Hat Linux. There's nothing stopping SuSE for seeking compliance, but they'd be waaaaay behind Red Hat. Most likely, anyone building a DII/COE compliant Linux-based system would just use Red Hat.
So, if you've got the time and the understanding of DII/COE, you should go for it. Team up with your Distribution Vendor of choice and get them to foot some of the bill. You've already got the contract vehicle and (I assume) the military 'friend'. You just need the support of one of th e Linux distribution vendors (note, however, if -you- get Red Hat Linux certified, -you- become the sole source provider of Red Hat linux).
IIRC, this is a fairly recurring topic on the linux kernel list. Do a search at any of the searchable archives and I'm sure you'll find the ongoing arguement (last time I checked).
Alternately, for a summary, check out Kernel Traffic.
-- IANAEG - I am not an elder god.
-UNCLASS-
I work as a DoD contractor supporting many HP/UX 10.20 and Solaris 2.5.1 based DII-COE 3.x systems. As far as DII-COE 4.x systems go, HP/UX will either up to 11.x or go away. The de-facto target Unix platform for DII-COE 4.x is Solaris 8, but the latest beta is on Solaris 7. I've heard rumors within DISA that a couple of rouge programmers have compiled a somewhat functioning COE under linux. Keep in mind that DII-COE 3.x is tightly integrated with CDE (4.x will be more abstracted). Alot of the DII-COE stuff is done at NASA's JPL, so you if you know any people there, push it. For now, if you want to start coding DII-COE apps that would have a GUI toolkit which ports easily to Linux, think about using GTK+. I am in the process of submitting the GTK+ and GLIB 1.2.8 (for Solaris 2.5.1) to DISA for acceptance as an official segment. After the initial acceptance, I will work on getting segments published Solaris 7 and HP/UX 10.20 also.
-UNCLASS-
I work for a large government contractor and just, today, returned from a DII/COE training seminar. I had a similar question regarding Linux and DII/COE compliance and this is what I came up with...
As of right now the major DII/COE compliant systems are Solaris, NT4, HP-UX and IRIX (which just recently was approved by DISA). The reason that Linux is not and will never (as long as the DII/COE rules stay they way they are) be DII/COE compliant is because it is open-source. One of the big things with DII/COE is that you can not get into the source code and "tweak" it thereby comprimising the integrety of it. The open-source nature of Linux sets off a red flag, to most government officals, that says "UNSECURE." For obvious reasons security is a big factor for the government and therefor is something the government takes extremely seriously and is evident from this quote right from the DII/COE SRS...
"The use of TFTP could create an unsecure state on the system and could be used to provide a distribution point for hacker files, pornography and pirated software."
Also, I noticed that some others were asking why NT was one of the DII/COE compliant systems, well read on... One of the reasons NT4 is DII/COE compliant, and this provides a humorous anticdote, is because of the Navy. A few years back the US Navy decided that instead of using UNIX based systems it wanted to use NT. So it spent several million dollars outfitting a battleship with NT servers and software. When the ship was finally completed it set sail for a week long trial run. A mile from port one of the NT servers "blue-screened" and froze up the entire ship. In fact, they had to send out a couple tug boats and tow the ship back to port.
Hope that helps....
I'm pretty sure I saw a story about SecureBSD on /. a few days back. Submit *that* and I think you'll have the OS you're looking for.
As a complete aside, and at possible risk to my karma, I have to say that a lot of the DoD regulations about computer usage are honored more in the breach than in the observance. That's because the DoD itself is a beauraucracy - a gigantic machine operated by pygmies.
I was in the USAF, stationed at Langley AFB (1912 GSG) when the putsch came to shove C in favor of Ada. God knows, there's probably a beautiful language hiding under that elephantine bulk, but I don't think it'll ever be released. (At the time (1988), the word went out that "Ada *is* Software Engineering.") (This was the line you had to trumpet to have any chance of proceeding in your career) (I'm now a civilian.) (Someone needs to unearth Robert Firth's hilarious comparison of fire control systems written in C versus Ada.)
In any event, the push to Ada left the DoD with a language nobody else was using, skyrocketing costs for supporting *its* language of choice, and a largely-indifferent programming community. The end result is that Ada no longer occupies center stage, and the approach to development is a bit more rational (i.e., language is *not* software engineering). I think that what happened, basically, is that some 2LT somewhere woke up one day and said "The Emperor has no clothes," and everyone else went "Damn, s/he's right!"
I think this OS war will go the same way. The DoD has its regulations, the regulations make little sense, the DoD will be stymied until the regulations change, the regulations will eventually change. I think it'll take a while, though. This year's Academy grads, who probably have *some* understanding of Linux, will have to wait 20 years, or so, before they'll have the authority to change anything.
So, by about 2020 the USAF will have a few decent OSs on the list. Sigh.
668: Neighbour of the Beast
I had something to say about this a couple of days ago. The new industry-sponsored Open Source Development Lab may be your answer. Why not try to get your stuff on the agenda there? As I understand it, this is an exact fit with the Lab's mandate.
--
When all you have is a hammer, every problem starts to look like a thumb.