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."
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.
----
----
Open mind, insert foot.
Show me one single source that says that the OS did not crash. (A non-Microsoft source that is.)
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
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.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
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.
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).
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
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 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"
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)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
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?
Those who can do. Those who can't sue.
This describes DII COE accurately.
Those who can do. Those who can't sue.
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.
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).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
Eve Fairbanks says I drive a hybrid!LOL
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
Eve Fairbanks says I drive a hybrid!LOL
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
Eve Fairbanks says I drive a hybrid!LOL
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!!
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.
The following text identifies specific criteria that must be satisfied for DII COE Kernel Platform certification.
, Internet Protocol, 1 September 1981. In addition, all implementations of IP must pass received Type-of-Service (TOS) values up to the transport layer.
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,
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
I sig, therefore I am.
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.
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
Also, the moderator of Risks, Peter G. Neumann 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 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.
I suggest you drop Dr. Neumann a Line.
-- Could you use my software consulting serv
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 :)...
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:
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 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 you know yourself but not the enemy, for every victory gained you will also suffer a defeat." -Sun Tzu
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
...will work for Chick tracts...
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!
Will I retire or break 10K?
So you're saying "no self-respecting programmer would use" Cygwin, the POSIX layer for Win32?
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
[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 toolkit (GTK+ & Co.), allows one application to be written for X and Win32 with minimal OS-specific code.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
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!
Will I retire or break 10K?
So, well, maybe we should be investigating whom Microsoft has potentially bribed?
The power of accurate observation is commonly called cynicism by those who have not got it. - G.B. Shaw
-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-
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).
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....
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
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
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.