test

Trusted Solaris Administration Overview

Chapter 1 Introduction to Administration

This chapter introduces you to system administration in the Trusted Solaris environment. It begins with a quick review of Trusted Solaris concepts from the Trusted Solaris User's Guide and goes on to explain some advanced concepts necessary for Trusted Solaris administrators.

Basic Concepts Review

The Trusted Solaris environment is an enhanced version of Solaris that incorporates configurable security policy into the system. The concepts in this section are basic to understanding the Trusted Solaris environment, both for users and administrators. They are briefly covered here and are discussed in more depth in the Trusted Solaris User's Guide.

How the Trusted Solaris Environment Protects Against Intruders

Trusted Solaris protects access to the system by providing accounts requiring user names with passwords. Passwords can be created by users or system-generated, according to your site's security policy. You can also require that passwords be changed regularly. In addition, users can work within their approved label range only limiting the information they can access. Additional passwords are required for certain administrative tasks; this limits the damage that can be done by an intruder who guesses the root password.

The Trusted Solaris environment displays the Trusted Path symbol, an unmistakable, tamper-proof emblem that appears at the bottom of the screen, indicating to users when they are using security-related parts of the system. If the Trusted Path symbol does not appear when the user is running a trusted application, that version of the application should be checked immediately for authenticity.

As administrator, you should always verify personally with your users instructions you send them via email. The purpose of this policy is to avoid such situations as imposters posing as administrators and sending email to users to try to get passwords to accounts or other sensitive information.

How the Trusted Solaris Environment Enforces Access Control Policy

The Trusted Solaris environment protects information and other resources through discretionary access control--the traditional UNIX permission bits and access control lists set at the discretion of the owner--and mandatory access control--a mechanism enforced by the system automatically that controls all transactions by checking the labels of processes and data in the transaction.

A user's label represents the sensitivity level at which the user is permitted to and chooses to operate. It determines which information the user is allowed to access. Both mandatory and discretionary access controls can be overridden by special permissions called privileges, which are granted to processes. In some cases, users may need authorizations as well, which are granted to users (and roles) by an administrator.

As administrator, you need to train users on the proper procedures for securing their files and directories, according to your site's security policy. Furthermore, you should instruct any users allowed to upgrade or downgrade labels as to when it is appropriate to change a label.

How the Trusted Solaris Environment Implements Administration

In conventional UNIX systems, superuser (root) is all-powerful with the ability to read and write to any file, run all programs, and send kill signals to any process. In the Trusted Solaris environment, root's capabilities are divided into separate role accounts that can be assigned to different individuals.

Roles are used mainly for security-related tasks. They require separate authentication, are assigned to sysadmin group 14, are privileged NIS+ principals, and operate in special workspaces that can supply the trusted path attribute to those processes requiring them; many administrative applications require all four conditions to run successfully.

Understanding Trusted Software Administration

The following sections describe trusted software administration:

Overview of Trusted Software Administration

As mentioned earlier in this chapter, the superuser's capabilities are divided into separate role accounts rather than being concentrated in the superuser account only. This separation is accomplished through two override mechanisms in the Trusted Solaris environment: authorizations, which are rights associated with users, and privileges, which are rights associated with processes. An application that can override system controls is called a trusted application. Trusted applications have either been designed to check for authorizations or have been assigned special security attributes (that is, effective and real user IDs (UIDs) and group IDs (GIDs), process labels, clearances, and privileges). Instead of becoming superuser, users or roles can run their assigned trusted applications with the same capabilities that the superuser would have running these applications.

Trusted applications and authorizations are grouped in rights profiles or profiles, for short, which can be assigned to users or more commonly to roles. Users access trusted CDE actions granted to them through the Front Panel, the Application Manager, the Workspace menu, and the File Manager. Users access trusted commands granted to them through special shells called profile shells. The profile shell is a Bourne, Korn, or C shell that has been modified to grant roles (and users) access to those programs assigned to their rights profiles and to make security attributes available to commands. From a profile shell, a user can execute those commands and only those commands assigned to that user's profiles. Note that a profile can be used to enable users, that is, give them access to commands, privileges, and authorizations not available to normal users; or to restrict users, that is, to limit them to a specific set of commands (this might be appropriate for unsophisticated users).

In practice, here is how access control is enforced and can be overridden by an administrator or authorized user. When a user attempts to access a file, the mandatory access controls (MAC) are checked. The process label of the program the user is running must dominate the label on the file; if this is not the case, then the user's process needs MAC privileges, such as file_mac_search to access the directory and file_mac_read to read the file. There are also discretionary access controls, that is, UNIX permissions, to be checked. If the user does not have read permission, then privileges such as file_dac_search and file_dac_read are needed. If the file's ownership were to be changed through the File Manager, then the user would need the authorization solaris.file.chown.

