Figure 2-6. POSIX Interfaces
Operating systems provide access to local computing resources (e.g., processes) and platform services (e.g., peripheral hardware devices). In addition, operating systems provide access to distributed platform services such as network file systems and naming services. Access to network protocol stacks is also provided through operating system service interfaces. Operating systems mediate access to computing resources between applications and unique platform and network hardware. The operating system provides many of the services for distributed computing.
Standards based operating systems use formally defined interfaces APIs for application program access to platform resources and are the basis for building open systems, which are the basis of distributed computing. Non-standard operating systems provide implementation unique interfaces for applications development which requires unique coding for each platform. DODIIS is fully committed to the use of standards-based interfaces for applications program development. What is left for discussion is the level of standardization for operating system services, the types of operating system services, and the means to identify compliant operating systems.
DODIIS efforts to define a standards based API infrastructure for portable software development on heterogeneous system has led to a mixture of standards to define the operating system environment. Standards for DODIIS operating systems (see table 2-12) are not set to a single standard, but are an amalgamation of standards (formal, public and proprietary) that build upon POSIX and provide additional functionality to address the current shortfalls of POSIX standards.
Table 2-12. Operating System Service Standards
POSIX provides common functionality among unique processing platforms through a standard API to access operating system services. POSIX compliant operating systems are not standardized on their own, but they do provide the POSIX standard interfaces and library functions needed to access unique system resources.
The POSIX standardization effort consists of IEEE and ANSI committees that have been organized by the Standards Subcommittee of the IEEE Technical Committee on Operating Systems to address issues inherent in standardizing the interface used by applications to obtain operating system services. Committee efforts are documented in POSIX specifications, that are in various stages of completion. Although some of the most critical parts of the POSIX interface standards have been or are close to being defined, there are still many outstanding standardization issues. In addition there has been a realignment of POSIX standards to reflect the functional nature of the POSIX documentation (e.g., kernel, commands and utilities, and corresponding validation specifications) and other IEEE standardization efforts. See appendix B for a complete list of POSIX efforts.
X/Open is an independent international organization dedicated to providing a unified path to open systems specifications and implementations. X/Open was founded in 1984 and is a non-profit corporation, incorporated in the United Kingdom. X/Open is dedicated to "accelerating practical implementation of open systems". X/Open is not limited to Unix or X Window-based systems, but includes Disk Operating System (DOS)/Windows and Apple platforms within its charter as well.
X/Open's strategy for achieving unification is through the close cooperation and integration of input from users, vendors and standards organizations worldwide. The X/Open specification, which is called the Common Application Environment (CAE), covers both interoperability and portability elements and is based on de facto and international standards. Components of the CAE include, among other things, an evolving portfolio of practical APIs which significantly enhance portability of application programs at the source code level and definitions of and references to protocols and protocol profiles which significantly enhance the interoperability of applications. In addition, X/Open operates a test and verification process for products conforming to its specification and awards its brand as the mark of compliance.
COSE is an alliance of the major Unix vendors formed in March 1993 to unify the Unix industry and deliver a common open software environment across their Unix platforms. COSE vendors are collaborating on specifications in many areas of open systems which include a common desktop environment, systems management framework, distributed computing and common APIs.
The COSE group is currently operating through X/Open for specifications, providing the COSE baseline and validation test suite to X/Open for standards enforcement and management. X/Open, in turn, will either update or extend XPG4 to cover COSE standards. As part of the Unix unification effort, the Unix trademark has been transferred to X/Open, requiring future Unix operating systems to pass the baseline X/Open validation suite in order to use the Unix name. Additionally, X/Open and the Open Software Foundation (OSF) formed a strategic relationship in March 1994 to manage the COSE development process.
There are additional technology areas that are to be covered in future versions of COSE compliant Unix operating systems, including Data Management, Distributed Computing/ Networking, Federated Naming, Graphics, Multimedia, Objects, and Systems Management.
Future COSE technologies will be adopted by the DODIIS community on a case-by-case basis as supported by various members within the COSE group. DODIIS supports the initial COSE endeavors and will review future COSE efforts in light of functional requirements, formal standards bodies, and industry acceptance.
NIST has developed a conformance test suite to provide standard methods for ensuring POSIX compliance. All POSIX products that are selected for DODIIS should be formally tested using the NIST test suite. The test suite is available from NIST for anyone who needs to test for POSIX compliance. Each version of the POSIX operating system must possess a NIST certificate of validation.
DODIIS operating systems must also be X/Open "branded" to certify that they satisfy X/Open conformance testing. Note that all testing for X/Open is conducted by the vendor and does not carry the weight that formal certification would bring. Eventually COSE will establish its base test suite and all COSE systems will have to pass formal testing to carry the Unix trademark.
The incompleteness of the POSIX operating system standards definition creates a potential problem for DODIIS organizations that are currently developing or acquiring software. As illustrated in figure 2-6 , POSIX compatible interface services do not normally make up an entire operating system product. To overcome this near term limitation, DODIIS requires operating systems to be both POSIX compliant and X/Open branded. "Unix" compliance will replace "X/Open" branded requirements when the COSE test suite becomes available.
Developed applications should use only POSIX interfaces where possible. However, when POSIX interfaces cannot be used to satisfy a requirement, alternatives defined by the COSE SUS may be used.
All newly developed shell script programs will use POSIX.2 compliant Korn shell when available in the native operating system environment. Use of "C" and Bourne Scripts are permitted when it is not feasible to use Korn scripts to modify or integrate existing shell scripts.
The DMB also recognizes that performance considerations will sometimes make it necessary to grant waivers to the use of POSIX compliant operating systems, especially in environments which support mainframes, embedded processors or dedicated servers. Any development waivers for standards compliance must be processed in accordance with the DODIIS Management Board Concept of Operations.
The operating system (OS) kernel provides the low level services necessary to create and manage processes, execute programs, define and communicate signals, define and process system clock functions, manage files and directories, and control input-output processing to and from peripheral devices. The OS kernel provides application software access to vendor unique device drivers and software entities through standard POSIX interfaces and libraries for all POSIX services. Non-compliant interfaces and vendor extensions should only be used when there are no standard POSIX services available to satisfy a specific requirement. The use of non-standard vendor extensions reduces the portability of the developed application.
Figure 2-6. POSIX Interfaces
The DODIIS Profile defines which POSIX specifications are applicable to the DODIIS client server computing environment, by functional area and provides gap standards where POSIX standards are currently not available. FIPS PUB 151-2 provides a consistent tailoring of components and options defined in the POSIX specifications to maximize consistency across Government implementations.
There is a common misconception that the POSIX functionality described by NIST in FIPS 151-2 is unique compared to IEEE, ISO, or ANSI POSIX. However, this is not the case. NIST has always been active on the POSIX committees, but found it necessary to tighten POSIX specifications by mandating certain options and alternatives for developers. In fact, FIPS 151-2 adopts ISO/IEC 9945-1 as the base POSIX standard. The DODIIS Profile adopts FIPS PUB 151-2 definitions and provides no further tailoring of options at this time. Note that ISO/IEC 9945-1 is a minimal standard and additional services will be eventually approved and added to the base POSIX kernel standards.
Although system-level services are necessary for application portability and interoperability, they are insufficient for many users' system needs. To maximize portability, users also require standard access to the tools and utilities. Standard command interface services facilitate successful porting of software, help users to manage and maintain applications, and solve problems on an ad hoc basis. Standardization of utilities allow users and programmers to move from platform to platform without having to be trained for each system's command interface.
Standard source code interfaces to POSIX utilities and command line services are specified in FIPS PUB 189, which is based upon IEEE P1003.2. Standards for the basic shell programming language and a set of utilities to support shell script portability are also included in IEEE P1003.2 (see section 2.7.1.5 for specific directions on the use of shell scripting languages). ISO 9945-2 is the basis for the IEEE P1003.2 specification. However, because there are some service requirements for programming support defined in ISO 9945-2 that have not been specified in IEEE P1003.2, the two documents are not entirely equivalent. Also, because the IEEE standard allows for the use of obsolescent features, NIST has published FIPS PUB 189. The FIPS PUB eliminates the obsolescent features and thereby provides more effective control of the command and utility integration process. Conformance with DODIIS guidelines requires adherence to FIPS PUB 189.
Real-time operating system services are extensions to the operating system kernel that provide capabilities to respond to external events, interrupts or scheduling on an autonomous basis. Real-time services are defined as an extension to the IEEE P1003.1 standard in IEEE P1003.1b. Thread services are specified in IEEE P1003.1c which introduces issues concerning concurrent processing. Real-time services also provide POSIX extensions (IEEE P1003.1d) to cover the following areas:
IEEE P1003.1b, IEEE P1003.1c and IEEE P1003.1d are still in draft stages and will be published as a separate standard in a FIPS PUB after they are finalized. The real-time extensions to the POSIX kernel and the corresponding FIPS PUB should be specified for all DODIIS products and projects that require real-time or threads services.
Networked information systems are composed of a wide variety of diverse resources that must be managed effectively to be used successfully. The adoption of a common management model enables administrators to manage numerous resources without having to learn different techniques for each resource. IEEE P1387 does not supplant specific management policies, but is directed towards providing standard user level interfaces to POSIX operating system administration services. The list of requirements for systems administration could be very extensive, but the initial efforts for IEEE P1387 are focused on specific functional areas, such as print management, software management and user environment management. IEEE P1387 is a draft standard at this time and it appears that it will remain so until there is convergence and consensus with other management standards efforts. Additional management areas will be covered in subsequent updates, but the IEEE P1387 effort is currently focusing on system administration areas that are well defined (see section 2.9 ).
DODIIS sites are required to establish and maintain effective security measures to ensure protection of information processed or stored in automated information systems (AISs)
(e.g., workstations, servers) and networks. The overall objective of these measures is to ensure that information residing within AISs and networks is safeguarded against unauthorized disclosure, tampering, loss, and destruction. The primary DODIIS security policy documents are the following:
These security policy documents provide general security policy guidance and identify minimum security requirements intended to improve the security posture of AISs and networks. More stringent requirements may be established by the Accrediting Authority for selected AISs and networks based on an assessment of acceptable levels of risk.
Operating system security services are specified in terms of controlling the access of users, or processes acting on their behalf, to the data, functions, hardware, and software resources of a system. Access control policies include discretionary access control (DAC) and mandatory access control (MAC). In addition to access control, other security services include individual user identification and authentication (I& A), data confidentiality, integrity (e.g., system integrity, Trusted Computing Base (TCB) integrity, label integrity), security audit, object reuse, and availability of service and data.
The Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), DOD 5200.28-STD, has been selected as the DODIIS security standard for operating systems. Network security services are discussed in section 2.6.5 .
In addition to these minimum operating system security requirements, DIA has also developed workstation-specific security requirements documents for the DODIIS community. A brief discussion of these documents follows. Table 2-13 provides a summary of these workstation security requirements documents.
Table 2-13 . Workstation Security Requirements Documents
A standard being monitored for potential inclusion within the DODIIS profile is the Common Criteria (CC) for Information Technology Security Evaluation, commonly referred to as the "Common Criteria". The Common Criteria, under development by representatives of the United States, Canada, and the European Community, will support evaluation of the security properties of information technology (IT) products and systems. The CC will also be the basis for evaluations that determine the effectiveness of the security functions and the level of trust which users may place in the correct implementation of those functions. The CC will also useful as a guide for development of products or systems with IT security features and for procurement of commercial products and systems.
