Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux and DII/COE Compliance? 102

Posted by Cliff from the yet-another-certification-question dept.
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."
This discussion has been archived. No new comments can be posted.

Linux and DII/COE Compliance? More

Linux and DII/COE Compliance?

Comments Filter:

  • Re:Putting the "D" in "BSOD" (Score:1)

    by Anonymous Coward
    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.

    Ah yes, that would be the infamous Navy Smart Ship Yorktown. See

    Software glitches leave Navy Smart Ship dead in the water [gcn.com]

    This is a must-read article, if only for the hilarious explanation of how computers, NT and your calculator handle division by zero. One hopes none of these people have anything to do with the Navy's budget, although now that I think of it, it would explain a lot if it turned out they did.

  • Ground Truth on Linux and DII/COE at DISA (Score:1)

    by Anonymous Coward
    Posting anonymously since I work for a contractor firm, and don't intend to speak for them. Although I use Linux, OpenBSD, NT4/2000, Solaris, HP-UX, and Irix in my daily work, my COE experience is 75% on Solaris and 20% on HP-UX, so I won't discuss COE on NT. I am currently "segmenting" (packaging) some well-known UNIX software for COE.

    I hated the COE when I first saw it, for many of the stated reasons in other replies and previous stories. COE is so focused on making things graphical that really should be CLI-based that it's truly annoying for experienced users. However, the target audience is non-sophisticated users, and for many of those folks it works.

    The current fielded UNIX COE systems are generally using COE 3.x on Solaris 2.5.1 or HP-UX 10.20. If you're using COE 3.x on Solaris, it installs the TriTeal Enterprise Desktop, which sucks even worse than regular Sun CDE (so bad, in fact, that TriTeal is now out of business). COE 3.x sucks, and the fix is to upgrade to COE 4.x, although that's taking too long in the operational world.

    COE 4.x (currently 4.2.0.0P1 is what I'm using) runs on Solaris 7 and HP-UX 10.20. There are plans to migrate to Solaris 8 and HP-UX 11.00 soon, but no firm schedule. COE 4.x uses the CDE functionality provided by the underlying OS, and really just adds some role-based functionality (split root into "sysadmin" and "secman", supports COE "segment" packages, and adds a few new actions to the CDE desktop.

    Linux is being actively used within DISA and within the US DoD as a whole--but it's still "in the closet" and few managers recognize it (similar to many Fortune 500 companies 18 months ago). With Linux as with any OS, if you don't know what you're doing you can get hacked. Too many people got a copy of RH 6.0 with some "Linux for Morons" book, installed it, and then never locked it down or updated. Surprisingly enough, they got 0wn3d. Unsurprisingly, they then blamed their stupidity on Linux. This was negative press for Linux within the DoD security community, but there's only so much that any of us reading Slashdot can do about that.

    I have some hope that DISA will modify the COE rules to allow Linux to be certified as a COE platform even though Linux will never be fully POSIX compliant. As has been well stated in other messages, the right way to make this happen is for a military project to want to use Linux enough to get it certified, and for one of the major distributions to step up to the plate. I believe that many security folks within DISA and related organizations do recognize that having the source code does not make the system less secure, so I really think that that is a red herring.

    I sure wish that the COE segmentation process was as well managed as either RedHat or Debian packages--most COE segments that I've worked with are steaming piles of crap compared to their OSS equivalents.

  • Linux was certified (Score:1)

    by Anonymous Coward
    Linux was certified a long time ago. Now we have
    people on the UNIX standards committee, so one
    may expect Linux to meet SUSv3, which will most
    likely be known as UNIX 2000.

    Once Linux meets that standard, Linux==UNIX.
    (UNIX is a trademark that you can use if you
    pass a feature test)

    Since Caldera bought UnixWare, Linux could end up
    with UNIX source code _and_ trademark. BSD is
    left with neither one, which is very funny.
    To those arrogant FreeBSD users, we will be able
    to say that Linux is UNIX while BSD is not.
  • emir writes:

    i believe there a lots of smarter ways for redhat or any other linux vendor to support free software community.

    True, but from a commercial standpoint I can think of few smarter ways to get lucrative government contracts than offering the "First [or Only] Linux Distribution that's POSIX, Unix and DII/COE certified", and getting government-saavy salespeople.

    ----

  • Show me one single source that says that the OS did not crash. (A non-Microsoft source that is.)

  • I didn't claim that it did. You claimed that it didn't. Every article I've seen called it a "system crash." That would seem to support the theory of the OS crash more than it supports your theory that it was only an application crash. Either way, you made the idiotic claim that the OS was not at fault, even though there is no evidence, even circumstantial, to support that claim.

  • I really think the OpenSource argument is irrelevant, here. If you look at the list, Solaris is certified. Solaris was certified by Sun, who has the source. Most linux distributions do not install source on a system. Whoever installs the OS would simply not include the source.

    So, an installed system does not have source on it that can be muddled with. Most of the main Linux vendors offer binary patches (eg, update RPMs from the vendors hat use RPM).

    Hell, a lot of the military folks I spoke with were very excited about Linux, Open Source or not.
  • Okay.

    Since NT is not UNIX-like and compatibility with UNIX-like operating systems is not expected, POSIX is irrelevant.

    Better?
  • Red Hat Linux.

    If you don't install the kernel-source package, you don't get the kernel-source. You do get the kernel-headers, though, if you want to do any development.

    headers != source
  • DII/COE certification has nothing to do with POSIX. NT got there because it some company (most likely Microsoft with a partnership with another gummit contractor) was willing to put in the work, and they got a sponsor within the military.

    Since NT is not UNIX and compatibility is not expected, POSIX is irrelevant.

  • DII/COE Certification (Score:3)

    by sighup ( 1594 ) on Friday September 01, 2000 @03:53AM (#812077)
    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).
  • SGI have released B1 patches, based on their IRIX OS, which are portable to Linux. Whether anyone is, is another matter, though they -could-.

    DII/COE compliance is another matter. Notice that there is a difference between certification and compliance. The former means there's been a formal, rigorous test, the latter means that there is no significant difference between the specs and the API.

    IMHO, Linux and OpenBSD are ideally positioned to more or less divide the entire secure OS market between them. All the code necessary is "there", almost nothing "new" is needed. What's needed is for vendors to take these pieces, merge them, and audit the resulting code. Someone like Red Hat or SuSE would be in a position to do this.

    Once you've had a code audit, B1-compliance (with or without a certificate), and DII/COE compliance (with or without a certificate), you'll have a product nothing in the commercial market can touch for less than a few hundred thousand a throw. This is something the Open Source software arena CAN do. Muster vast resources, to achieve these kinds of objectives, for a practical cost.

  • Is this able to read/write files that are used by the Win32 programs?

    Apparently the official NT version is completetly unable to do this, which means it "works with NT" about as well as a Linux box with no physical connection between it and the NT box.

    If so, is there official transformations between Unix file names and Win32 file names (ie does A:foo in Win32 turn into perhaps /A/foo in Unix?) What about case dependence (a posix requirement)?

    Agreement on these transformations would go a long way to allowing the writing of software that ports between NT and Unix. For my work the file name problem and lack of symbolic links are causing far more difficulty than the fact that X and Win32 GDI are completely different.

  • Re: especially when one considers that the GIMP toolkit (GTK+ & Co.), allows one application to be written for X and Win32 with minimal OS-specific code.

    That's what I meant. Despite the huge differences, it is possible to hide the difference between X and Win32 GDI by using a toolkit. But the lack of a simple thing like symbolic links on NT is impossible to get around.

    Symbolic links would allow us to set up local and remote files on our NT machines to have the same names as our Unix machines, and eliminate the need for drive letters, and thus allow much greater Unix/NT interoperability. Unfortunately MicroSoft is well aware of this fact and will refuse to support symbolic links as long as they possibly can.

  • If you look into your kernels bootup messages (Yeah... you don't see them often...) it says: POSIX Compliance testing by UNIFIX... And they are able to provide you with a posix valid version of linux. There you go
  • If some creates a new distro or a sub distro that is complaint but would only give the source code to the owner of the product. I do not see the problem with this. It would not violate the GNU license since you only have to give the source to the people who own the program. That would solve the problems. Or just create a BSD distro that is complaint. You do not have to give any code to anyone.

  • Most opt to let the professional techs decide what is best for the network.

    I should have joined the military... their commanding officers sound a good deal more intelligent than your average IT PHB (Director of Information Services / CIO for the geek-speak impaired).

    "Free your mind and your ass will follow"


  • Has Linux (or any BSD) ever been certified as POSIX-compliant? Or subjected to the X/Open groups testing to determine whether it can be registered as a "true" UNIX?

    D.


  • Well, the are companies out there who are making lots of moolah out of open source software. Why couldn't someone like Red Hat pay for it?

    As to whether it's useful or not, I'll leave that one open for discussion... :-)

    D.

  • So that's why there's all that water on the floor in our server room!
  • The can get such a thing at www.openbsd.org
  • Wrong. Yorktown is an Aegis cruiser.
  • Well, I am a FreeBSD type personally. I really don't see OpenBSD going anywhere either.
  • The obvious answer to this is that Red Hat and/or some of the other big companies in the Linux arena should make a POSIX-compatible, DII/COE compliant version of Linux, and distribute it on CD-ROMs that do not contain any source code for the included software. Furthermore, each binary should be digitally signed and the signatures stored on the CDROM, with a little executable on the CDROM that would check each binary on the system for changes.

    That system would be demonstrably more secure from tampering than Windows NT or any supposedly acceptable OS they use. And that would be the end of this "Open Source is Insecure" FUD crap.

    Red Hat, where are you? Please make this happen just so people don't have to discuss it anymore. (Oh yeah - of course the source code would be available... separately.)

    Torrey Hoffman (Azog)
  • You got it. People I work with have built several DII COE certified and compliant software product for the government. They always deliver the DII COE version as the contract requires, then they snicker and say, "Do you also want the one that works?".

    DII COE certification for Linux would exactly as you describe. The DII COE version would exist, which would allow government folks to choose Linux. The government users that really need a functioning system, would put the DII COE version in the round file and just install Debian or RedHat or similar.
  • DII/COE is the ultimate in US government waste and
    bureaucracy. An entire fiefdom had grown up around DII COE's goals of standardization and interoperabilty. Trouble is the people setting the rules for DII COE certification (or compliance) have little real software experience. This leads to ridiculuos rules and recommendations . On the military side (where I work), this leads to many poor decisions just to be "DII COE Compliant" (most even on the inside have given up being certified its too much paper work and too much wasted money). Being a US government project, lots of contractors were hired, lots of people were put in charge of things, so this bad idea has a life and cannot be killed.

    It started as standardization of things on Unix systems. When much of the military started shifting to Windows NT, DII COE followed suit, but keep their Unix rules in place. For instance, you have to install things in on the "/h" partition of your NT box, just like Unix. Of course, NT does not have partitions like Unix, so you create a "/h" directory on your NT disk drive and install stuff there. Another for instance, up until very recently, you could only add things to the NT registry in the DII COE spot, nowhere else! Try installing an OCX on NT and obeying that rule. Who cares about NT? Well I mention this to serve as an example why the Linux community should not waste any time on DII COE.

    It boils down to the US government trying to set software standards, usually in conflict with accepted commercial standards. Remember Ada? If the US government wants to use Linux, they should. Just install it and go. They do not need DII COE to be successful with Linux.

    I have worked with DII COE compliance for several years. I do not know a single developer who does not snicker everytime DII COE is mentioned. Just kill DII COE and give the $$millions$$ to support development of open source software. In the end what benefit would DII COE certification bring to the Linux operating system?

  • This describes DII COE [thinkgeek.com] accurately.

  • You have first hand experience which I respect, however Ada was not mandated to replace just C, but the hundreds of other languages (including dialects) with custom tools, compilers etc spread across all of the DoD. They decided to standardise on just one language and AT&T refused to submit C (they said it was not suitable).

    As for "elephantine bulk", well the language definition for Ada95 is about the same or smaller than C++. Guess which language many contractors switched to from Ada? You got it. I've heard that they've had at best mixed success mindlessly switching from one complex language to an even more complex language even though in many cases they already had working systems.

    Otherwise you are quite right.

  • Look at the linux kernel list (Score:5)

    by handorf ( 29768 ) on Friday September 01, 2000 @03:00AM (#812095)
    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 [linuxcare.com].
  • Open source requires that when you distribute object code to somebody, you make the source available.

    Nothing requires that the recipient actually accepts the source, unless they further redistribute the source to a third party (internal redistribution doesn't count).

    Even if you do install source, you just have to install it with permmissionsso that ordinary users and black hats don't tweak it.

    Finally, if you really want to be secure, put all your utilities etc. on read only media (e.g. boot off of a CD-ROM).

  • then Linux should be certified by default (or should it be de facto | ipso facto | a priori | Klatu Virata Cisco?).

    And, yeah, what about OpenBSD?
  • I am a program manager for a very small program in the US 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.

    I see nothing at all preventing YOU from submitting the platform/krenel combination that you want to use.

    I hope it is not something pesky like "government money is too precious to be wasted on this", since it should not cost over a couple hundred bucks and that is for a system that you are going to end up using anyway.

    BTW, I hope that you are using ONLY the 2 platforms on that compliance list in your shop. If you have anything legally running Win95 then this is just a bunch of nonsense that you may ignore just as everybody else does.

    Visit DC2600 [dc2600.com]
  • Secondly, if you think that an undertaking like Linux (or any OS for that matter) would only cost a few hundred dollars, then you are only looking at the cost of procuring the OS itself. While Linux may be freely distributed, coding the Military's very specific pieces of hardware would require a huge undertaking employing numerous engineers many man hours.

    Incorrect. He has a specific project, the information on how to make a secure install of Linux is out there, the spec he wants to follow (however, he probably does not have to follow it like he thinks he does, if you read my whole post) is out there.

    I don't know what DoD related job you ever heald, but in the 21+ years of military service plus years with contractors I have not been on any platform listed. As you will see by scrolling through the other posts of folks that are actually familiar with the DoD drumbeat, from experience, this guy has a much smaller problem than he thinks he has as far as getting his system up.

    Visit DC2600 [dc2600.com]
  • This:
    So the cost of segmentation, a users guide/manual, QA, and everything else that go into a DII COE segment are free? Unfortunately, we have to go through this far too often. A well supported segment takes three months (full time) to get it in. If someone has a problem or you don't have someone to push the segment through for you? Now you're looking at more like six months or longer.
    is not the real point. The real point is that he can probably do what he needs to do with Linux or anything else that is not on the "certified" list.

    Now, if you wan to get something else onto the list you CAN do it yourself and there are about a zillion ways to get a charge number for this and work it into the existing appropriation and/or contract.

    Visit DC2600 [dc2600.com]
  • Actually, it was an aircraft carrier. The Yorktown IIRC.

  • Ada (Score:1)

    by wiredog ( 43288 )
    My father worked for a branch of DOD in the mid-eighties and one of the contractors flat out refused to use Ada. Given the choice of doing without a product that only they made, or using C, the DOD went with C.
  • 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.

    What that is SUPPOSED to mean is that the whole system is secured ... as in, write protected OS and so on. Security folk call it the "trusted distribution" problem, and one solves it by tamperproofing mechanisms. Sign the code using a signature, check the code using a secured mechanism (preferably with the basic keys encrusted in plastic) ... you get the idea. There are non-cryptographic solutions, such as "golden CDs" used as part of certain network install procedures, too.

    Note that any operating system, unless installed in a fairly restrictive manner, is going to fail to meet the requirements there. I mean, who actually is paranoid enough to need BIOS password checks, on top of restricting who gets root privileges? Well, some folk. The boxes need to be physically locked and sealed, and they may need their own customized BIOS...

    There's an opportunity for Linux here, assuming that reactionary and clueless folk aren't controlling the discussion. The point is to be trustworthy (shed those images of green-haired webbies raving the night away!) and make the points to the buyers. The reason that a Solaris is "trusted" doesn't have to do with the fact that nobody can see the source (lots and lots of people can see it). It has to do with a supplier who can be dealt with, and which has a track record in that market. And the fact that not just every "bug""fix" will ever be applied.

    On the other hand ... based on CDE and Motif? Run, don't walk, away as quickly as possible! Or if you don't, use the stake and garlic quickly -- save yourself!!

  • That's the point. Don't tell anyone! You know how moderators are with reverse psychology...
  • The story about the smart-warship is true. IIRC, it was a divide-by-zero error in a spreadsheet/database app that was being used for some navigational/targeting system that crashed the ship.

    I don't want to know how an OS can let a div-by-0 error in an application take down the whole OS. It hurts my head.

    How suits are allowed to make decisions like this just scares me.
  • 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."
    And so, I guess Solaris will come off that list Real Soon Now(TM) since now anyone can get the source code to it. Come on now, this is rediculous. They ain't that stupid in the military, are they? I certainly hope not, as I'm quite proud of my father and siblings who served. Not strickly meant as flamebait, but it's probably large government contractor's like yourself that perpetuate this nonsense.
  • The following text identifies specific criteria that must be satisfied for DII COE Kernel Platform certification.

    To the extent that automated test suites can verify satisfaction of a subset of these criteria, submission of certificates from recognized testing organizations shall be considered sufficient evidence of conformance. For manual procedures, submission of valid and successful test results shall be considered sufficient evidence of conformance. For many criteria, applicant claim of satisfaction may be accepted, with the provision that if found to be in error, the vendor applicant will bring the application platform into compliance within 180 calendar days in accordance with the provisions of section 2.5, "Changes in DII COE Kernel Platform Certification Status". Detailed definition of procedures and decision criteria are found in the referenced specifications and appendices.

    In addition to the all other criteria defined below, the applicant vendor shall ensure that the application platform, as configured for DII COE Kernel Platform Certification is Year 2000 compliant. Year 2000 compliant means that the submitted application platform accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000 and leap year calculations. Furthermore, Year 2000 compliant information technology, when used in combination with other information technology, shall accurately process date/time data if the other information technology properly exchanges date/time data with it.

    3.1 Integration and Run-Time Specification (I&RTS) Certification Criteria

    The DII COE platform must comply with relevant I&RTS requirements applicable to the 8 levels of conformance. These criteria include all platform specific requirements in the document, with emphasis on those identified in the checklist for I&RTS Appendix B.

    The specific I&RTS Appendix B criteria applicable to the DII COE Kernel Platform Certification Program are listed in Appendix B of this document. In most cases, the requirement is copied verbatim from the I&RTS. In some cases the text reflects an interpretation, either to clarify the aspect of the I&RTS requirement that applies to the application platform, or to make explicit an implied requirement. In all cases, no modification of the I&RTS requirement is intended, and where conflict arises, the current version of the I&RTS shall have precedence.

    3.2 Commercial Specification Certification Criteria

    DII COE Kernel Platform Certification requires the application platform implementation to be in conformance with the following specifications. Supporting documentation requirements are identified in Appendix C of this document. Citations below are drawn from "Department of Defense Joint Technical Architecture", Version 1.0, 22 Aug 1996 .

    The following standards contain provisions which, through direct references in this text, constitute criteria for DII COE Kernel Platform Certification. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties of interest are encouraged to investigate the applicability of the most recent editions of the standards listed below. However, DII COE Kernel Platform Certification criteria include conformance only to the specific versions listed below.

    Application Program Interface

    The application platform implementation shall be in conformance with the following Application Program Interface specifications. An application executing on the application platform implementation shall have simultaneous access to all services associated with the following standards:

    Operating System API

    The following standards are required:
    ISO/IEC 9945-1: 1996, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 1: System Application Program Interface (API) [C language]*, (as profiled by FIPS PUB 151-2: 1994)

    Communications Service API

    IEEE 1003.1g: 1996 Draft 6.6, POSIX - Part 1: System Application Program Interface (API) Amendment 2: Protocol Independent Interfaces (Sockets) [C Language]*, Sockets portion only

    Human computer Interaction API

    FIPS Pub 158-1: 1993, User Interface Component of the Application Portability Profile X-Windows Version 11, Release 5
    OSF Motif Application Environment Specification (AES), Release 1.2, 1992
    X/Open C323, Common Desktop Environment (CDE); XCDE Services and Applications - Version 1.0, April 1995.
    X/Open C324, Common Desktop Environment (CDE); XCDE Definitions and Infrastructure - Version 1.0, April 1995.

    Note: * - The reference to C Language is part of the formal title of these standards. It denotes the language used to define the standard.

    Human Computer Interface

    The application platform implementation shall be in conformance with the following Human Computer Interface specifications:

    OSF/Motif Style Guide, Revision 1.2 (OSF 1992).
    OSF/Motif Inter Client Communications Convention Manual (ICCCM) for communication between Graphical User Interface (GUI) client applications
    ISO 9945-2: 1993, Information Technology - Portable Operating System Interface for Computer Environments (POSIX) - Part 2: Shell and Utilities, (as profiled by FIPS PUB 189: 1994)

    Communications Service Interface

    The application platform implementation shall be in conformance with the following Communications Service Interface specifications:

    IETF Standard 7/RFC-793, Transmission Control Protocol, 1 September 1981. In addition, TCP shall implement the PUSH flag and the Nagle Algorithm, as defined in IETF Standard 3.
    RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 24, 1997
    IETF Standard 6/RFC-768, User Datagram Protocol, 28 August 1980.
    IETF Standard 5/ RFC-791/RFC-950/RFC-919/RFC-922/RFC-792/RFC-1112,, Internet Protocol, 1 September 1981. In addition, all implementations of IP must pass received Type-of-Service (TOS) values up to the transport layer.
    IETF Standard 13/RFC-1034/RFC-1035, Domain Name System, 1 November 1987.
    IETF Standard 9/RFC-959, File Transfer Protocol, 1 October 1985, with the following FTP commands mandated for reception: Store unique (STOU) and Abort (ABOR).
    IETF Standard 8/RFC-854/RFC-855, TELNET Protocol, 1 May 1983.
    IETF Standard 15/RFC-1157, Simple Network Management Protocol (SNMP), 10 May 1990.
    IAB Standard 16/ RFC-1155, RFC-1212, Structure of Management Information, May 1990.
    IAB Standard 17/RFC-1213, Management Information Base-II (MIB), 26 March 1991.
    IETF RFC 1757, Remote Network Monitoring Management Information Base, 10 February, 1995.
    RFC-951, Bootstrap Protocol, September 1, 1985.
    RFC-1533, DHCP Options and BOOTP Vendor Extensions, October 8, 1993.
    RFC-1541, Dynamic Host Configuration Protocol, October 27, 1993.
    RFC-1542, Clarifications and Extensions for the Bootstrap Protocol, October 27, 1993.
    RFC-1305, Network Time Protocol (V3), April 9, 1992.

    3.3 Government Supplied Software Certification Criteria

    Government supplied source code is provided which implements functionality not available on many commercial platforms. Government supplied source code implementation also assures that human-computer interfaces are functionally identical across multiple application platforms. This tends to reduce training cost and potential for operator error.

    The following software elements described in "DII COE Baseline Specifications" [2] are currently implemented by government supplied source code, and must be ported by the applicant to the candidate application platform. The full set of tools called for in the DII COE I&RTS [1] are not yet implemented, and the set of Government supplied source code base will expand as more tools become available. The current set of software elements, as described in reference [1], includes:

    Printing Services

    Print Services 1.0 Provide the basic heterogeneous print capability of the system. It provides such functions as user selection of a default printer, printer administration, and a common way of accessing print resources from an application program. It also includes print queue management and remote printer administration.

    Security Management Services

    Deadman 1.2 Locks the user's terminal if the keyboard and mouse have been idle for longer than a configurable time, defaulting to 5 minutes.

    Console 1.2 Provides a read-only console window for the use of applications which need it to display output written to stdout.

    Password Allows users to change their own passwords in accordance with established guidelines.

    X Display Manager (XDM) An element of the X-window system which controls access to the system from the login screen. This software element is a modified version of the publicly available implementation.

    Note: Government supplied Security Management Services are written in the C programming language, and contains approximately 90,000 lines of source code. Approximately 15,000 lines of code are associated with XDM.

    System Management Services

    Account Groups & Profiles Used to set profile configuration, create or edit local and global user profiles, and create or edit local and global user accounts. The security administrator's account group sets the security administrator's environment in order to execute the profiles and accounts. The Security Administration function also provides a facility to update internal profile and user account data structures through command line programs.

    Executive Manager 1.1 Establishes session characteristics during initiation of a DII session based on user-selected roles.

    Note: The government supplied "System Management Services" source code is written in the C Programming language, and contains approximately 6500 lines of source code.

    DII COE Run-Time Tools

    The system administrator uses the COE Runtime Tools support to install, configure, and de-install systems. The tools also provide the developers with a means to communicate with the operator during segment installation. These tools include:

    COEAskUser Display a message to the user, and have the user click on a button (Yes/No, True/False, Accept/Cancel, etc.) in response to the message.

    COEFindSeg Return information about a requested segment. The tool sets status and writes the pathname, segment name, segment prefix, and segment type information to stdout.

    COEInstaller Display a list of variants or segments that may be installed from tape, disk, or other electronic media. It is normally executed by an operator who selects it from a System Administrator menu to install or de-install segments.

    COEInstError Display an error message to the user from within a Pre-Install, Post-Install, or De-Install script signaling installation termination or de-installation of the segment.

    COEMsg Display a message to the user and have the user click on the "OK" button to continue. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.

    COEPrompt Display a message to the user and have the user enter a response to the message. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.

    COEPromptPasswd Prompt user to enter a password. The tool may be used by the Pre-Install, Post-Install, and De-Install scripts.

    COEUpdateHome Update the home environment variable within a script file to point to where a segment was actually installed.

    DII COE Developers Tools

    DII COE Developers' Tools support application software development and delivery, but are not delivered to operational sites. All interfaces to these tools are at the command line; none of them have a GUI interface. These tools include:

    CalcSpace computes the space required for the segment specified and updates the hardware descriptor accordingly. The segment referred to must not be compressed and must not contain any files that do not belong with the segment (e.g., source code) at run-time. The amount of space required is written to stdout in K bytes.

    CanInstall tests a segment to see if it can be installed, which means that all required segments must already be on the disk, and the disk cannot have any conflicting segments.

    ConvertSeg examines segment descriptors and converts them to the latest format. The original segment descriptor directory is not modified. The output is in a directory created by the tool and called SegDescrip.NEW. This directory will be located directly underneath the segment's home directory at the same level as SegDescrip. ConvertSeg is not location sensitive and may be moved to any directory desired for development.

    MakeAttribs creates the descriptor file FileAttribs. It recursively traverses every subdirectory beneath the segment home directory and creates a file containing permits, owner, group, and filename information.

    MakeInstall writes one or more segments to an installation medium, or packages the segments for distribution over the SIPRNET. MakeInstall checks to see if VerifySeg has been run successfully on each of the segments, and aborts with an error if it has not.

    TestInstall temporarily installs a segment that already resides on disk. There must be no other COE processes running when TestInstall is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.

    TestRemove removes a segment that was installed by TestInstall. There must be no other COE processes running when TestRemove is run. The reason for this restriction is that the tool may modify COE files already in use with unpredictable results.

    TimeStamp puts the current time and date into the VERSION descriptor.

    VerifySeg validates that a segment conforms to the rules for defining a segment. It uses information in the SegDescrip subdirectory and must be run whenever the segment is modified.

    VerUpdate updates the segment version number, date, and time in the VERSION descriptor.

    Government supplied source code includes approximately 175,000 lines of C programming language code.

    To assess the degree of satisfaction of the functional requirements associated with the government supplied software, functional testing of the applicant port or implementation is required. Any available automated and manual testing of COE kernel government supplied software will be provided to aid in assuring proper function. Appendix D identifies applicable test technology, manual test procedures, and acceptance criteria.
    3.4 Security Certification Criteria

    This document identifies security-related criteria for DII COE Kernel Platform certification. Service, agency and system unique requirements are outside the scope of this document, as are the overall security requirements of systems built using DII COE Kernel Platforms. These criteria are drawn from "Defense Information Infrastructure (DII) Common Operating Environment (COE) Security Software Requirements Specification (SRS)", Version 2.0 - 8 July 1996 .

    This evaluation verifies the presence and configuration of basic DII COE Kernel Platform security features and capabilities as identified in Appendix E of this document. These security features and capabilities are grouped into the following categories:

    1. Identification and Authentication (I&A)
    2. Security Audit
    3. Service Availability
    4. Discretionary Access Control
    5. Object Reuse
    6. Data Integrity
    7. System Integrity
    8. System Architecture
    9. Trusted Facility Management
    10. Other Requirements

    DII COE Kernel Platform Certification security evaluation and criteria supporting DII COE Kernel Platform Certification does not replace or satisfy security testing required by Department of Defense Directive 5200.28 (1988).

    The vendor applicant will also develop and deliver a security checklist as an aid in assuring that the candidate application platform satisfies the security criteria in Appendix E, Part 1. A sample security checklist specifically developed for the Solaris 2.4 DII COE platform is provided to applicants in part 2 of Annex E to accelerate the process of checklist development.

    DISA security personnel will evaluate the suitability of the checklist provided by the vendor. This evaluation will be performed by the government at no charge to the vendor applicant. If the checklist is found to be an functionally equivalent to the existing checklist, and an effective method for demonstrating satisfaction of the criteria in Appendix E, the checklist will be accepted. The checklist for this platform will then be executed to assure that the application platform implements those features and capabilities.

    Issue: Evaluation of the security checklist will be time and skill intensive.
    3.5 Internet Interoperability Demonstration Certification Criteria

    These simple demonstrations provide a basic, yet cost-effective, verification of TCP/IP interoperability, and basic BSD sockets API support. They also provide assurance of application level interoperability for several key services and protocols, such as File Transfer Protocol (FTP) and Hyper-Text Transfer Protocol (HTTP). The scope of each test is limited, but DISA investment in more formal testing can be made over time to expand the scope of assurance, as needed. Test plans in Appendix F are used to demonstrate that the candidate application platform supports the following capabilities:

    TCP/IP "Ping" Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides an initial assurance of application level interoperability prior to demonstration of other services and protocols.

    The Ping utility sends a request for simple acknowledgment and displays the result to the user. is used to assure connectivity to a DISA remote validation platform.

    Domain Name Service (DNS) Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Domain Naming Service (DNS) services and protocols.

    This demonstration shows that hostnames are resolved via DNS and can be converted from standard format to DNS format.

    File Transfer Protocol (FTP) Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key File Transfer Protocol (FTP) services and protocols.

    The demonstration suite for FTP uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. Test files located on the remote DISA test platform are transferred to the candidate, and key FTP capabilities are exercised from the candidate platform. Test files located on the candidate platform are then transferred to the remote DISA test platform, and key FTP capabilities are exercised from the remote platform.

    Network File System (NFS) Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Network File System (NFS) services and protocols.

    The demonstration suite for NFS uses ASCII and Binary files located on a DISA supplied test platform and on the candidate platform. A volume located on the remote DISA test platform is mounted on the local platform under test, and key NFS capabilities are exercised from the candidate platform. A volume located on the candidate platform is then mounted on the remote DISA test platform, and key NFS capabilities are exercised from the remote platform.

    Electronic Mail Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Simple Mail Transport Protocol (SMTP) services and protocols.

    The demonstration of SMTP electronic mail uses the 'mailx' commands required by the ISO/IEC 9945-2 (Posix) specification. An electronic mail message is read in from a file, sent to a mail reflector located on a DISA supplied test platform, and is reflected back to the platform under test. The returned message is displayed and saved to a file. This provides some level of assurance that the candidate platform can support both sending and receipt of electronic mail.

    World Wide Web (WWW) Interoperability

    This demonstration provides a first order verification of TCP/IP interoperability and basic BSD sockets API support for the application platform being certified. The demonstration also provides some assurance of application level interoperability for key Hyper-Text Transfer Protocol (HTTP) services and protocols.

    The demonstration of WWW services uses an HTTP 1.0 conforming browser to retrieve a series of HTML 3.2 conforming web pages to and display them on the application platform being certified. The test pages exercise key Hyper-Text Markup Language (HTML), HTTP and forms related capabilities.

    Note: The browser is supplied by the vendor as part of the validation suite, not as part of the kernel platform software.
  • Heh, so would DODLinux replace the common linux commands with their own? "kill" would become "military police action" and "grep" would become a "intensive investigation of magnetic contents to achieve a postive result" AKA IIMCAPR.

    Vulgrin the MAD
  • Perhaps a small tidbit in favor of switching over to Linux for your project would be that the Navy is using Windows NT as the shipboard OS for its warships, and it therefore must be certified as you mention.

    But after a sailor entered a zero into a data entry field aboard the Yorktown, the whole ship's NT network went down and our nation's proud vessel had to be towed into port, as seen here [ncl.ac.uk].

    Of course there's no guarantee that this wouldn't happen with Linux too, but what would make a lot of sense is to use it's open-source nature to create a military distribution, which has been audited for both security holes and reliability defects.

    I'm sure many of the distribution vendors would be happy to do that for a price, but I suggest the military do it for yourselves - but remember the GPL!

    For more such informative anecdotes of computer reliability, please read The Forum on Risks to the Public in Computers and Related Systems [ncl.ac.uk]

    Also, the moderator of Risks, Peter G. Neumann [sri.com] is a computer reliability expert that is held in high esteem by the defense establishment - see for example Practical Architectures for Survivable Systems and Networks [sri.com] which he did for the Army Research Lab.

    He presented a keynote talk for the April 2000 NATO Symposium "The Potentials of Open-Box Source Code in Developing Robust Systems". At the NATO Symposium he handed out a preprinted entitled "Robust Nonproprietary Software" which is available in PDF format. [sri.com]

    I suggest you drop Dr. Neumann a Line.

  • >The open-source nature of Linux sets off a red flag, to most government officals, that says "UNSECURE."

    And, here I thought all this time, it was the root kits run by script kiddies that say 'unsecure', not the Open Source nature. Or the high number of security alerts on security focus for 'linux'. (And, I make good money de-root kitting other people's Linux boxes)

    OpenBSD has managed to convice people that security is an option with Open Source software.

    If time was spent educating that Open Source is not defined by linux, then perhaps the DII/DOE would evaluate Open Source fairly.

  • I note that there's a contact for source code, but apparently there's no downloadable code that one may run to diagnose any level of compliance.

    Pardon me if the following questions are silly, but I'm not familiar with this area of testing (in part because I'm not a fan of mounds of paperwork :)...

    • Is this an open, public standard?
    • If so, is there an open compliance test?
    • If there is, where can it be downloaded?
    • If it can't be, why not?

    Linux and other open source OS's tend to improve (here, read: "conform") better when the goals are open and easily referred to and researched against.

    Further, the philosophy is (and always has been) "If you don't see something you want, you're free to add it yourself." This, of course, includes the government. Apart from the usual politics of budget constraints, what's stopping you (plural :) from developing (or contracting to have developed) a version of Linux or BSD which meets the spec and which can run on whatever hardware meets your needs?

    So the best ways to get Linux into this environment might be:

    • Make the conformance suite immediately available for download, if possible;
    • Develop or contract to develop a variant which specifically meets your needs.

    There are a variety of vendors who offer professional services for the latter. Linuxcare, BSDi, and others come to mind; I don't know their status on any Approved Vendor Lists you may need to follow.

  • I'm reading this on a Compaq ML-330 server running Linux behind a firewall composed of a Sun Enterprise 250 server, also running Linux. In the computing center of a the main headquarters of the Navy Exchange Service Command.

    However, NEXCOM is a NAF (Non-Appropriated-Fund) activity where the "guidelines" are less stringently adhered to.

    And I didn't ask permission, though I have provided volumnious support documentation to justify my decision. I've found that if you through a large enough stack of paper at 'em, they won't read it; they'll just ask where you want them to sign.

  • Because the Certification Criteria document is MS word formated:

    http://diicoe.disa.mil/coe/kpc/KPCP_8/KPCP_8.DOC

    Just think how hard it would be to get another OS certified without NT and Word. IT gave me NT at work and I opened this document with Word Pad. Though I could read it, there were lots of scratchouts and stuff that made things tricky. I'm scared to think of what it would look like under VI.

  • That was nice to see. I've read complaints about Word's big ugly spec and it's hard to belive that little program can pull it out. It was much more than I expected to get out of a bad joke.

    The certification pages were mostly good and plain HTML until I ran into the HOWTO document cited.

    Propriatory formats for document storage are evil.

  • I also work as a federal technician for the US Army. Currently, NT4, HP/UX, AIX, and Solaris are approved for general use... but, the DoD and DoD-CERT (Computer Emergency Response Team) are pushing to certify both SecureBSD and a secure Linux distro. As of now, I have several Linux Boxen running that have been authorized and certified by the DoD to exist on DoD networks. In addition, all of my authorized security tools are written for SunOS and Linux. As far as the COE is concerned, there are no plans to get off of micro$oft until at least 2005. Current fielding plans for the COE include Win2k starting in march 2001. Don't expect much else; if we couldn't run Micro$oft Office, the government would come to a screeching halt. Remember: Stupid Users.
  • if i remember correctly you have to pay lots of $ to someone to be certified as "real" UNIX. i dont see why we should waste money on such useless things....
  • actually i believe that va linux and linux international are making efforts towards getting gnu/linux certified as "real" UNIX.

    i believe there a lots of smarter ways for redhat or any other linux vendor to support free software community. i mean only big companies and govermant organisations care if gnu/linux is "real" unix or not. so those are the ones that should pay for getting gnu/linux unix certified. why should redhat which is selling linux mainly to private person pay.
  • Might try checking out the news groups [disa.mil] related to the subject. Maybe with enough comments there some additional improvements can be made to the whole environment.

    I have worked with it in the past and must agree, it is more a hinderance then a help.

    DII COE uses segmentation to package things up, which allows easy installation, removing, documentation, source (for development). A lot of these segments just package things up and install using tar or any other appropriate install tool with an install script. This can be a way to allow for overcoming some of the shortfalls of this.

    BreezyGuy

  • Right on! As a former military guy I remember the misery of working on "DII/COE compliant" systems. What a horrible waste. The DII/COE "enhancements" took my nice little sun workstations and brought them to their knees. All this while providing virtually zero added benefit. My office was able to assemble a far superior system just by putting all the applications we needed on some good workstations (not NT!). Like you, everytime DII/COE was mentioned in the office or at exercises everyone just laughed or blurted out some nasty comment. We need to stop letting high-ranking officers and civilians who have no clue about systems dictate our selections.

    The US gov't: Aspiring to mediocrity and failing to achieve it!
  • I hate to bring it up, but this could be one application where the open source/tweakablity that Linux lovers love so much may be a liability. You could submit one build to the government, and they might say "OK this setup is acceptable." But if you get a patch or update, or someone wants to customize it differently do you have to submit the whole thing as a new OS for complience testing?

    For that matter, if you get one person on the complience "panel" or whatever it is that understands how Linux works, how could they reasonably pass it knowing that what ends up on any given machine may not be the same as what they passed?

    -Kahuna Burger

  • Working in an environment that competes against COE based products, we have the same problem that it sounds like you do. Consider the following methods of getting around such requirements.

    1. COE requires a certain "Style" well, that is FINE and easy to do. Make that so.
    2. COE cannot do certain things that your platform can. This is how we are able to get in the door and close it on COE.
    3. DONT STAY WITH THE US GOVERNEMNT. They are one of the worst customers I have ever had. Canada is the best...

    Let me clarify somethings. The US governement use of products are required by a lot of other NATO countries before they think of purchasing a system.

    The US governement contracts are typically Best Value, and so even if you are small and have best price you can lose to a raytheon.. BEST price rules in NATO.

    The US Governement will come in behind the contract and take money back. This is true even on fixed price contracts. If you bid 4 million on a project and when you are done the ACTUAL contractual price then is audited and you may lose hundreds of thousands of dollars at the whim of the US governement auditor.

    COE has to go away. Many of the people working in COE agree to this as well. It is bad that large companies like SAIC, ENRI, and others that get a large constant funding to keep COE around.

    ---
    None of these views is from the company I work for. If you find out who I work for, do not even think of holding them responsible. I choose to take my own time to write this for the benefit of others. Go away and play with someone who actually represents thier company on the net.
  • Ahhh...

    My time for a little rant.

    Why do people insist on saying because Linux is open source it is insecure. That is patently false. FALSE.

    If you make a distro and you do not include the kernel source no one is going to come on and mystically change your kernel.

    TO me that says the chances of someone getting ahold of IRIX, Xyz Unix source code and or modifying the kernel is just as good as any well setup Linux boxes. Oh no.. its open source we just cant have that someone might root our system and replace our kernel with a rogue kernel.. *right*.

    Are you sure its a government thing or a teachers misinterpretation? You know people *HAVE* seen the source for all of these OS' so they are just as weak using this severely flawed logic.

    I wont stand for it anymore arrrghh.

    *goes back to his corner of /.

    Jeremy

  • Since NT is not UNIX and compatibility is not expected, POSIX is irrelevant.

    GNU's Not UNIX® either, which makes this whole article moot according to your logic.


    <O
    ( \
    XGNOME vs. KDE: the game! [8m.com]
  • So you're saying "no self-respecting programmer would use" Cygwin [cygnus.com], the POSIX layer for Win32?
    <O
    ( \
    XGNOME vs. KDE: the game! [8m.com]

  • [Missing symlinks] are causing far more difficulty than the fact that X and Win32 GDI are completely different.

    Tiddly-day, especially when one considers that the GIMP [gimp.org] toolkit (GTK+ [gtk.org] & Co.), allows one application to be written for X and Win32 with minimal OS-specific code.


    <O
    ( \
    XGNOME vs. KDE: the game! [8m.com]

  • But use Cygwin if you're really that enamored with the Win32 subsystem.

    Especially when you're porting Win32 apps such as GIMP from *n?x to Wintendo 9x.

    And it's Certified POSIX compliant, not wannabe.

    All Red Hat needs to do for Cygwin is get UNIFIX's help like it did for GNU/Linux (glibc + GNU *utils + Linux kernel).


    <O
    ( \
    XGNOME vs. KDE: the game! [8m.com]
  • Hey, look. Even with NT, the certification they've had has been for a particular setup. Strip this, reconfigure that, do this.

    Of course, admins still change things and then they aren't compliant. The cool thing would be if every time a program was deemed DoD-useful, it would be submitted. I mean, do you know what's in IIS? I don't and I doubt the DoD does. But I'm willing to be some DoD servers have IIS on them.

  • NT may be POSIX certified to some degree, but there's no way it can run half the programs the new (1997) requirements specify...

    So, well, maybe we should be investigating whom Microsoft has potentially bribed?

  • Please elaborate on how NT4 has worse standards than linux. In case you didn't know the option pack provides a lot of POSIX tools.
  • haha, funny thing about NT and Posix... correct, Posix doesn't have jack beans to do with DII-COE compliance for NT. actually, for INFOSEC compliance, the Posix subsystem in NT is suppose to be disabled.
  • cool, i need try that on one of our sratch boxes. diicoe running on top of gnome and enlightenment w/ java chart up *muahahhaha* talk about bringing a box to its knees. hopefully in the next couple of weeks the GNUGTK segment will be coming to a DISA CM near you soon!

  • DII-COE Rants, etc... (Score:5)

    by merricks ( 146797 ) on Friday September 01, 2000 @03:42AM (#812134)
    -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-
  • On one page they list that only Tru64 Unix on an Alpha platform is certified, while their FAQ lists Solaris 7, HP/UX, and NT4.

    However, Linux adheres mcuh more closely to their standards than NT4 (actually, how NT4 got there I don't know as it seems to fail the POSIX requirements amon other things).

    I think the initial problem was that Linux didn't have a vendor to assure compliance and as such could not qualify. FWIW - I also believe that the DII/COE guidelines are being ammended to take that sort of situation into account (specifically because a wide number of vendors and contractors are pushing it).

  • What ever happened with this? [slashdot.org]
  • I was just on board the Ike and they were using NT as terminals on both their classified and unclassified networks, but their command and control systems were a mish mosh of systems from different upgrade cycles. I heard the same story about the ship being stranded because of a blue screening NT server, but I thought it was a destroyer. Couldn't the Military just approve certain kernels and have their own central mirror of the approved "secure" kernels.
  • I don't see how stating that "TFTP is inherently insecure" is pushing it as far as security goes. I mean, it IS insecure by design, everyone who knows anything about TCP/IP knows this.
  • More proof that government personnel may be listening to too much self-expert or contractors' smoke, fog, and wind. This is a silly non-starter issue. OSS when compiled and encrypted (System authentication and key required to run/function) is as secure or more than ... it won't be "tweaked". I sat in a meeting (about three years ago) on the issue of a system's security (everyone stated how the system was to be secured). I made one statement that proved all others flawed. I was told "I could not discuss my comment outside the room because the content of the statement was classified (to the level of the system)". I offered options to (I believe/think) provide the security (all I/O data encrypted, no writeable removeable media, keyed CD-ROM OSS and applications loading, increased RAM, and all I/O data encrypted on hard disk ... plus) wanted. I never attended another meeting, because, I only made, one five sentence comment after about two hours of meeting. Anyway the below cause/story does not ring true to me, and if true then very flawed .... Linux, I believe, has the potential to provide the greatest control/security (for systems and software) ever allowed to any government (why should the government trust what is delivered by MS, SUN, SAP ...) person or company when you control everything on your system, know what everything is there for, write your own "SECRET" source code programs that are never part of OSS for others to see/use. The future says that governments (not only US) may want to follow all the freedom loving individuals (around the world) in the OSS movement, IBM and others into standardizing on an OSS for the world. You said; "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.""
  • Read my other post [slashdot.org] to find out about NT4 and DII/COE compliance...

  • Linux and DII/COE compliance... (Score:5)

    by Penguin_99 ( 169189 ) on Friday September 01, 2000 @03:49AM (#812141)
    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....
  • So the cost of segmentation, a users guide/manual, QA, and everything else that go into a DII COE segment are free? Unfortunately, we have to go through this far too often.

    A well supported segment takes three months (full time) to get it in. If someone has a problem or you don't have someone to push the segment through for you? Now you're looking at more like six months or longer.

    I'd love to see Linux and other OSS as accepted but if it doesn't have a sponsor it's not going to make it. And to have a sponsor you need to have someone at the top who sees the value of it. To have someone see the value of it needs either a marketing weenie whispering sweet nothings into an admiral or general's ear or having a very forward thinking or technically literate admiral or general.

    So you need a sponsor, with money, that has the authority, capability, and backing to go against the established norm and commit something new and different. If you've worked that long with the military and contractors then you know that this isn't generally how it works. New things are generally frowned upon so instead old things are modified: slightly different segment, same name. This is iterated on until there is little or nothing of the original left except the name. And yes, this does cause some really interesting code.

    Believe it or not there are quite a few proponents of OSS within the government. The problem is that they aren't in positions (yet) to be able to sway opinion enough. Hopefully, someday they will be.
  • That's funny - all of the distros I've installed put the kernel source in /usr/src/linux by default... slack, rh, mandrake, debian... what distro are you using that doesn't install the source for you???
  • Huh... it put it on my system - what kind of install did you do? I used the CD (maybe you used ftp, so it didn't want to waste the time?)
  • One of the main pains in DII COE is called "segmentation" - it's not fun at all. Naturally, being good members of the military-industrial complex, companies involved in the spec figured out how to make cash off it.

    The Segmentation Center [segmentationcenter.com], operated by SAIC, will do the vast majority of the DII COE (and JTA - don't forget about that Joint Technical Architecture that DII COE came from) compliance and segmentation work for you.

    Now, in the DoD Make vs. Buy world, shelling out your program cash may not look good - but it's cheaper to have these guys do the work and have it pass certification the first time than training your own folk up, doing the work, and running a good chance of blowing it when it goes up for review and certification.

    And yeah, I work for SAIC - but not for these guys. I've just used 'em - made this decision myself a LOONG time ago.

  • A DII/COE Closed-Parallel kernel would not be the end of the world. I'm sure for the right sum Linus, Maddog, and afew other people could come up with a DII kernel in parallel with the public releases. perhaps at a rate of one DII for every other four public releases. Is this possible? All it would have to do is look and act like a linux kernel to applications right?
  • Well, I use DII COE on a Sun box running Solaris, but if you really want the *nix experience on a (much cheaper) PC, what's stopping you? Very few of our PC's are DII compliant, we can do whatever we want with them as long as our development machines, where everything gets sent to when we finish development, is. We've got quite a few linux boxes around here, but I'm happy with my Workstation. It may be expensive, but if it's there, use it! :-)
    PS, there have been rumors about moving some government systems to Linux. Mostly it seems to be coming from army/marine sectors, but its a start. All you need is a few Admirals/Generals who like linux and suddenly it becomes a high priority.

  • Oh, trust me, it'll hurt... I was running on an UltraSparc 60 totally clean machine. It only took about an hour before I had managed to slow it to a crawl. (Burning 100% of both CPUs, it took probably 5 minutes to get a terminal open to kill off some of the processes.)
    Next I'll see if I can get it to run in single-user mode :-) Who needs gui's anyway???

  • Sorry to hear you have to work with HP :-) We've just managed to get rid of those cursed things.
    We've been using DIICOE 4.2 here, and while it is a lot prettier, the big advantage is that we've sucessfully run it without CDE. (Sighs of relief)
    Most of our apps for it are being written in java, which is fine for some of our heavier workstations, but I'd sure like to get something more stripped down for some of our stuff that'll be going in the field.

  • I have only 'seen' a few 'secure' systems in my day and they ran internal devs of some unix variant off of firmware. All the apps (and I think to some extent, the NOS) were distributed accross the newtork. Very nasty, scary, expensive systems. Sorry I cant be more specific, but maybe the ABC sections of our government are not sharing their knowledge with the military. Wouldn't be the first time.
  • I work in Computer Management for the network control center of Minot AFB, ND. My side mainly deals with buying computers and software. I try to influence the thinking of my superiors, but NT4 is all they know or want to know. Nix is not even considered. I desperately want to change their thinking anyone have any ammunition to throw at them or any ideas to help change their mind? FYI the base is split into 2 ncc's. The spacewing runs novell and we the bombwing runs NT only. The only nix is used is on the firewall and on the email server and its at&t's version whatever. Any questions give me an email i'll be happy to answer.
  • Yeah, you're right i'm sorry. Nevermind.
  • The truth of the matter is that that type of compliance, while dictated, constantly gets thrown out the window in the name of reliability.

    For Instance... Utilizing a Linux box (running Debian) isn't "prescribed" by AFCERT (The Air Force Computer Emergency Response Team). For Network Control Centers, AFCERT guidelines are the defact bible of day to day operations.

    But, those are "guidelines", and nothing more. Linux has been used before by the military, both as a perl compiler, and as a DNS router. Want UNIX? HP Unix, Solaris, Free BSD, what... All these have been used in one way or another by the military to provide reliability.

    Military Network Control Centers are not basic lego block modules that are just moved around from one place to another with big trucks. Since every base varies in size, and requirements, the equipment purchased will vary as well. Network Technicians with their own ideas of what is a good OS, and what is not will also place some changes in the system. In the end, the local commander has the ability, and the responsibility to balance regulations with performance. They are also responsible for the Network providing good performance.

    Basically, in the end, it's their choice, and their ass. Most opt to let the professional techs decide what is best for the network.

    krystal_blade

  • Redhat 6.1 did not install the kernel source for me. It just left a document that said where I could get it.
  • Sounds like a niche market to me, and I'm guessing that Compaq/Digital and IBM have already gotten a strong hold on it (with MS gaining, due to crazy large money to throw at the problem). I'd think that this would be a distracting side project to most Linux distribution companies right now. Red Hat, Caldera, and Corel (couldn't get SUSE investor info in English this morning) are not "making lots of moolah". They all use red ink to print their bottom lines. I'm guessing no retail distro comes out of the box compliant with and DoD standard. So, this is probably more than just paying a fee and giving some military testers a boxed set and waiting for the certificate to come in the mail. But then again, maybe building a relationship with the military is a good investment, it sure hasn't hurt Compaq or IBM has it?

  • What about tripwire, md5's and PGP sigs oh my!
  • I think the original point sounded like meeting POSIX standards was a subset of meeting these COE standards. POSIX is a nice set of unix-influenced, but certainly not unix-specific, standards. Microsloth needs to get on the ball and at the very least support the system call part of POSIX fully and correctly....
  • Well, I seem to remember Linux kernels for a long time now spewing a bootup message similar to: POSIX conformance testing by UNIFIX. So I'm thinking Linux as a kernel conforms to POSIX by testing, but perhaps not officially the way a commercial unix is.
  • OPEN SOURCE AND THESE UNITED STATES

    By C. Justin Seiferth, Maj USAF

    http://skyscraper. fortunecity.com/mondo/841/documents/index.html [fortunecity.com]

    This is a research report submitted to the faculty of the Air Command And Staff College, Air University, Maxwell AFB, Alabama

  • SecureBSD? (Score:4)

    by PHAEDRU5 ( 213667 ) <instascreed@gmai[ ]om ['l.c' in gap]> on Friday September 01, 2000 @03:51AM (#812160) Homepage
    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.

  • Open Source Development Lab (Score:4)

    by Tough Love ( 215404 ) on Friday September 01, 2000 @03:38AM (#812161)
    I had something to say [slashdot.org] about this a couple of days ago. The new industry-sponsored Open Source Development Lab [salon.com] 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.
    --
  • Programmeurs rouges dans le Departement de la Defence?

  • This is a FACT. It was widely reported in the news about a year to year-and-a-half ago. Fresh trial run of a navy ship using NT and it craps out very quickly. The ship WAS disabled and had to be towed back to port. Fact.

    Here's a link to start you on your educational journey:

    • http://slashdot.org/articles/980721/1049204.shtm l
  • word2x [tex.ac.uk] makes a decent enough job of it (although I've only looked at its plain text output).
  • Let me first say that I work for a small security company and have had to port things to the DIICOE environment; working with DIICOE in general is not anything that I would wish upon my worst enemy. The DIICOE certification is not like POSIX or any other certification driven by a standards organization... You get DIICOE certification by playing the politics game (The reason that HP-UX and NT are certified). Also, in order for a unix system to be considered DIICOE compliant, it must run a bastardized version of CDE (you know, the abortion of a Motif look-alike) as well as have a herd of memory sucking daemons running behind the scenes.
  • First off, its always about money ;) Secondly, if you think that an undertaking like Linux (or any OS for that matter) would only cost a few hundred dollars, then you are only looking at the cost of procuring the OS itself. While Linux may be freely distributed, coding the Military's very specific pieces of hardware would require a huge undertaking employing numerous engineers many man hours. Then there are the security issues. Not that Linux isn't fairly secure, but DOD marches to the beat of another drum. Most of the stuff is absurd, but none the less it is DOD policy. Once that is all said and done the systems must be tested and certified, agian, not without its price. Then there is the training effort that takes place. There will be a learning curve when you introduce a new OS to the field. So hopefully you can see where a few hundred bucks can and will span into a few million when all is said and done. With all that said, I am willing to use the tax dollars I donate in pursuing a solid OS that will hopefully give the War fighter, that protects my freedom, the tools that he/she needs to accomplish a very complicated job.

Slashdot Top Deals

Anything free is worth what you pay for it.

Close