The following figure summarizes the elements used in Trusted Solaris administration. The arrows in the figure indicate the direction of an assignment. In short, roles are special accounts that can be assigned to users. Rights profiles are packages of permitted operations that are assigned commonly to roles and occasionally to users. Authorizations, CDE actions, and commands are assigned to rights profiles. Privileges are assigned to sets. The allowed and forced privilege sets can be assigned to executable files. CDE action and command processes can have the following security attributes applied: privileges in the inheritable privilege set; effective and real UIDs/GIDs; and clearances and security labels.

These elements and their relations are discussed in the following sections.

Figure 1-1 Security Element Assignment in the Trusted Solaris Environment

Graphic

Note -

The Solaris environment also provides roles, authorizations, rights profiles, and profile shells (also referred to as "administrator shells"). The only security attributes that trusted applications in the Solaris environment can make use of are real and effective UIDs/GIDs. There are no labels, clearances, or privileges in the Solaris environment.

Understanding Roles

A role is a special user account that gives a user access to specific programs and the authorizations and privileges necessary for running them. All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users cannot log in directly to a role; they must log into their user account prior to assuming a role to ensure that the user's real UID is recorded for auditing. (Another restriction that supports auditing is that a user cannot assume any other role directly from a role.) Assuming a role requires users to authenticate themselves by providing the role password. The user is then granted access to a dedicated role workspace where the user has access to trusted applications, the profile shell, and the trusted path attribute.

The Trusted Solaris environment provides one preconfigured role (Root) and four recommended roles as shown in the table below. If your site plans to use these roles, you need to configure them according to the instructions in the "How to Create Administrative Roles" in Trusted Solaris Installation and Configuration.

Table 1-1 Roles and their Responsibilities

Role (Login Name) 

Responsibilities 

Root (root) 

Initial installation and configuration of the operating environment. After configuration, the root role is not used for administration and should not be assigned to any user. 

System administrator (admin)  

Performs standard UNIX system administration tasks. Adds new users; configures user templates; modifies certain user properties; configures hosts, networks, routes, and printers. Can also make and restore backups and administer printing.  

Security administrator (secadmin) 

Responsible for security tasks and decisions. Administers labels; modifies security-relevant attributes of users, networks, printers and other devices and hosts. Configures host templates. Can modify default roles and profiles and add new roles, but cannot grant capabilities beyond those of the security administrator role itself.

Primary administrator (primaryadmin) 

Not used in normal system operations, the primary administrator role is designed to be used only when the security administrator role cannot accomplish a task, for example, adding a new role or profile with capabilities the security administrator does not have. 

System operator (oper) 

Makes backups and administers printing.  

The Trusted Solaris environment is highly configurable so that you can implement a customized set of roles and rights profiles. (Note that this type of customization would be done by the primary administrator role.) If your site does reconfigure roles, make sure all users know who is performing each set of duties.

Your site may need new roles in addition to the predefined administrative roles. The main reason for creating a role is to define an explicit job responsibility that can use special commands and actions and any necessary privileges, that needs to be isolated from normal users, and that uses a shared home directory, files, and environment. (If you need to isolate commands and privileges with separate home directories and files for different users, then you should create a special rights profile instead of a role. See next section.)

Understanding Rights Profiles

Trusted applications and authorizations can be grouped into packages called rights profiles for assignment to user or role accounts. The main purpose of a rights profile is to provide limited override power to a user or role who needs this capability.

The potential contents of a rights profile are:

Assigning Rights Profiles to Users or Roles

To assign rights profiles to users, you open the User Properties dialog box from the User Tool in the Solaris Management Console and select the Rights tab, as shown in the following figure. The rights profiles not assigned to the current user or role are displayed in the Excluded column on the left and must be moved to the right column for assignment to the current account. For more information, see the online help. In similar fashion, you can make changes to roles through the Administrative Roles dialog box in the User Tool.

Figure 1-2 Assigning Rights Profiles to Users

Graphic

Predefined Trusted Solaris Rights Profiles

The Trusted Solaris environment provides a set of predefined rights profiles (see the following table). Before you assign any of these rights profiles, you should familiarize yourself with their contents. To view the contents of predefined rights profiles, use the -list option in the smprofile command (see next section) or the Rights dialog box. The profiles can be modified according to the needs of your organization.

Table 1-2 Rights Profile Descriptions

Rights Profile 

Purpose 

All

Provides access to all executables but without privileges.  

All Actions 

Provides access to all actions but without privileges.  

All Authorizations

Provides all authorizations. For testing. 

All Commands 

Provides access to all commands but without privileges.  

Audit Control

For managing the audit subsystem but without ability to read files. 

Audit Review

For reading the audit trail. 

Basic Actions

Provides access to the applications on the Front Panel with the necessary privileges. 

Basic Commands

Provides access to rudimentary commands necessary for all roles. 

Basic Solaris User 

