Trusted Solaris Administration Overview

Understanding Trusted Software Administration

The following sections on roles, rights, authorizations, and privileges 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 can be designed to check for authorizations. They can also be assigned special security attributes: 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 when running these applications.

Trusted applications and authorizations are grouped in rights profiles (or profiles, for short) that 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 both enable and restrict users. It enables users by giving them access to commands, privileges, and authorizations not available to normal users. It can restrict users by limiting them to a specific set of commands. This might be appropriate for unsophisticated users.

In practice, here is an example of 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 the Trusted Solaris environment 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

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.) To assume a role, users 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 "Create Administrative Roles" section in Trusted Solaris Installation and Configuration.

Table 1-1 Roles and Their Responsibilities


Role (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. Implements auditing decisions. Can also make and restore backups and administer printing.
Security administrator (secadmin)	Responsible for security tasks and decisions. Administers labels. Oversees auditing. 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, as described in the 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 that needs this capability.

The potential contents of a rights profile are:

Authorizations
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

Assigning Rights Profiles to Users or Roles

To assign rights profiles to users, you open the User Properties dialog box from the Users tool in the Solaris Management Console (SMC) 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 Users tool.

Figure 1-2 Assigning Rights Profiles to Users

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 of the smprofile command (see "Displaying Rights Profile Information") 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 the 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 basic commands necessary for all roles.
Basic Solaris User	Assigned to all users of the Solaris Management Console. Provides Read permissions and lets users add cron jobs to their crontab files. Contains the All rights profile.
Convenient Authorizations	Provides authorizations for normal users.
Cron Management	For managing cron and at jobs.
Custom Admin Role	An empty right for adding security attributes to the default Admin role.
Custom Oper Role	An empty right for adding security attributes to the default Oper role.
Custom Root Role	An empty right for adding security attributes to the default Root role.
Custom Secadmin Role	An empty right for adding security attributes to the default Secadmin role.
Custom SSP	An empty right for adding security attributes to the default SSP role for Sun Enterprise^TM 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	For backing up 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	For operating outside system accreditation range.
Primary Administrator	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	For 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 smprofile -list command to obtain various rights profile information. This command displays the contents of any profile for all users or specified users and optionally displays the contents of the profiles. See the smprofile(1) man page for examples. Another option for displaying rights profile information is the profiles(1) command.

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 another role with equivalent powers. Use the Rights dialog box to edit the contents of rights profiles. The Rights dialog box is accessed from the Users tool in the Solaris Management Console. For more information, see the online help.

Figure 1-3 Rights Dialog Box

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 only superuser 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 following table lists the authorizations provided in the Trusted Solaris environment.

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 Users tool.

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 command getfpriv(1) lists the privileges that 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 of the smexec(1) 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, Front Panel, and Application Manager interpret profiles for actions. 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 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, system booting, system configuration management, console output redirection, device management, file systems, creating hard links to directories, increasing message queue size, increasing the number of processes, system network configuration, third-party loadable modules, or label translation	`sys_boot` - Lets a process halt or reboot a Trusted Solaris computer
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