The Common Data Security Architecture (CDSA) from the Open Group is a flexible standard that defines APIs for security services needed for implementing public key infrastructure (PKI). The emerging IETF public key infrastructure (PKIX) standards provide certificate management protocols geared reward the Internet. The PKIX specifications define the expected behavior of the PKI, but do not provide abstractions that can be used by exploiting applications. In this paper we show the feasibility and design methodology of extending CDSA abstractions to support PKIX certificate management. To achieve this, we model a general, end-to-end system architecture based on CDSA that 0 PKIX certificate management model, and discuss the merits of this system from the application and system architecture perspectives. We conclude the paper with a discussion of the resulted generic CDSA version 2.0 API that support PKIX certificate management model.

When DCE is implemented on an existing operating system platform, its security facilities need to be integrated with the local security facilities on that platform. One key task in this effort is the integration of the DCE registry and the local security registry. This paper discusses the requirement for registry integration, and considers alternative approaches to a number of major structural issues that arise when integrating the DCE registry with local registries, including:The relationship of the DCE registry with respect to the local registriesPropagation of updates to local registriesSelectivity of update propagation“Push” versus “pull” of updates“Write-through” versus “virtual update”.

A practical method for the identification of covert storage channels is presented and its application to the source code of the Secure Xenix kernel is illustrated. The method is based on the identification of all visible/alterable kernel variables by using information-flow analysis of language code. The method also requires that, after the sharing relationships among the kernel primitives and the visible/alterable variables are determined, the nondiscretionary access rules implemented by each primitive be applied to identify the potential storage channels. The method can be generalized to other implementation languages, and has the following advantages: it helps discover all potential storage channels is kernel code, thereby helping determine whether the nondiscretionary access rules are implemented correctly; it helps avoid discovery of false flow violations and their unnecessary analysis; and it helps identify the kernel locations where audit code and time-delay variables need to be placed for covert-channel handling.>

A formal method for the identification of covert storage channels is presented and its application to the source code of the Secure Xenix* kernel is illustrated. The method is based on the identification of all visible/alterable kernel variables by using information flow analysis of language code (e.g., C language code). The method also requires that, after the sharing relationships among the kernel primitives and the visible/ alterable variables are determined, the non-discretionary access rules implemented by each primitive be applied to identify the covert storage channels. The method can be generalized to other implementation languages, and has the following advantages: (1) it leads to the discovery of all storage channels in kernel implementations, (2) it helps determine whether the non-discretionary access rules are implemented correctly, and (3) it can be automated. An additional important aspect of applying this method to a kernel interface is the discovery of all kernel variables that are modified directly or indirectly through that interface. The analysis of the modification scenarios provides the necessary conditions for all kernel penetration. This implies that, in any kernel that enforces both a non-discretionary security and an integrity policy, penetration instances are the dual of covert storage channels instances.

Secure Xenix™ is an experimental system designed to run on IBM PC/AT workstations. Like Xenix, it is a Unix™ System V implementation on the PC/AT workstation; unlike Xenix, it eliminates the Unix security deficiencies and it enhances security policies. In this paper, we present the design features of Secure Xenix, their integration within Xenix, and some of the lessons learned from this experiment to date.

A new security testing method is proposed that combines the advantages of both traditional "black box" (monolithic functional) testing and "white box" (functional-synthesis-based) testing. The new method allows significant coverage both for security model-based tests and for individual kernel-call tests. It eliminates redundant kernel test cases 1) by using a variant of control synthesis graphs, 2) by analyzing dependencies between descriptive kernel-call specifications, and 3) by exploiting access check separability. A higher degree of test assurance is achieved than that of other security testing methods because the new method helps eliminate cyclic dependencies among test programs for different kernel calls. The application of this method to the testing of the Secure Xenix™ kernel is illustrated.

Secure Xenix * is an experimental system designed to run on IBM PC/AT workstations. Like Xenix, it is a Unix implementation on the PC/AT workstation; unlike Xenix, it eliminates the Unix security deficiencies and it enhances security policies. In this paper, we present the design features of Secure Xenix, their integration within Xenix, and some of the lessons learned from this experiment to date. In addition, we address some of the problems specific to workstations in the security management area. The major design differences between Secure Xenix and other experiments with Unix security enhancements, such as LINUS IV, are also presented. In a companion paper, we present the important problems that arise in the testing of Secure Xenix and their solutions.

A new security testing method is proposed that combines the advantages of both traditional "black box" (monolithic functional) testing and "white box" (functional-synthesis- based) testing. The new method allows significant coverage both for security model-based tests and for individual kernel-call tests. It eliminates redundant kernel test cases (1) by using a variant of control synthesis graphs, (2) by analyzing dependencies between descriptive kernel-call specifications, and (3) by exploiting access check separability. A higher degree of test assurance is achieved than that of other security testing methods because the new method helps eliminate cyclic dependencies among test programs for different kernel calls. The application of this method to the testing of the Secure Xenix* kernel is illustrated. The design and the implementation of Secure Xenix are presented in a companion paper.