Assigned to all users of the Solaris Management Console. Provides Read permissions and lets users add con jobs to their crontab files. Contains All rights profile. 

Convenient Authorizations

Provides authorizations for normal users. 

Cron Management

For managing cron and at jobs. 

Custom Admin Role

This is an empty right for adding security attributes to the default Admin role. 

Custom Oper Role

This is an empty right for adding security attributes to the default Oper role. 

Custom Root Role

This is an empty right for adding security attributes to the default Root role. 

Custom Secadmin Role

This is an empty right for adding security attributes to the default Secadmin role. 

Custom SSP 

This is an empty right for adding security attributes to the default SSP role for Sun Enterprose 10000 administration. 

Device Management 

For allocating and deallocating devices, and correcting error conditions. 

Device Security

For managing and configuring devices. 

Enable Login

Provides the authorization for allowing yourself and other users to log in after boot. 

File System Management

For managing file systems. 

File System Security

For managing file system labels and other security attributes. 

Information Security 

For setting access control policy. 

Mail Management

For configuring sendmail, modifying aliases, and checking mail queues. 

Maintenance and Repair

Provides commands needed to maintain or repair a system. 

Media Backup

Backup files. 

Media Restore

Restore files from backup. 

Name Service Management 

Grants right to control the name service daemon. 

Name Service Security 

Grants right to control the name service properties and table data. 

Network Management

For managing the host and network configuration. 

Network Security 

For managing network and host security, with authorizations for modifying trusted network databases. 

Object Access Management

For changing ownership and permissions on files. 

Object Label Management

For changing labels of files and setting up system-wide labels. 

Object Privilege Management

For changing privileges on executable files. 

Outside Accred

Operate outside system accreditation range. 

Primary Adminstrator 

Contains subordinate rights profiles for primary administrator role. 

Privileged Shells

For developers to run Bourne, Korn, and C shells with all privileges. NOT intended for secure environments. 

Process Management

For managing current processes, including cron and at jobs. 
 Remote Administration Remote administration of headless systems.

Rights Delegation 

Lets user or role assign rights assigned to that user or role to other users or roles. Lets user assign roles assigned to that user to other users. 

Rights Security 

For managing assignment of rights profiles, labels, and privileges, and for setting account security. 

Software Installation 

For adding application software to the system. 
 SSP Administration Tools for administering the SSP.
 SSP Installation Tools for installing the SSP.

System Administrator 

Contains subordinate rights profiles for system administrator role. 

User Management

For creating and modifying users but without the ability to modify self (as a security measure). 

User Security

For creating and modifying users' security attributes but without the ability to modify self (as a security measure). 

Displaying Rights Profile Information

Use the -list option in the smprofile command to obtain various rights profile information. This command lets you display the contents of any profile for all users or specified user(s) and optionally the contents of the profiles. Another option for displaying rights profile information is profiles(1).

Customizing Rights Profiles

If the predefined rights profiles as they are shipped are not appropriate for your organization, they can be modified by the security administrator (or other role with equivalent powers). The Rights dialog box is used to edit the contents of rights profiles (see figure below). The Rights dialog box is accessed from the User Tool in the Solaris Management Console. For more information, see the online help.

Figure 1-3 Rights Dialog Box

Graphic

Understanding Authorizations

An authorization is a discrete right granted to a user or role that is checked by certain trusted applications to determine whether the user is permitted to execute a restricted function. For example, in a conventional system, the file manager allows superuser only to change the ownership of a file. In the Trusted Solaris operating environment, the authorization Change File Owner is required.

An authorization has a name, which is used internally and in files (for example, solaris.file.owner) , and a short description, which appears in the graphical interfaces (for example, Act as File Owner). By convention, authorization names begin with the reverse order of the internet name followed by the subject area, any subarea, and the function, all separated by dots, for example, com.xyzcorp.device.access. The exceptions to this convention are authorizations from Sun Microsystems, Inc., which use the prefix solaris. instead of an internet name. This convention enables administrators to apply authorizations in a hierarchical fashion using a wildcard (*) to represent any strings to the right of a dot.

The authorizations provided in the Trusted Solaris environment are shown in the following table.

Table 1-3 Authorizations

Authorization Category 

Authorization Name -- Short Description 

solaris.admin.dcmgr.* 

solaris.admin.dcmgr.admin--Manage OS Services and Patches  

solaris.admin.dcmgr.clients--Manage Diskless Clients  

solaris.admin.dcmgr.read--View OS Services, Patches and Diskless Clients 

solaris.admin.diskmgr.*

solaris.admin.diskmgr.read--View Disks 

solaris.admin.diskmgr.write--Manage disks 

solaris.admin.fsmgr.* 

solaris.admin.fsmgr.write--Mount and Share Files  

solaris.admin.fsmgr.read--View Mounts and Shares 

solaris.admin.logsvc.* 

