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 |