【正文】 application code that results in buffer overflow vulnerabilities ? Password cracking or weak password encryption ? Poor or unsecure system configuration These vulnerabilities are further plicated by legacy UNIX design considerations. Unix was originally designed for universities, researchers, and government agencies who wanted to share information extensively. As such, it was not originally designed to be secure in the early days of UNIX. Today UNIX is applied in mission critical systems where security is mandatory, and special care must be taken to secure what has historically been an unsecure environment. Assurance The above concepts () are features of an operating system. Features themselves are not enough to determine the security of a system. Assurance that the system?s security features work as advertised is required for some applications, particularly military ones. Two basic classes of assurance exist: vendor self assurance (through their own design, development, and testing process) and independent third party evaluations. The third party evaluations most monly used today are the US Government TCSEC (Trusted Computer System Evaluation Criteria) and European ITSEC (Information Technology Security Evaluation Criteria). Because these processes are lengthy, on the order of multiple years to plete, they are not usually specified in mercial procurements. Often formally evaluated mercial products are obsolete before the evaluation process is finished! US Government Security Specifications and Levels With the pletion of the TCSEC referenced above, the US Government defined a set of security levels products could conform to. These classes are frequently specified in RFPs. They are (in order of increasing security): ? Class D (Minimal if any security protection) (example: DOS, Windows) ? Class C1 (Discretionary Access Control) ? Class C2 (Discretionary Access Control and Accountability) (example: Windows 20xx, Trusted Mode HPUX, MVS with RACF) ? Class B1 (Mandatory, Multilevel Access Control) (example: HPUX , MVS with RACF) ? Classes B2, B3, A1 Of these classes, C2 is a defacto standard for mercial secure UNIX type systems. C2 systems mediate access based upon a resource owner?s discretion. That is, the owner of a resource primarily defines who on the system can access his/her information. HPUX Security White Paper 8 B1 systems are required for some government, military, and mercial applications. B1 systems support the security required to store multiple levels of classified information (., confidential, secret, top secret) on a single puter system. A B1 system will prevent a user with a confidential clearance from accessing top secret documents, regardless of the top secret document owner?s discretionary control. B3 and A1 systems have the same functional requirements: they represent increasing levels of assurance or trust in the implementation, reliability, integrity, and delivery of security. European Security Specifications and Levels The European ITSEC specification defines functional levels independently of assurance levels. In general, the functional levels correspond to the US Government and are designated as “FC2, FB1,” etc. The assurance levels are in ascending order with E1 being lowest and E5 highest. A typical ITSEC evaluated product will have a rating of FC2, E3, meaning that the product has C2 functionality with an assurance rating of E3. Commercially oriented products are usually certified to an E2 or an E3 assurance level. The discussion of ITSEC assurance requirements is outside the scope of this paper. While European and US assurance levels really are not parable to each other, rough approximations can be made as shown below. Rough Comparisons Between European and US Assurance Specifications European ITSEC US Government TCSEC Minimal Protection E1 D Functional Security Testing E2 C1 C2 E3 C2 B1 Descriptive Top Level Specification and Verification E4 B2 B3 Formal Top Level Specification and Verification E5 A1 Warning: The European scheme and the US criteria look at assurance in very different ways. The mapping above is very coarse. Customers who are knowledgeable in Government security standards may differ with this assessment. Extensions to Security Specifications The above specifications were originally written for monolithic mainframeoriented systems. With the advent of clientserver, worked puting, additional work was done to extend the meaning of the specifications to the new paradigm. The US Government developed the Trusted Networking Interpretation and the Trusted Database Interpretation of the TCSEC. These apply the security concepts above to works and databases respectively. These interpretations are outside the scope of this paper. HPUX Security White Paper 9 HPUX Operating System Security Functionality This section describes the security features in the general purpose, mercial HPUX Release operating system. Only basic operating system security is discussed: kernel and UNIX mands. Systems that fall outside the scope of this presentation are: ? XWindows and Common Desktop Environment ? Distributed Computing Environment ? Separate products such as IPSEC, Java, Intrusion Detection, Firewalls, ? Public Key Infrastructure ponents and products ? Hardware cryptographic accelerator cards ? Praesidium Applications and middleware ? OpenView ? Virtual Vault ? B1 special releases such as , , etc.… Two Modes of Security in HPUX HPUX can be configured to operate in one of two security modes: Standard Mode, and Trusted Mode. Standard Mode is the default configuration of the OS. HPUX is C2 Trusted Systems pliant in the optional Trusted Mode.