solaris.admin.logsvc.write--Manage Log Settings 

solaris.admin.logsvc.purge--Remove Log Files 

solaris.admin.logsvc.read - View Log Files 

solaris.admin.nameservice.* 

solaris.admin.nameservice.config--Name Service Configuration 

solaris.admin.printer.* 

solaris.admin.printer.read--View Printer Information  

solaris.admin.printer.modify--Update Printer Information  

solaris.admin.printer.delete--Delete Printer Information 

solaris.admin.procmgr.* 

solaris.admin.procmgr.admin--Manage All Processes  

solaris.admin.procmgr.user--Manage Owned Processes 

solaris.admin.serialmgr.* 

solaris.admin.serialmgr.modify--Manage Serial Ports 

solaris.admin.serialmgr.delete--Delete Serial Ports  

solaris.admin.serialmgr.read--View Serial Ports 

solaris.admin.usermgr.* 

solaris.admin.usermgr.audit--Set User Audit Info 

solaris.admin.usermgr.write--Manage Users  

solaris.admin.usermgr.psword--Change Password 

solaris.admin.usermgr.read--View Users and Roles 

solaris.admin.usermgr.labels--Set User Label Info 

solaris.audit.* 

solaris.audit.config--Configure Auditing 

solaris.audit.read--Read Audit Trail 

solaris.compsys.* 

solaris.compsys.read--View Computer System Information  

solaris.compsys.write--Manage Computer System Information 

solaris.device.* 

solaris.device.allocate--Allocate Device 

solaris.device.config--Configure Device Attributes 

solaris.device.grant--Delegate Device Administration 

solaris.device.revoke--Revoke or Reclaim Device  

solaris.file.* 

solaris.file.audit--Set File Audit Attributes 

solaris.file.chown--Change File Owner  

solaris.file.privs--Set File Privilege  

solaris.file.owner--Act as File Owner 

solaris.grant 

solaris.grant--Grant All Solaris Authorizations 

solaris.jobs.* 

solaris.jobs.admin--Manage All Jobs 

solaris.jobs.grant--Delegate Cron & At Administration  

solaris.jobs.user--Manage Owned Jobs  

solaris.label.* 

solaris.label.print--View Printer Queue at All Labels 

solaris.label.file.downgrade--Downgrade File Label  

solaris.label.file.upgrade--Upgrade File Label 

solaris.label.range--Set Label Outside User Accred Range  

solaris.label.win.downgrade--Downgrade DragNDrop or CutPaste Info  

solaris.label.win.noview--DragNDrop or CutPaste without viewing contents 

solaris.label.win.upgrade--Upgrade DragNDrop or CutPaste Info  

solaris.login.* 

solaris.login.enable--Enable Logins 

solaris.login.remote--Remote Login 

solaris.login.su--Switch User Without Trusted Path 

solaris.network.* 

solaris.network.hosts.read--View Computers and Networks 

solaris.network.hosts.write--Manage Computers and Networks 

solaris.network.security.write--Manage Trusted Networking  

solaris.network.security.read--View Trusted Networking 

solaris.print.* 

solaris.print.admin--Administer Printer 

solaris.print.list--List Jobs in Printer Queue  

solaris.print.cancel--Cancel Print Job  

solaris.print.nobanner--Print without Banner  

solaris.print.ps--Print Postscript  

solaris.print.unlabeled--Print without Label  

solaris.profmgr.* 

solaris.profmgr.assign--Assign All Rights 

solaris.profmgr.delegate--Assign Owned Rights 

solaris.profmgr.execattr.write--Manage Commands 

solaris.profmgr.read--View Rights 

solaris.profmgr.write--Manage Rights 

solaris.role.* 

solaris.role.assign--Assign All Roles  

solaris.role.delegate--Assign Owned Roles 

solaris.role.write--Manage Roles 

solaris.system.* 

solaris.system.date--Set Date & Time  

solaris.system.shutdown--Shutdown the System 

For a complete list of authorizations, see the /etc/security/auth_attr file. Authorizations are assigned to rights profiles using the Rights dialog box in the SMC User Manager.

Understanding Privileges

A privilege is a discrete right granted to a process to perform an operation that would otherwise be prohibited by the Trusted Solaris environment. For example, processes cannot normally open data files unless they have the proper file permission. In the Trusted Solaris environment, the file_dac_read privilege gives a process the ability to override the UNIX file permissions for reading a file.

How a Process Acquires Privileges

The Trusted Solaris environment determines which privileges a process can make effective based on the allowed and forced privilege sets assigned to the executable file and the inheritable privileges inherited by the process.

The allowed privilege attribute satisfies one condition necessary for that privilege to be effective. If an allowed privilege for an application is not set, the privilege cannot be effective under any condition. The forced privilege attribute makes the privilege effective to all users running that application. Both types of attributes are assigned using either the File Manager or the setfpriv(1) command. The commandgetfpriv(1) lets you see which privileges are set on the executable file. Note that if an executable file is modified, all allowed and forced privileges are removed.

