Copyright (c) 1997-1999 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Execution Profiles for Restricted Environments 1.2. Name of Document Author/Supplier: Glenn Faden 1.3. Date of This Document: 10/31/97 1.4. Name of Major Document Customer(s)/Consumer(s): Sun Federal Secure Software Engineering, PSARC Network Security Products Group 2. Project Summary 2.1. Project Description This project provides a configuration facility that allows administrators to define profiles consisting of specific sets of UNIX commands, CDE actions, and Authorizations. These profiles include the security attributes to be applied to each command and action. The capabilities of individual users can be defined in terms of these profiles in NIS+ tables or local files. This mechanism can be used to configure turnkey environments for novice users, or to break down the administration of the enterprise into specific areas of responsibility called roles. The CDE environment is modified so that only allowed actions are made available to users and administrative roles. A restricted shell is also provided which enforces these restrictions for UNIX commands. 2.2. Risks and Assumptions This design assumes a desktop that is based on CDE. There is more administrative overhead in setting up and assigning profiles to users. The design must accommodate customers working in restrictive environments as well as normal users. The prototype supports two process attributes (privileges and sensitivity labels) that are currently only available in Trusted Solaris. The design must make support for these attributes configurable. However, this proposal should be viewed as part of the plan to provide restrictions for the powers of the superuser. It should be extensible to support new functional attributes, as yet undefined. The current prototype does not support NIS (YP) for the new execution profile tables. The prototype is also based on the Solstice Admin Framework, and depends on the admin daemon. It is not clear how long these interfaces will be supported. 3. Business Summary 3.1. Problem Area Many customers want to distribute the administrative responsibility of Solaris among separate administrative roles. A mechanism is needed to specify functionally and explicitly the capabilities of each role. This mechanism must be configurable and must address both command line and GUI interfaces. In addition there is a need to provide turn-key environments, such as kiosks, in which the commands and actions available to the logged-in user are stictly limited. Both of these problem areas are addressed by this proposal. A building-block approach allows individual profiles to be constructed, and then sets of profiles to be assigned to users and/or roles. 3.2. Market/Requester This functionality is specified in a variety of commercial as well as government-related security specifications including: o the NIST MSFR (Minimum Security Functionality Requirements -- taken generally from BellCore specifications), o the X/Open XBSS (Baseline Security Services -- which consolidated the BellCore requirements, the I-4 Commercial International Security Requirements, the MSFR, the ECMA COFC for Security and others), o the Orange Book (DoD TCSEC), o the Common Criteria, and o the ITSEC. It is further required by sites that want to strengthen firewalls and other critical systems to reduce the powers of the root user. In addition, hospitals, financial organizations, and many businesses are already role-based and need a system that follows the same model. 3.3. Business Justification Most security threats are internal rather than external. The proposal addresses the risks associated with individual users or the superuser having too much power. The total opportunity, including hardware pull through, could be in the hundreds of millions of dollars. 3.4. Competitive Analysis A similar, though less powerful, feature is provided in Windows NT. Microsoft sales force uses it as a discriminator. No one else provides an approach with such fine granularity. Other trusted systems, like HP's Trusted OS, are not as configurable in the number of roles supported or in the ability to customize the roles. 3.5. Opportunity Window/Exposure There is an immediate need to address role-based administration as part of our firewall strategy. The release of Trusted Solaris 2.5 (August 97) has created demand for these features to be rolled back into Solaris. 4. Technical Description A prototype of the implementation is currently shipping in Trusted Solaris 2.5. A new NIS+ table, tsolprof.org_dir, contains the profile definitions. Another new NIS+ table, tsoluser.org_dir, is used to associate profile names with users and roles. New GUIs are added to the Solstice Admin Suite for managing these new databases. Local file versions are also supported. The restrictions to CDE actions is implemented by modifying the loading of the action cache, dtdbcache, to exclude actions that are not defined in the user or roles profile. In addition, the window manager, dtwm, is modified to make it a trusted process which prevents users from bypassing the profile restrictions. The command restrictions are currently implemented using a modified version of the Bourne shell. Roles and restricted users must use this shell for command-line sessions. An enhanced design, based on the intercepting the exec system call, is not yet prototyped. The authorizations database is also maintained in the profiles table. Trusted applications check the authorizations of the user to determine whether privileged execution should be allowed. 5. Reference Documents The following Trusted Solaris design specs describe execution profiles design and implementation: Defining Administrative and User Profiles (SunTech'95) (A high-level overview of the concepts and the sample implementation) http://odgers.ebay/shark/doc/ts2_301.dir/profiles.doc Profiles and DT Services (Describes the implementation of the CDE Actions aspects of Profiles, and the Profile Manager) http://odgers.ebay/shark/doc/ts2_408.dir/ProfileBOOK.ps Admintools (Describes the GUIs which allow profiles to be associated with users and roles) http://odgers.ebay/shark/doc/ts2_404.dir/ext.ps Profile Shell, System Shell, and Admin Text Editor (Describes the implementation of the commands aspects of Profiles) http://odgers.ebay/shark/doc/ts2_426.dir/ts_prshBOOK.ps In addition a response was submitted to the Network Security Products group's Root Control RFP. The RFP and our responses are available on request. Trusted Solaris Adminstration Overview (end user documentation about execution profiles) http://answers.eng:8888 6. Resources and Schedule 6.1. Projected Availability Solaris 2.7 or 2.8? 6.2. Cost of Effort 4 person years. 6.3. Cost of Capital Resources 8 machines. 7. Prototype Availability 7.1. Prototype Availability The prototype is available now. The Sun part number is TS-25-S. 7.2. Prototype Cost The prototype was fully funded by Sun Fed and included in the development cost of Trusted Solaris 2.5.