“Draft:PitBull Trusted Computing Platform”的意思、由来-开放百科全书

PitBull Trusted Operating System (PitBull)^[1] is a Linux distribution developed by General Dynamics Mission Systems and targeted toward the commercial, government, and defense markets.

PitBull incorporates a number security features and access control mechanisms that can be used for protecting systems and system resources.

PitBull has been frequently used as the basis for multilevel security (MLS) systems.

History

Product History

PitBull entered the market in 1987 as one of the five Compartmented Mode Workstations (CMW) contracted by the Defense Intelligence Agency.

The contract (MDA908-88-C-1183) was awarded to Harris Corporation of Melbourne, Florida, to develop a CMW for AT&T System V/386 Unix Release 3.2 on an Intel 80386 hardware platform. Harris called the product the Harris Compartmented Mode Workstation (HCMW).

Addamax Corporation of Champaign, Illinois, began assisting Harris with the development of the CMW in September 1989, and Harris transferred all rights to the software and contract in June 1990, at which point the product name was changed to the Addamax Compartmented Mode Workstation (ACMW).

In March of 1993 Addamax Corporation ceased active operations, and transferred most of its technology and product rights to the newly formed Argus Systems Group, Inc., of Champaign, Illinois, which continued the development of the ACMW (Argus Compartmented Mode Workstation) product. Argus upgraded the technology to SVR4 Unix running on Intel 80486 hardware and continued the ongoing security evaluation. In 2003, the assets of Argus Systems Group, Inc., were acquired by Innovative Security Systems, Inc., of Champaign, Illinois, who continued to do business as Argus Systems Group to present a more seamless transition to the marketplace.

Argus ported the ACMW technology to Sun Microsystem's Solaris 2.4 on SPARC and x86 hardware in 1994 and dropped support for the SVR4 ACMW product in 1995. Argus released versions of the product for Solaris 2.5, 2.6, 2.7, 2.8, and 10. The Solaris 2.8 version was renamed PitBull and the ACMW name was permanently dropped. After the acquisition of Sun by Oracle Corporation in 2010, Solaris source code and distribution licenses became prohibitive, and support for PitBull for Solaris was discontinued in 2012.

Argus ported the PitBull technology to IBM's AIX operating system in 2003. Most of the PitBull technology for AIX (excluding the multilevel windowing system and some multilevel networking technology) was sold to IBM in 2007, who renamed the product Trusted AIX.

Argus began a port of PitBull to Red Hat Enterprise Linux in 2010, and in 2011 Argus released PitBull for RHEL.

In 2011, General Dynamics C4 Systems acquired the assets of Innovative Security Systems, Inc., including all PitBull technology rights.^[2]

Evaluation/Certification History

The Harris HCMW and Addamax/Argus ACMW System V products were in evaluation under the oversight of the National Computer Security Center (NCSC) and DIA from 1988 through 1993.

The evaluation target was for the B1 security level under the Trusted Computer Security Evaluation Criteria (TCSEC or "Orange Book") with extensions for multilevel networking and multilevel windowing functionality required by the DIA Compartmented Mode Workstation Evaluation Criteria (CMWEC). The ACMW product reached the Initial Product Assessment Report (IPAR) level in the evaluation, but never received a final certification.

The PitBull for Solaris was evaluated in 1996 and 1999 in the United Kingdom under the ITSEC evaluation scheme at the E3/F-B1 and E3/F-C2 levels in both evaluations.^[3]

PitBull for AIX was evaluated in two separate Common Criteria evaluations in 2006 and 2007.

Although PitBull has not been independently accredited in the United States, it has been a key component for a number of Secret and Below Interoperability (SABI) and Top Secret/SCI and Below Interoperability (TSABI) accreditations.

Versions

Only the major releases are shown here. Some versions (such as 6.5.3) were prototypes or proof-of-concept and were never officially released.

ACMW 1.0

PitBull 2.0

PitBull 3.0

PitBull 4.0

PitBull 5.0

PitBull 6.0

PitBull 6.5

PitBull 6.8

Features

Privilege and Authorizations

PitBull replaces the concept of superuser/root on Linux with one based on privileges.

The PitBull operating system no longer gives any special capabilities or access rights to processes with a user ID of zero.

PitBull has a number of superuser emulation mechanisms so that individual processes can gain PitBull privileges by having a user ID of zero, but these are typically used only for testing and prototyping rather than in production systems.

There are over 100 separate PitBull privileges that can give a process to bypass specific kernel controls, such as DAC read access, DAC write access, the right to use restricted system calls, etc.

Processes can also temporarily or permanently disable privileges that they have been given, which allows software developers to write privilege bracketed programs that enable privileges only for system calls where they are needed.

Additionally, processes and process trees can be restricted from getting any specified set of privileges, which is used to prevent unauthorized privilege escalation.

Executable files can have a number of different privilege sets and PitBull security flags that indicate which privileges can be inherited or retained when the executable run.

Authorizations are attributes of a user account. An authorization can be used to restricted access to individual executable files or sets of executable files.

Authorizations are also used to allow different users to have different privilege sets when running the same executable files.