The inheritable privilege attribute is assigned to the application within a rights profile. Only users who have been assigned that rights profile are granted the privilege for that application. Inheritable privilege attributes are assigned to an application inside a rights profile using either the Rights Manager or the -add option in the smexec command. An inheritable privilege is made effective when the process is launched by one of the trusted launchers. For the terminal environment, the Trusted Solaris environment provides three profile shells corresponding to the Bourne, Korn and C shells; for the desktop, the Workspace Menu, the Front Panel, and the Application Manager interpret profiles for actions; and for remote environments the Solaris Management Console legacy application tool interprets profiles. A process can also pass inheritable privileges to any program it executes, provided that the particular privilege is allowed by the program.

Note -

In contrast to inheritable privileges, forced privileges cannot be inherited by child processes except in applications that have been customized especially for the Trusted Solaris environment to have that specific capability. To provide privileges to a shell script, one should thus use inheritable privileges, not forced privileges.

Default Privileges Supplied by the Trusted Solaris Environment

The Trusted Solaris environment provides more than 80 privileges that you can apply to applications to override security policy. For a complete list of privileges, see the priv_desc(4) man page. The privileges provided fall into the categories shown in the following table.

Table 1-4 Privilege Categories

Privilege Category 

Summary 

Example Privileges in the Category 

File system security

For overriding file system restrictions on user and group IDs, access permissions, labeling, ownership, and file privilege sets 

file_dac_chown - lets a process change the owner user ID of a file.

System V Interprocess Communication (IPC) security

For overriding restrictions on message queues, semaphore sets, or shared memory regions  

ipc_dac_read - lets a process read a System V IPC message queue, semaphore set, or shared memory region whose permission bits or ACL do not allow process read permission

Network security

For overriding restrictions on reserved port binding or binding to a multilevel port, sending broadcast messages, or specifying security attributes (such as labels, privileges on a message, or network endpoint defaults)  

net_broadcast - lets a process send a broadcast packet on a specified network

Process security

For overriding restrictions on auditing, labeling, covert channel delays, ownership, clearance, user IDs, or group IDs 

proc_mac_read - lets a process read another process where the reading process label is dominated by the other process label

System security

For overriding restrictions on auditing, workstation booting, workstation configuration management, console output redirection, device management, file systems, creating hard links to directories, increasing message queue size, increasing the number of processes, workstation network configuration, third-party loadable modules, or label translation  

sys_boot - lets a process halt or reboot a Trusted Solaris workstation

Window security

For overriding restrictions on colormaps, reading to and writing from windows, input devices, labeling, font paths, moving data between windows, X server resource management, or direct graphics access (DGA) X protocol extensions 

win_selection - allows a process to request inter-window data moves without the intervention of selection arbitrator

Understanding Labels

Labels and clearances are the heart of mandatory access control in the Trusted Solaris environment. They determine which users can access which files and directories. Labels and clearances consist of one classification component and zero or more compartment components. The classification component indicates a hierarchical level of security such as TOP SECRET or CONFIDENTIAL. The compartment component represents a group of users who may need access to a common body of information. Some typical types of compartments are projects, departments, or physical locations.

The Trusted Solaris environment mediates all attempted security-related transactions. It compares the labels of the accessing entity, typically a process, and the entity being accessed, usually a file, and then permits or disallows the transaction depending on which label is dominant (as described in the following section). Labels are also used to determine access to other system resources, such as allocatable devices, networks, framebuffers, and other hosts.

Note -

CMW labels are primarily of importance to programmers. They are composed of regular labels (also called sensitivity labels) and an obsolete label type called an information label. Although they are present in CMW labels (for backwards compatibility), information labels are no longer used by the system.

Dominance Relationships Between Labels

One entity's label is said to dominate another's if the following two conditions are met:

Two labels are said to be equal if they have the same classification and the same set of compartments. If they are equal, they dominate each other and access is permitted.

If one label has a higher classification or if it has the same classification and its compartments are a superset of the second label's compartments or both, the first label is said to strictly dominate the second label.

Two labels are said to be disjoint or noncomparable if neither label dominates the other.

The following table presents examples of label comparisons for dominance. In the example, NEED_TO_KNOW is a higher classification than INTERNAL. There are three compartments: Eng, Mkt, and Fin.

Table 1-5 Examples of Label Relationships

Label 1 

Relationship 

Label 2 

NEED_TO_KNOW Eng Mkt 

(strictly) dominates 

INTERNAL Eng Mkt 

NEED_TO_KNOW Eng Mkt  

(strictly) dominates 

NEED_TO_KNOW Eng  

NEED_TO_KNOW Eng Mkt  

(strictly) dominates 

INTERNAL Eng 

