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.
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.
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.
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.
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.
The following sections describe 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.
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.
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
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.)
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:
CDE actions with or without real and effective UIDs and GIDs, privileges, process labels, and clearances
Commands with or without real and effective UIDs and GIDs, privileges, process labels, and clearances
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.
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 |
---|---|
Provides access to all executables but without privileges. |
|
All Actions |
Provides access to all actions but without privileges. |
Provides all authorizations. For testing. |
|
All Commands |
Provides access to all commands but without privileges. |
For managing the audit subsystem but without ability to read files. |
|
For reading the audit trail. |
|
Provides access to the applications on the Front Panel with the necessary privileges. |
|
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. |
Provides authorizations for normal users. |
|
For managing cron and at jobs. |
|
This is an empty right for adding security attributes to the default Admin role. |
|
This is an empty right for adding security attributes to the default Oper role. |
|
This is an empty right for adding security attributes to the default Root 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. |
For managing and configuring devices. |
|
Provides the authorization for allowing yourself and other users to log in after boot. |
|
For managing file systems. |
|
For managing file system labels and other security attributes. |
|
Information Security |
For setting access control policy. |
For configuring sendmail, modifying aliases, and checking mail queues. |
|
Provides commands needed to maintain or repair a system. |
|
Backup files. |
|
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. |
For managing the host and network configuration. |
|
Network Security |
For managing network and host security, with authorizations for modifying trusted network databases. |
For changing ownership and permissions on files. |
|
For changing labels of files and setting up system-wide labels. |
|
For changing privileges on executable files. |
|
Operate outside system accreditation range. |
|
Primary Adminstrator |
Contains subordinate rights profiles for primary administrator role. |
For developers to run Bourne, Korn, and C shells with all privileges. NOT intended for secure environments. |
|
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. |
For creating and modifying users but without the ability to modify self (as a security measure). |
|
For creating and modifying users' security attributes but without the ability to modify self (as a security measure). |
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).
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.
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.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.
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.
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.
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.
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 |
---|---|---|
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. |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
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.
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.
One entity's label is said to dominate another's if the following two conditions are met:
The classification component of the first entity's label is equal to or higher than the second entity's classification. (The security administrator assigns numbers to classifications in thelabel_encodings(4) file; these numbers are compared when determining dominance.)
The set of compartments in the first entity includes all of the second entity's compartments.
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 |
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.
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:
component definitions--definitions of classifications, compartments, labels, and clearances, including rules for required combinations and constraints
accreditation range definitions--specification of the clearances and minimum labels that define the sets of available labels for the entire system and for normal (non-administrative) users
printing specifications--identification and handling information for print banners, trailers, headings, footers, and other security features for printouts
customizations--local definitions including label color codes, alternative names for classifications, compartments, and markings in the graphical interface, and other items
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.
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.
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.
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.
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 |
---|---|
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. |
|
The -m option indicates whether or not the directory is an MLD. |
|
The getmldadorn(1) command displays the MLD adornment of the filesystem on which the specified pathname resides. |
|
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. |
|
When used with -M option or when the directory name has the .MLD. adornment, creates a new MLD. | |
The mldpwd(1) command displays the pathname of the current working directory, including any MLD adornments and SLD names. |
|
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. |
|
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.
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.
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.
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.
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 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.
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.
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.
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.
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).
The Device Allocation Configuration dialog box is divided into three parts:
Device security attributes--includes device name and type, minimum and maximum labels, clean program, and device map.
Allocation specifications--from Trusted Path or non-Trusted Path (for command line users), authorized users (with the authorizations specified in the Authorizations field), no users (if device is not allocatable), all users (if no authorizations required), and which authorizations to require for device allocation
Deallocation options--deallocate any allocated devices on reboot and deallocate any allocated devices on logout
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.
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.
add_allocatable(1M)--adds devices to the allocation databases.
allocate(1M)--manages the ownership of devices through its allocation mechanism. It ensures that each device is used by only one qualified user at a time.
deallocate(1M)--deallocates a device allocated to the evoking user.
list_devices(1M)--lists the allocatable devices in the system according to specified qualifications.
dminfo(1M)--displays information about device entries in the device maps file.
Device clean scripts are special scripts that are run when a device is first allocated. Clean scripts address two security concerns:
Object reuse - the requirement that a device is clean of previous data before being allocated or reallocated
Media labeling - the requirement that removable information storage media have a physical label indicating its label. While the ultimate responsibility for putting the labels on the removable media rests with the user, the device clean scripts can prompt the user to do so.
The name of a device clean script for a specific device is stored with that device's entry in the device_allocate(4), file. The operations of each device clean program are specific to each device. The following is a list of tasks that a device clean program performs:
Eject media - Devices that store information on removable media must be forced to eject that media upon deallocation or reallocation of the device, to prevent passing information to the next user of the device who may be at a different label.
Reset device state - Devices that keep state information can potentially be used as a covert channel by the users. Thus driver status information must be reset to default values during deallocation of the device.
Remind user about media labeling - It is a requirement that removable information storage media be labeled with appropriate external media labels. The device user's label is passed to the device clean program when it is invoked (Seedevice_clean(1M) man page for interface detail.)
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.
For more information on device allocation, see Chapter 15, "Managing Devices," in Trusted Solaris Administrator's Procedures.