User accounts can be permanently blocked from getting access to authorizations even when the a user's process changes its user ID via a setuid file or the setuid system call.

Authorizations can be defined in a complex tree consisting of individual authorizations or groups of authorizations, and it is this capability that allows the creation of administrative roles for system management.

Access Control Mechanisms

PitBull incorporates six orthogonal file system access control mechanisms. All access control mechanisms are implemented using attributes stored in the object's inode.

The three general access control mechanisms (those applying to all file system accesses) are discretionary access control (DAC), mandatory access control (MAC), and mandatory integrity control (MIC). The PitBull DAC mechanism is the standard Linux permission bits and access control list (ACL). The PitBull MAC mechanism implements the Bell-LaPadula Model for mandatory access and can support up to 32,768 hierarchical classifications (such as SECRET or TOP SECRET) and 4,096 non-hierarchical compartments or categories. The PitBull MIC mechanism implements a form of the Biba Integrity Model, but is uses only a hierarchical structure within its MIC label rather than both a hierarchical and non-hierarchical component as specified by Biba.

The three targeted access control mechanism (those applying only to certain kinds of file system objects) are trusted computing base access control (TCB), authorizations (AZ), and audit (AUD). TCB is used to prevent a file system object from being modified, renamed, or deleted by any process, including all privileged processes. PitBull's AZ mechanism is used to implement roles and applies only to executable files. The PitBull AUD mechanism is used to protect audit files from access, renaming, or deletion by process that may have override capabilities for the other access control mechanism.

All PitBull access control mechanisms can be used simultaneously on any file system object. Because PitBull doesn't recognize any user ID as having innate privilege (i.e., root/superuser is not implemented on a PitBull system), only a process have the explicit privilege needed to override a specific form of access control can bypass an access control constraint.

Networking Security

PitBull modifies the RHEL network stack with enhanced functionality for the IP module. This enhancement, called Advanced Secure Networking (ASN), adds support for CIPSO and additional network rules to filter incoming and outgoing packets based on a number of criteria, including port numbers, network protocols, IP addresses and subnets, packet direction, and MAC label of the incoming or outgoing packet. PitBull supports CIPSO tag types 1, 2, and 5, as well as a proprietary implementation of tag type 7 that allows an essentially unlimited number of compartments/categories and an unlimited number of classifications.

PitBull's network enhancements also polyinstantiate ports, so that multiple processes can be listening simultaneously to the same port as long as they are listening for packets at different MAC labels or MAC label ranges.

PitBull supports standard [[Network_File_System|NFS] as either a client or server, but also includes a version of NFS called Trusted NFS that allows a server to export and a client to mount a PitBull file system with all PitBull attributes. A file system mounted with TNFS supports all PitBull attributes and functionality as if the file system were on a local drive. If a PitBull client mounts a file system using NFS, all files on the remote file system are treated as if they had the PitBull security attributes of the client's mount point.

Trusted X Window and MLS GUI

PitBull includes a complete MLS X window system, with security labels on windows, atoms, pixmap, font, and other X objects.

A number of GUI-based tools are available for users and administrators, including utilities to construct valid security labels, launch programs at user-specified security labels, and to allow upgrading and downgrading using copy-and-paste based on user authorizations.

PitBull supports both the Fluxbox and Metacity window managers as well as the GNOME desktop and Nautilus file manager.

Software Development on PitBull

PitBull retains the standard RHEL ABI, so applications that run on standard RHEL do not need to be recompiled to run on a PitBull system

PitBull also uses the standard RHEL API, so programs written for RHEL can be compiled on PitBull systems.

PitBull includes the library and header files needed to develop PitBull-aware programs.

PitBull has APIs for C, C++, and Python. There is also a PitBull Web API (WAPI) for writing browser-based MLS applications.

Use Scenarios

Historically, PitBull has been used in a variety of environments, both defense and commercial.

Comparison to SELinux

Both SELinux and PitBull are designed to extend the basic security functionality of Linux, and both do so by adding security functionality to the kernel.

SELinux does this assigning a type to all processes and system objects, and then defining the relationship and rights between types by a collection of rules, called the SELinux policy.

PitBull assigns a number of attributes to all processes and system objects, and the attributes themselves contain the information needed to determine the relationship and access rights of processes to system objects. PitBull does not have any rules or policy to define what the attributes mean or how they are interpreted.

SELinux can implement essentially any security policy needed through the appropriate SELinux policy, although trying to implement multiple, orthogonal security policies simultaneously requires that the SELinux policy describe the security relationships as if they were all part of a single, complex security policy.

PitBull's security policies are fixed, but the available security mechanisms are each entirely independent of the others and can be added and modified independently.

SELinux and PitBull can each "lock down" individual processes and both can be used to create a multilevel security (MLS) system based on the Bell-LaPadula model for mandatory access control, but SELinux is optimized for locking down processes and implementing non-standard policies, whereas PitBull is optimized for building traditional MLS systems and subsystems and for adding Biba-based mandatory integrity controls.

Because SELinux and PitBull use some of the same kernel mechanisms, they cannot be used together on the same system.