NEED_TO_KNOW Eng Mkt  

dominates (equals) 

NEED_TO_KNOW Eng Mkt 

NEED_TO_KNOW Eng Mk  

is disjoint with 

NEED_TO_KNOW Eng Fin 

NEED_TO_KNOW Eng Mkt  

is disjoint with 

NEED_TO_KNOW Fin 

NEED_TO_KNOW Eng Mkt  

is disjoint with 

INTERNAL Eng Mkt Fin 

Administrative Labels

The Trusted Solaris environment provides two special labels for administration to be used as labels or clearances: ADMIN_HIGH and ADMIN_LOW. (You can rename these two labels in the label_encodings(4) file if you choose.) These labels are used to protect system resources and are intended for administrators rather than normal users.

ADMIN_HIGH is the highest label; it dominates all other labels in the system and is used to protect system data, such as administration databases or audit trails, from being read. You need to work at the ADMIN_HIGH label (typically in a role) or have the privilege to read up from your current label to read data labeled ADMIN_HIGH.

ADMIN_LOW is the lowest label; it is dominated by all other labels in a system. Mandatory access control does not permit users to write data to files with labels lower than the subject's label. Thus, applying ADMIN_LOW, the lowest label, to a file ensures that normal users cannot write to it although they can read it. ADMIN_LOW is typically used to protect public executables and configuration files to prevent them from being modified, since only a user working at ADMIN_LOW or with the privilege to write down would be able to write to these files. Typically, only an administrator would work at ADMIN_LOW.

Label Encodings Files

All label components for a system, that is, classifications, compartments, and the associated rules are stored in a file called label_encodings(4) (located in /etc/security/tsol). The security administrator sets up the label_encodings file for the site. A label encodings file contains:

For more information on the label_encodings file, see the man page for label_encodings(4) and the manuals, Trusted Solaris Label Administration and Compartmented Mode Workstation Labeling: Encodings Format.

Label Ranges

A label range is the set of potentially usable labels at which users can operate. Resources that can be protected by label ranges include such things as allocatable devices, file systems, networks, interfaces, frame buffers (effectively workstations), and commands or actions. A label range is defined by a clearance at the top of the range and a minimum label at the bottom. A range is not necessarily all combinations of labels that fall between a maximum and minimum label. There may be rules in the label encodings file that disqualify certain combinations. A label must be well-formed, that is, permitted by all applicable rules in the label encodings file, in order to be included in a range. On the other hand, a clearance does not have to be well-formed. Suppose, for example, that a label encodings file prohibits any combination of compartments Eng, Mkt, and Fin in a label. INTERNAL Eng Mkt Fin would be a valid clearance but not a valid label; as a clearance, it would let a user access files labeled INTERNAL Eng, INTERNAL Mkt, and INTERNAL Fin.

Account Label Range

When you assign a clearance and a minimum label to a user, you define the upper and lower boundaries of the account label range in which that user is permitted to operate. The following equation describes the account label range, using <= to indicate dominated by or the same as:

minimum label <= permitted label <= clearance

Thus, the user is permitted to operate at any label that is dominated by the clearance as long as that label is not strictly dominated by the minimum label. If you do not expressly set a user's clearance or minimum label, the defaults defined in the label encodings file will take effect. Make sure when you assign a clearance that the classification dominates (or is the same as) all classifications at which the user can work and that the list of compartments include all compartments that user might need. Combinations of compartments in the clearance will be governed by rules in the label_encodings file.

To assign single-label operation to a user, you set the user's clearance equal to the minimum label.

Session Range

The session range is the set of labels available to a user during a Trusted Solaris session. The session range must be within the user's account label range and the label range set for the system. If the user selects single-label session mode, the session range will be limited to that label. If the user selects multilabel mode, then the label entered will serve as the session clearance, defining the upper boundary of the session range while the user's minimum label defines the lower bound. The user enters the session at the minimum label and can switch to a workspace at any label in the session range.

How Labeled Files are Stored

In the Trusted Solaris environment, labels are automatically associated with all files and directories, and are stored as extended attributes of the file. These attributes are protected by privilege and mandatory controls.

In addition, special directories called multilevel directories (MLDs) allow files to be isolated by label in subdirectories called single-level directories (SLDs). SLDs are transparent to users and applications.

The purpose of MLDs is to enable applications that are running at different labels to write into what appears to be the same directory. For example, the /tmp directory is often used by multiple applications; for that reason, /tmp is an MLD. Applications are not aware that when they write a file into /tmp they are actually writing the file into the SLD within /tmp that has the label at which the application is running. If a single-level directory corresponding to the label does not yet exist, the Trusted Solaris environment creates one automatically.

New MLDs are built by creating a new folder with the File Manager using the MLD option or at the command line using the --M option of the mkdir(1). The crontab(1) and at-job directories are shipped as MLDs so that you can set up batch jobs for a user that run at different labels. See the "Administering the Automatic Running of Jobs Using cron, at, and batch" in Trusted Solaris Administrator's Procedures.

Home directories are MLDs so that accounts can create files and folders at different labels within their home directories. When user or role accounts change into their home directories, they do not need to be aware that they have actually changed into an SLD that is at the same label as their current workspace. For example, when setting up a new account for user roseanne, the User Tool creates the home directory /export/home/roseanne as an MLD. When the user roseanne changes to her home directory, she is automatically and transparently redirected to an SLD within her home directory MLD. The SLD has the same label as her current workspace, so if the workspace has a label of NEED_TO_KNOW, she changes into the SLD that has the NEED_TO_KNOW label.

To allow normal users to create their own MLDs, the administrator role must first create a new directory that is not an MLD and make it writable by normal users. For example, an administrator could create a directory called /myDir/doc mounted by and writable by all developers at a single label, so that design specifications and other project-wide documentation could be kept in one commonly accessible place. Anyone in the development group could then create a new directory within that directory and make it an MLD. If desired, the prefix can be changed from MLD using the mount(1M) command.

Multilevel directory names contain a hidden string, .MLD. (referred to as an adornment), which is appended to the beginning of the directory name but is not visible to standard UNIX commands.

Single-level directories are named .SLD.n where the number n represents the order in which the SLDs in the multilevel directory are created. Thus, the single-level directories are named .SLD.0, SLD.1, and so on. The implementation is transparent so that directory names with adornments are not displayed except through the special commands in the table below. A user with appropriate privileges can view the contents of a hidden directory outside of the current SL by explicitly specifying the adornments to the path.

Table 1-6 Adornment--Related Commands

Command Name  

Description 

adornfc(1)

The adornfc(1) command displays the specified directory pathname with the final component adorned, that is, the strings .MLD. or .SLD. used to identify whether the directory is multilevel or single-level.

getfattrflag(1)

The -m option indicates whether or not the directory is an MLD.

getmldadorn(1)

The getmldadorn(1) command displays the MLD adornment of the filesystem on which the specified pathname resides.

getsldname(1)

The getsldname(1) command displays the single-level directory name associated with the label of the current process within the multilevel directory referred to by pathname.

mkdir(1)

When used with -M option or when the directory name has the .MLD. adornment, creates a new MLD.

mldpwd(1)

The mldpwd(1) command displays the pathname of the current working directory, including any MLD adornments and SLD names.

mldrealpath(1)

The mldrealpath(1) command displays the canonicalized absolute pathname, including any MLD adornments and SLD names. It expands all symbolic links and resolves references to special characters (/. and /..) and translations in pathnames. The resulting path has no special characters, unadorned multilevel directories, or any hidden SLD names.

rm(1), rmdir(1)

The -M option when used with the -R option removes SLD subdirectories recursively.

The following figure illustrates the normal view of an SLD, depicting directories as ovals, files as rectangles, visible items with solid lines and bolding, and hidden items with dashed lines and normal font. In this case, the user is operating with a NEED_TO_KNOW Eng Mkt label and executes the ls command as shown on the left side of the figure. The user can view files with the Top Secret label only. The actual structure and contents of myHomeDir, which is a multilevel directory, is shown at the right of the figure.

Figure 1-4 Normal Viewing of a Directory

Graphic

The following figure demonstrates how a user can view directory contents outside of the current SL. By typing ls /.MLD.myHomeDir/.SLD.*, the user sees all hidden directories in the multilevel directory, in this case, .SLD.0 which contains files with an SL of INTERNAL Eng and .SLD.1 which holds a TOP SECRET file.

Figure 1-5 Viewing the Contents of Multiple SLDs

Graphic

Applying Labels to Email

All email messages have labels in the Trusted Solaris environment. The underlying tool sendmail(1M) does not deliver mail to a user outside of the user's account range; use the -p option in the sendmail.cf file to provide for out-of-range mail. Furthermore, the restrictmailq option in the sendmail.cf file is set by default to restrict users from listing mail sent by other users; only users in the same group as the mail queue can list jobs in the queue. Email operations make use of multilabel directories both for messages queued prior to delivery and for storage of incoming messages. Users are notified separately about mail received at each label in their account range and in the range of any role they have assumed. In addition, an option exists to promote email from administrators from ADMIN_LOW to the user's minimum label.

Applying Labels to Printed Output

You can arrange for labels, handling information, and other security information to be printed out in the banner and trailer pages on a printer by printer basis. The following figure shows a typical banner page. For more information on configuring printing in the Trusted Solaris environment, see "Managing Printing" in Trusted Solaris Administrator's Procedures and "Configuring How Labels are Printed on Banner/Trailer and Body Pages" in Trusted Solaris Label Administration.

Figure 1-6 Typical Print Banner Page

Graphic

How the Trusted Solaris Environment Controls Device Access

Since devices provide a means for the import and export of data to and from a Trusted Solaris system, they must be controlled to properly protect the data. (A device is either a physical peripheral that is connected to a Trusted Solaris system or a software-simulated device called a pseudo-device.) The Trusted Solaris environment lets you control data flowing through devices through device allocation and device label ranges.

Device Allocation

Device allocation provides a way to control data when it is imported and exported and prevents unauthorized users from access to the information. In a Trusted Solaris system the administrator decides which devices, if any, each user can use to import and export data and sets those devices to be allocatable. The administrator then assigns to selected users the Allocate Device authorization . The Configure Device Attributes, Delegate Device Administration, and Revoke or Claim Device authorizations are used to adminstrate devices. Users authorized to use a device must allocate the device before using it and deallocate the device when finished. Between the allocation and deallocation of a device, the user has exclusive use of it.

The device allocation applications are provided by the Solaris SunSHIELD Basic Security Module (BSM); refer to Chapter 4, "Device Allocation," in the SunSHIELD Basic Security Module Guide. The Trusted Solaris environment provides a graphical user interface on top of these commands called the Device Allocation Manager that enables device label ranges.

Device allocation provides a way to control the import and export of data. In the Trusted Solaris environment, the administrator decides which devices, if any, can be used to import and export data and includes the devices in the device_maps(4) file.

Users allocate devices through the Device Allocation Manager. The Device Allocation Manager mounts the device, runs a clean script to prepare the device and performs the allocation. When finished, the user deallocates the device through the Device Allocation Manager, which runs another clean script and unmounts and deallocates the device.

Device Label Ranges

To prevent users from copying off sensitive information, each allocatable device has an associated label range that is assigned by an administrator. To use an allocatable device, the user must be currently operating at a label within the device's label range; if not, allocation is denied. The user's current label is applied to data imported or exported while the device is allocated to the user. The label of exported data is displayed when the device is deallocated so that the user can physically label the medium containing the exported data.

Examples of devices that have label ranges are frame buffers, tape drives, diskette and CD-ROM drives, printers, and network interfaces.

Administering Devices through the Device Allocation Manager

The Device Allocation Manager is accessed from the Tools subpanel above the Style Manager in the Front Panel. The Device Allocation Manager is available to users with the Allocate Device authorization for allocation and deallocation only. Normal users cannot see if a device is currently allocated to another user and cannot perform maintenance through the Device Administration button in the Device Allocation Manager, which is available to authorized users and administrators only. The Device Allocation Manager is shown in the following figure.

Figure 1-7 Device Allocation Administration Dialog Boxes

Graphic

Device Administration Dialog Box

Clicking the Device Administration button in the Device Allocation Manager main window causes the Device Administration dialog box to be displayed (see following figure). The Device Administration dialog box lets you select a device. Its state is then displayed. The buttons in the upper right of the dialog box let you perform operations on the selected device. Clicking the Revoke button moves the selected device from a busy (allocated) state to an available (deallocated) state. Clicking the Reclaim button lets you make available a device that is currently in an error state. The revoke or reclaim device authorization is required to use these buttons. Clicking the Delete button makes a device unavailable. Clicking the New or Configure buttons displays the Device Allocation Configuration dialog box.

Figure 1-8 Device Administration Dialog Box

Graphic

Device Allocation Configuration Dialog Box

To use the Device Allocation Configuration dialog box requires the configure device attributes authorization. Clicking the Configuration button in the Device Allocation Maintenance dialog box causes the Device Allocation Configuration dialog box to be displayed (see following figure).

Figure 1-9 Device Allocation Configuration Dialog Box

Graphic

The Device Allocation Configuration dialog box is divided into three parts:

Device Allocation Authorizations Dialog Box

If you click the Authorizations button in the Device Allocation Configuration dialog box, the Device Allocation Authorizations dialog box is displayed (see following figure). It lets you specify the authorizations required for using the device.

Figure 1-10 Device Allocation Authorizations Dialog Box

Graphic

Device Allocation Databases and Commands

If you do not have access to the Device Allocation Manager, you can use the commands below to administer allocatable devices. The commands use the device databases: device_allocate(4), device_deallocate(4), and device_maps(4) . Note that the commands are not intended for non-administrative users.

Device Clean Scripts

Device clean scripts are special scripts that are run when a device is first allocated. Clean scripts address two security concerns:

Not all allocatable devices require a device clean program. Devices that do not keep states and do not use removable media do not need a device clean program.

Device clean programs for tape, floppy disk, CD-ROM, and audio devices are provided by the Trusted Solaris environment. The configurable nature of the user device allocation mechanism lets an administrator install new devices and configure device clean programs accordingly.

Device Allocation Security Policy

For more information on device allocation, see Chapter 15, "Managing Devices," in Trusted Solaris Administrator's Procedures.