test

Trusted Solaris Administrator's Procedures

Chapter 13 Adding Software

This chapter reviews how privileges are used by commands and actions. The chapter covers how to evaluate and install trustworthy software, including scripts, applications, and packages. This chapter contains these procedures:

Types of Software

The following types of software can be added to the Trusted Solaris operating environment:

Two distinct roles handle software evaluation and installation, the System Administrator role and the Security Administrator role.

Administrator Role Responsibilities

The System Administrator role installs software that meets the following criteria:

The System Administrator role also controls who can bring in software by granting or denying the device allocation authorization to individual users. An account with the device allocation authorization can import or export data at any single label within that user's clearance.

Security Administrator Role Responsibilities

The Security Adminstrator evaluates software for its ability to be trusted. As configured in the default system, the Security Administrator role can do the following:

See the Trusted Solaris Developer's Guide for how programmers can manipulate privileges.

Privilege Enabling Mechanisms

The Trusted Solaris operating environment enables and enforces privilege inheritance by means of the system shell, profile shells, and the trusted window system.The software can also force privileges on executables with the setfpriv command. Privileged programs that require dynamically-loaded libraries search a trusted library list.

For a description of privileges themselves, see "Adding New Privileges".

System Shell

The system shell, sysh(1M), enables commands in run control (rc) scripts to execute with privilege. For every command in the rc script, the sysh consults a rights profile for security attributes. If no specific rights profile is listed for the command, the /bin/sysh shell consults the boot rights profile.

The boot and inetd rights profiles are local to each computer. They specify commands that require security attributes during booting. The boot profile specifies security attributes for commands in /etc/init.d and /etc/inittab. The inetd profile specifies security attributes for commands in /etc/inetd.conf.

Caution - Caution -

Do not assign these profiles to any user or role. The results are unpredictable.

Profile Shells

Profile shells enable users and roles to execute commands with the security attributes that make the commands work. See the pfexec(1) man page for an explanation of the three profile shells, /bin/pfsh, /bin/ksh, and /bin/sh. All roles have a profile shell as their login shell. Users may or may not be assigned a profile shell, either as a login shell or as a shell made available in a rights profile.

Profile shells do not execute commands for roles unless the commands are issued within the trusted path.

Trusted Processes in the Window System

The following window system processes are trusted:

The window system's trusted processes are available to everyone, but access to actions in the window system are restricted by an account's rights profiles. For example, the administrative actions that are in the System_Admin folder can only be used if they are in one of the account's profiles. Therefore by default, since the Check Encodings action is in the Object Label profile assigned to the Security Administrator role and the Set Mount Points action is not, the Security Administrator role can use the Check Encodings action but cannot use the Set Mount Points action.

In the File Manager, if an action is not in one of the account's profiles, the icon for the action is not visible. In the Workspace Menu, if an action is not in one of the account's profiles, the action is visible, but an error displays if the action is invoked.

The CDE window manager, dtwm(1) calls the Xtsolusersession script, which then works with the window manager to invoke actions launched from the window system. Just as the profile shell consults an account's rights profiles when the account attempts to invoke a command, Xtsolusersession also consults the account's rights profiles when the account attempts to launch an action. In either case, if the action is in an assigned rights profile, the action is run with the security attributes specified in the profile.

Trusted Libraries

Dynamically-shared libraries used by setuid, setgid, and privileged programs can be loaded only from trusted directories. The list of trusted directories is in /var/ld/ld.config. Programs that require libraries from other directories will fail. See "Making Libraries Trusted " for how to extend the list of trusted libraries.

Assigning Privileges

Privileges can be forced on an object, or can be inherited by child processes. Therefore, the Security Administrator role has two ways to assign privilege:

  1. By giving forced privileges to the executable file itself (for commands only).

  2. By assigning inheritable privileges to a command or action in a rights profile.

    When the command is executed in one of the shells that understands profiles (either the profile shells described in the pfexec(1) man page or the system shell, as described on the sysh(1M) man page, it executes with privilege. When an action is launched by a trusted process in the window system, it executes with privilege.

Giving Forced Privileges to an Executable File

The Security Administrator role can assign forced privileges to an executable file for a command by using the File Manager Privileges dialog box or by entering the setfpriv(1) command in a profile shell, as described under "To Give Forced Privileges to a Command".

When a command with forced privileges is executed by any user in any shell, the forced privileges are put into the effective set of the executing program. The only way to prevent a user from executing such a command with privilege is to control access to the command itself. If you give the user only one profile shell to use, and do not assign the command, the user cannot execute the command.

To change the privileges on an executable file, the process's label must allow MAC write access to the file. The process does not require DAC write permission. The default Security Administrator role can change the privileges on an executable file in an admin_low workspace. The forced and allowed privilege sets of a file can be changed by:

Assigning Inheritable Privileges to a Command or Action

After a site is configured, a privilege should be granted by a site's Security Administrator role only if the security administrator is convinced that the command or action will use the privilege in a trustworthy manner.

Privileges are available by inheritance when they are in a command or action's allowed privilege set. The Security Administrator role uses the Rights tool in the Solaris Management Console to specify inheritable privileges for a command or an action. The role then assigns the rights profile to a user or role, unless the profile is consulted by the system shell during boot. See "System Shell" for the profiles that are not assigned to users or roles.

Passing Privileges to Child Processes

When a process executes a new program, the process's new inheritable set equals the process's old inheritable set before the new program was executed: I[new]=I[old]. The result is that the inheritable privileges available for one program to pass to another program are not affected by the forced or allowed privileges on the currently executing program.

The benefit of setting I[new]=I[old] without reference to allowed privileges is that privileges can be passed from a process executing a program that cannot use the privileges to one that can.

The benefit of setting I[new]=I[old] without reference to forced privileges is that forced privileges cannot be used by shell scripts.

Passing Privileges to Another Program

A process executing a program that has no allowed privileges cannot use any privileges because it cannot put any privileges into its effective set even if it inherits privileges from another trusted process. Such a process, however, can pass its inheritable privileges through to another program that it executes, one which might have allowed privileges and which therefore can use the inheritable privileges. The process executing the program without allowed privileges can pass privileges to another program because the inheritable set of the process is not affected by the lack of allowed privileges on the program. The following figure shows the inheritance mechanism.

Figure 13-1 How an Unprivileged Program Can Pass On Privileges

Graphic

Not Passing Forced Privileges via Shell Scripts

The inheritable set of a process cannot be increased by the forced privileges on the program. Any forced privileges on a shell script are not passed to commands invoked in a forced-privilege shell script. The result is that privileges cannot be used by shell scripts executed in standard UNIX shells, sh(1), csh(1), and ksh(1). See the following figure.

Figure 13-2 How Forced Privilege Shell Scripts Are Prevented from Passing On Privileges

Graphic

Creating and Using Shell Scripts

If an account has been assigned a normal UNIX shell (sh, csh, ksh), the account can create new shell scripts that can run any command in the system without privileges. Therefore, if none of its commands need privileges, a shell script can be used by anyone who has access to the script and its interpreting shell.

Making privileges available to commands that are invoked in shell scripts is done by the Security Administrator role.

Forced privilege commands are able to run with privilege in any shell because the forced privileges attached to the program file are available to the executing command. Assigning forced privileges to a csh, sh, or ksh shell script does not give any privileges to the commands executed by the shell script. Even though a shell that was started from the script runs with the forced privileges, the shell does not have any privileges in its inheritable set. See the rules for how processes get privileges, which are described in "Passing Privileges to Child Processes".

Caution - Caution -

Shell scripts are vulnerable to being modified without detection. Before releasing shell scripts that use inheritable privileges, the security administrator should keep in mind that the protection against tampering that is available for programs is not available to shell scripts.

Summary of Shell Script Behavior in the Trusted Solaris Environment

Figure 13-3 How Shell Scripts Pass Inheritable Privileges Using a Profile Shell

Graphic

Using Profile Shell Scripts

Profile shell scripts behave differently when invoked by normal users than they do for administrative roles.

Profile Shells for Normal Users

Profile Shells for Administrative Roles

Editing Executables With Inheritable Privileges

To prevent unauthorized tampering with object code, any forced and allowed privileges previously given to a file are deleted whenever any executable program file is edited. This prevents someone from editing a file so that it uses privileges in a manner that was not originally intended. The Security Administrator role can save the list of privileges on such a file before editing it and restore them afterwards, as described in "To Save and Restore Privileges When Editing a File".

Testing New Software for Security

The default Trusted Solaris programs and actions have already been assigned privileges, effective UIDs or effective GIDs when any of these attributes are required for the programs or actions to do their work. This section outlines the issues and tasks associated with adding the following types of software:

Evaluating a Program for Security

The security administrator is responsible for testing and evaluating new software. When your site wants to add any existing programs to a Trusted Solaris environment, whether it is an application written outside of your organization, a Solaris software program, or a program written in house, the security administrator makes the final determination. Part of the determination is technical, and part is affected by site policy and procedures.

  1. Find out if the application runs without changes in the Trusted Solaris environment.

    If it runs without privilege or any modification, the System Administrator role can install the application.

  2. If the program fails to run, find out why.

    Some software packages and third-party applications written for the Solaris environment cannot run because of certain modifications made to the Trusted Solaris operating environment to enforce security policy. For example, software that links with the kernel may be incompatible with Trusted Solaris modified kernel data structures. For similar reasons, loadable device drivers and other software may not be capable of operating in the environment unless changes are made to the code.

    If the program does not rely on aspects of the Solaris operating environment that have been modified for the Trusted Solaris environment, but it fails without privileges, find out what privileges or other attributes it needs.

  3. If the program does require the use of privilege, assess whether the program will use its privileges in a trustworthy manner. See "Considering When to Add Privilege".

    If the program cannot use its privileges in a trustworthy manner and it cannot be modified, do not make it available.

  4. If the program can safely run with the privileges or other security attributes in a manner that does not violate security policy, you may then assign the required privileges as described in "Assigning Inheritable Privileges to a Command or Action".

    If you make privileges available to a program, you need to make sure that any libraries used by the program are identified as trusted. See "Making Libraries Trusted ".

  5. If you can modify the program's source code, a security consultant or programmer knowledgeable about security can modify the code.

    These modifications might include privilege bracketing or adding code that makes the program aware of the Trusted Solaris security policy. You may then add privileges and trusted libraries. See "Making Libraries Trusted ".

Considering When to Add Privilege

The most obvious type of program that fails without privileges is one that needs to run in the Solaris environment as root (such as a program that executes with setuid root). This kind of program can be assigned an effective UID of root in a rights profile that is assigned to an administrative role.

UNIX applications that need to violate DAC often are implemented to make careful checks before doing so on a user's behalf. However, most applications are written in environments that do not have Trusted Solaris security mechanisms such as MAC. Therefore, a standard UNIX application does not carefully check MAC before violating MAC on a user's behalf. An administrator who gives such a program a MAC-override privilege may unintentionally provide a way for users to override MAC arbitrarily.

Some of the security considerations to be assessed are illustrated by the behavior of rcp(1), which is a commonly used UNIX program. The rcp command, which copies files across a network, runs with setuid root. Running as root allows the program to run with all privileges in a standard UNIX system. Although the program is allowed to bypass DAC restrictions, it checks for DAC permissions on a file to make sure the user who executed the has permission to access the file. But rcp has no knowledge of MAC restrictions. If you gave the rcp command the file_mac_read or file_mac_write privilege, it would not do the right kinds of checks for MAC relationships when accessing a file for a user; so rcp would not be able to use the privileges you assigned it in a manner that enforces the security policy of the system.

If you simply assign a similar program the privileges it needs to run and do not modify it to work within the security policy of the Trusted Solaris environment, the program violates system security. In order to make it run without violating system security, you would need to add to the program's source code. For example, if a program needed to bypass MAC restrictions when reading and writing files, you would need to modify the source code by adding the necessary MAC checks.

Some software may need privileges for reasons that are not obvious and sometimes not necessary for the program to succeed. Even if it is not performing any function that seems to violate system security policy, an application may be doing something internally that does violate security, such as keeping track of its operations in a shared log file, or reading from /dev/kmem (see mem(7D)). Sometimes these internal policy overrides are not particularly important to the application's correct operation but merely provide a convenient feature for users. If your organization has access to the source code, check if you can remove the operations that require policy overrides without affecting the performance of the application.

If the program would violate aspects of Trusted Solaris security policy, such as reading and writing files without doing MAC checks, then you should probably either make sure the required MAC checks are added to the source code, if you can, or not port the program.

Running a Program As Root

When an application has been written to run as root, the Security Administrator role has three options (all of which should be assessed for consistency with the site's security policy):

Cooperating to Create a Trusted Program

Even though a program's developer can manipulate privilege sets in the program's source code, if the Security Administrator role does not assign the required privileges, the program will fail. The developer and security administrator cooperate when creating trusted programs.

Developer's Responsibilities

A developer who writes a program to be added to a Trusted Solaris environment must do the following:

  1. Understand whether the program requires privileges to do its work.

  2. Know and follow techniques, such as privilege bracketing, for safely using privileges in programs.

  3. Be aware of the security implications when assigning privileges to a program and make sure that the program does not violate security policy.

  4. Compile using shared libraries linked to the program from a trusted directory.

    See the Trusted Solaris Developer's Guide for additional guidelines and examples of using privileges in programs.

Security Administrator Role`s Responsibilities

The Security Administrator role must ensure that a program that uses Trusted Solaris system calls and routines not compromise the security of the Trusted Solaris environment in any way.

  1. Make sure the programmer and the program distribution process is trusted.

  2. From one of these sources, find out which privileges are required by the program:

    1. Ask the programmer.

    2. Search the source code for any privileges that the program expects to use.

    3. Use the runpd command as described in "To Find Out Which Privileges a Program Needs".

  3. Scrutinize the source code to make sure it behaves in a trustworthy manner when using the privileges it needs to operate.

Adding Trusted Actions

The process of creating and using actions is pretty much the same in the Trusted Solaris environment as it is in a Solaris environment. Adding actions is described in the "Adding and Administering Applications" in Solaris Common Desktop Environment: Advanced User's and System Administrator's Guide.

In the Trusted Solaris environment, use of actions is controlled by the rights profile mechanism. Actions that are assigned security attributes in a rights profile can run with the assigned security attributes if they are invoked within one of the window system's trusted processes. In the Trusted Solaris environment, a number of actions have been assigned security attributes in the rights profiles of administrative roles. The Security Administrator role can also use the Rights tool to assign security attributes to new actions.

The following table summarizes the main differences encountered in creating and using actions in the Trusted Solaris environment.

Table 13-1 Constraints on Actions in the Trusted Solaris Environment

Solaris CDE 

Trusted Solaris CDE 

New actions may be created by anyone within the originator's home directory, and a new action is automatically usable by its creator. 

An action is only usable by a user or role if the action is one of the account's rights profiles. The actions' search path has been changed so that actions in any individual's home directory are processed last instead of first. Therefore, no one can customize existing actions. 

If either the Create Action action or commands or actions that permit the editing of files are in an account's profile, the user or role can create a new action in the account's home directory, but the account may not be able to use the new action.
 

There are two ways a user can use a new action: if the Security Administrator role adds the name of the new action to one of the account's rights profiles, or if the user has the All profile. The All profile turns off all checks for actions, and as a result any existing and potential actions may then be used by that account. 
 

If the account is allowed to use the action by its rights profiles, the account can launch the action from its home directory through the File Manager. The default System Administrator and administrator roles are permitted to place actions in public directories. 

Actions can be dragged and dropped to the Front Panel. 

The Front Panel is part of the trusted path. The window manager recognizes only the administratively-added actions that are located in /usr/dt and /etc/dt subdirectories where system-wide action files are kept. Even if a normal user account or a non-administrative role account creates a new action in the account's home directory and has the All Accounts profile, new actions dragged to the Front Panel from the user's home directory are not recognized by the window manager, which only looks in the public directories.

The only way that actions can do privileged operations is if they are run by root. 

If actions are specified to have privileges in one of the invoking account's rights profiles, actions can inherit privileges when they are launched from a trusted process. Therefore, the only way that actions can do privileged operation is if they have been assigned privileges in the account's profiles. 

Actions are not managed by the Solaris Management Console. 

Actions are assigned to rights profiles by the Rights tool. If new actions are added, the Security Administrator role needs to make the new actions available. See "To Make New Actions Available to the Rights Tool".

Finding Which Privileges a Program Needs

The runpd(1M) command is the privilege debugging program for Trusted Solaris software. By default, the runpd command is in a rights profile assigned to the Security Administrator role. The environment for running the command is disabled by default.

The runpd command requires the trusted path attribute, which a command can only obtain when the command is executed by a role. Therefore, a user cannot use the runpd command to find out what privileges are required.

The root role should not be used to debug privilege use because the UID 0 may give the command more access than it would have with another UID. Similarly, the Primary Administrator role is not a good privilege tester. Executing runpd in any administrative role except root and primaryadmin logs the privileges needed by any normal user if the command is run at a label within the user accreditation range.

The procedure "To Find Out Which Privileges a Program Needs" describes enabling the runpd environment and optionally creating an administrative role exclusively for doing privilege debugging.

The assignment of privileges should not be automatic. A program that fails due to lack of privilege may be assigned privileges, or, the Security Administrator role may decide to assign an effective UID or GID to make the privilege unnecessary.

When software has been assigned privileges or an alternate UID or GID, the software becomes trusted by virtue of the fact that it can bypass aspects of the Trusted Solaris security policy. Be aware that you can make software trusted even though it might not be worthy of trust. The Security Administrator role should not give any privileges to software until convinced that the software can use the privileges in a trustworthy manner. Only when it has been scrutinized and found to be using its privileges within the system security policy, can a program be called a trustworthy program.

Making Libraries Trusted

When a privileged program cannot find the libraries it requires, it fails with an error like the following:


ld.so.1: fatal: application-name: open failed: No such file or directory. 
Killed.

The Security Administrator role can add a privileged program's shared library directories to the list of trusted directories in /var/ld/ld.config. The crle(1) command must be used with both the -u and -s options followed by a colon-separated list of pathnames to the library directories.

The ldd(1) command lists the libraries that are used by a program. See "To Make a Library Directory Trusted" for how the Security Administrator can check for the library directories used by the application and run crle to add them to the trusted directories list.

The addition of a library directory to the list of trusted directories persists across reboots. However, if the crle command is ever entered with other options but without the -u option (perhaps by a third party script), any entries made on the command line will be removed.

To help ensure that all library directories needed for your privileged applications are configured as trusted directories at every reboot, the Security Administrator can create a boot-time script. See "To Make a Library Directory Trusted" for how to create such a script.

See /etc/rc2.d/S90wbem for an example of adding the JAVA library directories needed by the SMC to the trusted library directories list. See /etc/init.d/README and /etc/rc2.d/README for naming and numbering conventions for boot scripts.

Note -

By default, boot scripts run with the system shell and with a real UID of 0 at ADMIN_LOW.

Also see the ld(1) man page for information on the link editor for object files.

Adding Boot Commands

New commands can be added to run during boot in the following ways:

Unless other attributes are explicitly configured, commands run from the inittab or from scripts in /etc/init.d during the boot process have a label and clearance of ADMIN_LOW, a real and effective UID and GID of 0, and no privileges. If commands added into one of the files in the previous list need non-default security attributes, the commands must be added to local rights profiles. The Rights tool should be launched from a toolbox with the Files scope on the computer whose local files have been modified. Profiles defined on a naming service master are not going to be available to the boot programs on a naming service client.

Adding Commands to the inittab File

Make the changes to the inittab(4) file, and then add the commands to the boot profile. For example, if a script in /usr/local/bin named mysite needs to run with real UID of root, the Security Administrator role does the following:

  1. Uses the Admin Editor to add an entry for the mysite script to /etc/inittab:


    lo:234:respawn:/usr/local/bin/mysite

  2. Uses the Rights tool with the Files scope to add the script /usr/local/bin/mysite to the boot rights profile with a real UID of 0.

See "To Add Commands to the /etc/inittab File".

Adding Commands to /etc/init.d Scripts

In the default Trusted Solaris environment, the /etc/init.d scripts are modified to use the system shell, sysh(1M), instead of the Bourne shell, sh(1) when the service being started requires explicit privileges or other non-default security attributes that are defined in the boot profile. In the default boot scripts, /bin/sysh is used without the name of a profile argument because if no profile is specified, the system shell looks at the boot profile by default.

Caution - Caution -

Do not modify the commands already specified in the boot profile or modify the default /etc/init.d scripts. You can either add new scripts or change only scripts that may be added when a new application imported to the system.

When additional commands need to run during boot with non-default security attributes, the Security Administrator role specifies the commands with the needed attributes either by creating a new boot-time rights profile or by modifying the existing boot profile using the SMC Rights tool.

The role also needs do one of the following in /etc/init.d: modify an existing shell script, or create a new shell script so that the script starts with #!/sbin/sysh as the first line.

See the README in the /etc/init.d directory and in each /etc/rcn.d directory for guidelines about the numbering of the scripts that start system services.

As shown in the following example, a system shell boot script has #!/sbin/sysh as the first line. If the Security Administrator role has added the needed commands into the boot profile, there is no need to specify a profile name. If the Security Administrator role has created a new boot profile, the second line has the setprof argument followed by the name of the local_boot_profile. 


#!/sbin/sysh
 setprof local_boot_profile

For example, if a command needs a process label other than ADMIN_LOW, the profile needs to specify the label and if the command needs a UID of root, the profile needs to specify the required UID. See "To Run rc Scripts With Security Attributes".

Stopping or starting boot scripts in a Trusted Solaris environment requires privileges, so the script must be executed by the System Administrator Role in an administrative role workspace with the trusted path attribute, and the script's name must be in one of the account's rights profiles.

The toolbox from which the Rights tool is invoked should be running with the local FIles scope on the computer where the script is added to the /etc/init.d.

Adding Services to the inet Daemon

Services started by inetd(1M) run with the label and clearance of the client. inetd also runs with other attributes of the client if the following are specified in inetd.conf(4):

In addition:

See "To Add Services to the inetd.conf File".

Managing Software (Tasks)

To Mount a CD-ROM for Adding a Package

  1. Assume the System Administrator role and go to an ADMIN_LOW workspace.

  2. Allocate the CD-ROM device.

    Use the Allocate Device option from the Trusted Path menu or launch the Device Allocation Manager action from the Tools subpanel in the Front Panel.

  3. Double-click the name of the CD-ROM device in the list of Available Devices to transfer it to the list of Allocated Devices. Click OK to the ADMIN_LOW label.

  4. Insert the CD-ROM at the specified label into the drive and click the OK button.

  5. Click Yes to mount the CD.

  6. Press return when prompted to close the window.

  7. Deallocate the device when finished.

To Give Forced Privileges to a Command

An executable file with forced privileges runs with those privileges when invoked in a profile shell by any user or role.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

    A file's owner or a user with the Act as File Owner authorization can also add privileges to an executable at a label within the user or role's accreditation range.

  2. Navigate to the file's directory, and make sure the file is executable.

    If the file is not an executable and it should be, change permissions to make it executable, as in:


    $ chmod 755 filename

  3. Give the command allowed privileges equal to the forced privileges you plan to assign.

    If you are using the File Manager Permissions dialog box, click the Allowed button, assign Allowed Privileges, and then click the Forced button to assign the Forced Privileges.

    The following example shows using the setfpriv(1) command to set file_dac_read and file_dac_write as allowed and forced privileges.


    $ setfpriv -s -f file_dac_read,file_dac_write \
-a file_dac_read,file_dac_write test.priv.file

To Create a New File Edit Action

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. Launch the Admin Editor action to open the /usr/dt/appconfig/types/C/TSOLadmin.dt file for editing.

    See "To Log In and Assume a Role", and "To Edit a Local File", if needed.

  3. Copy and paste the definition for one of the existing actions in the TSOLadmin.dt file.

    The example in this procedure modifies a copy of the Vfstab action.


    ACTION Vfstab
{
        LABEL        Set Mount Points
        ICON         Dtpenpd
        TYPE         COMMAND
        WINDOW_TYPE  NO_STDIO
        EXEC_STRING  /usr/dt/bin/trusted_edit /etc/vfstab
        DESCRIPTION  Specify the file system mount points
}

  4. Modify the copied action's definitions.

    1. Change the ACTION name.

      This example creates a new action to edit the /etc/system file to modify Trusted Solaris kernel switch settings.


      ACTION EditSystemFile
{

    2. Change the LABEL.


      LABEL            Edit System File

    3. Change the ICON, if you have created a new icon or want to use another existing one from /usr/dt/appconfig/icons/C.


      ICON           Dtpenpd

    4. Change the file name in the EXEC_STRING.


      EXEC_STRING      /usr/dt/bin/trusted_edit /etc/system

    5. Change the text in the DESCRIPTION. 


      DESCRIPTION        Modify system file
}

  5. Save and close the TSOLadmin.dt file.


    :wq

  6. Copy and rename the Vfstab action file.

    1. Go to /usr/dt/appconfig/appmanager/C/System_Admin.

    2. Clone the Vfstab file and rename it to the name of the new action.

      For example, rename Vfstab to EditSystemFile.

    3. Make the action file executable.

      Select the Permissions option on the File Manager's File menu and set the permissions to executable for owner, group, and other, or enter the following on the command line:


      $ chmod 777 EditSystemFile

  7. In the System Administrator role, copy the modified TSOLadmin.dt and action files to every host in the domain.

    Since actions are not administered through the name service, some other means of distribution must be used, such as rdist(1) or sneakernet (copying the files to a floppy and carrying it around to install the files on each host).

  8. In the Security Administrator role, bring up the Solaris Management Console, choosing the appropriate name service scope.

    To make the action available only to one host, choose the Files scope on the host.

  9. Click Users and provide a password when prompted.

  10. Double-click the Rights tool, then double-click either the Information Security profile or the Object Access Management profile.

    The Properties dialog box for the Right displays.

    1. If the action edits a security-relevant file, such as the /etc/system file, open the Information Security profile.

    2. If the action edits an administrative file that would normally be modified by a UNIX system administrator and that does not contain labels or other security attributes, such as the group file, open the System Management profile.

  11. Click Actions, then System_Admin in the Actions Denied column.

    The new action should be listed. Refer to the online help for assistance.

  12. Add the action to the rights profile, and assign to the action the same privileges that are assigned to the Set Mount Points action: file_dac_read, file_dac_write, proc_audit_appl, proc_audit_tcb.

  13. To make the action usable, log out and log in again.

To Add Actions Outside of the System_Admin Folder

Adding actions can be done as described in the Solaris Common Desktop Environment: Advanced User's and System Administrator's Guide, within Trusted Solaris MAC constraints.

  1. As a user or role, create the action by using the CreateAction action, or manually.

  2. Assume the Security Administrator role, and label the action ADMIN_LOW.

  3. Place it in the /etc/dt/appconfig/types/C directory so that CDE makes it available.

    Note -

    Added actions are software. Their trustworthiness must be checked before they are made generally available. See "Testing New Software for Security".

To Make New Actions Available to the Rights Tool

  1. Assume the Security Administrator role, and go to an ADMIN_LOW workspace.

  2. Remove the /usr/dt/appconfig/smc/C/actions file on the SMC server.


    $ rm /usr/dt/appconfig/smc/C/actions

  3. Log out and log into the SMC server using the CDE login screen.

    CDE regenerates the removed file, and populates it with all actions that it finds.

To Write a Profile Shell Script

Note -

When adding a profile shell script that runs commands with inherited privilege, the Security Administrator role needs to update an appropriate rights profile with a list of each of the commands that run within the shell script and to assign the commands any privileges they need. If a new shell script needs to be used by a role, all the commands that need security attributes must be added to the Custom role_name Profile or other profile that applies to the role, along with the name of the script itself.

Anyone with a text editor can write the shell script.

  1. Start the script with /bin/pfsh (or any other profile shell) on the first line. 


    #!/bin/pfsh

  2. Determine which commands need privileges and which privileges are needed.

    In the example, /usr/lib/fs/nfs/nfsfind is a cron job owned by root that needs privileges in order to run successfully at ADMIN_HIGH. The tfind command needs the file_dac_search and file_dac_read privileges and the rm command needs the file_dac_search, file_dac_write, file_dac_read, and file_mac_write privileges. See "To Find Out Which Privileges a Program Needs", if needed.


    #!/bin/pfsh
# Copyright (c) 1993, 1997, 1998, 1999 by Sun Microsystems, Inc.
#ident  "@(#)nfsfind.sh 1.5     97/05/21 SMI; TSOL 2.x"
#
# Check shared NFS filesystems for .nfs* files that
# are more than a week old.
# 
# These files are created by NFS clients when an open file
# is removed. To preserve some semblance of UNIX semantics
# the client renames the file to a unique name so that the
# file appears to have been removed from the directory, but
# is still usable by the process that has the file open.
if [ ! -s /etc/dfs/sharetab ]; then exit ; fi
 for dir in `awk '$3 == "nfs" {print $1}' /etc/dfs/sharetab`
do 
    tfind $dir -M -name .nfs\* -mtime +7 -mount -exec rm -f {} \;
done

  3. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  4. Use the Rights tool to update an appropriate profile to list the script, each of the commands that need to run within the shell script and to assign the commands the privileges they need.

    See "To Launch the Solaris Management Console", if needed.

    To continue with the example, to enable the System Administrator role to run the example cron script with the needed privileges, the Security Administrator uses the Rights tool to update the Custom Admin Role and makes sure it is assigned to the System Administrator role. The rights profile is modified to include the /usr/lib/fs/nfs/nfsfind script, the tfind command with the file_dac_search and file_dac_read privileges and the rm command with the file_dac_search, file_dac_write, file_dac_read, and file_mac_write privileges.

    Caution - Caution -

    When you add commands to a profile and give them privileges or other security attributes, the commands execute with those attributes, not only in the profile shell script but whenever they are invoked in any profile shell, as long as the profile is in effect for the invoking account. The order of profiles is also important: the profile shell executes a command or action with whatever security attributes are specified in the first profile in the account's list of profiles. For example, if tfind is in the Custom Root Profile with privileges, and the Custom Root Profile is the first profile in which tfind is found, then tfind will inherit the privileges specified in the Custom Root Profile when the root role executes tfind on the command line in a profile shell.

To Write a Standard Shell Script that Runs Privileged Commands

Note -

You can create a standard shell script to run its commands with privileges by adding the script to a rights profile and specifying the script to run with all the privileges that are needed by the script's commands. The script then inherits privileges when invoked in a profile shell, when an account has a rights profile containing the script.

  1. Start the script with any standard shell (not a profile shell) on the first line. 


    #!/bin/csh

  2. In the PrivDebug or the Security Administrator role, determine what privileges are needed by what commands in script.

    See "To Find Out Which Privileges a Program Needs", if needed. The example, called autosetpriv, would enable the Security Administrator to assign a defined set of forced and allowed privileges to a file called executable. The setfpriv command in this script needs the file_setpriv privilege.

    Note -

    This shell script is just an example. A normal shell script accepts the privileges and the filename as arguments and does error checking.


    #!/bin/csh
 setfpriv -s -f ipc_mac_write,proc_setsl,sys_trans_label
-a ipc_mac_write,proc_setsl,sys_trans_label executable

  3. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  4. Use the Rights tool to update an appropriate profile to list the script, each of the commands that need to run within the shell script and to assign to the commands the required privileges.

    See "Adding or Modifying a Rights Profile", if needed.

    To enable the script called autosetpriv to run with the file_setpriv privilege needed by the setfpriv command, the Security Administrator role would use the Rights tool to update the Custom Secadmin Role (which is assigned to the Security Administrator role by default) to include the autosetpriv script and assign to autosetpriv the file_setpriv privileges.

  5. Test, debug, and execute the shell script as desired in the profile shell.


    $ autosetpriv

To Save and Restore Privileges When Editing a File

  1. Assume the Security Administrator role and use the getfpriv command to list the privileges on the executable file and save the output.

    The following example directs the output into a temporary file. 


    $ getfpriv executable_file > tempfile

  2. After editing the executable file, use the File Manager to make the file executable again (if needed) and then restore the privileges listed in the temporary file.

    The following example uses the setfpriv(1) command to set the privileges stored in the tempfile created in Step 1.


    $ setfpriv -s -f `cat tempfile` program_pathname

To Find Out Which Privileges a Program Needs

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. (OPTIONAL) Create a Privilege Debug profile and assign it to an administrative role.

    Note -

    The Security Administrator role is the only role assigned the runpd command in the default configuration. The administrative role that can be created in this step could be used exclusively for privilege debugging. The role can be used to find out what privileges a command needs when run by a normal user at a label within the user accreditation range or by an administrative role at one of the administrative labels.

    1. In the appropriate scope, launch the SMC and use the Rights tool to create a new rights profile (such as Privilege Debug).

      Give the new profile the commands: /usr/sbin/runpd, /bin/getfpriv, and /bin/setfpriv, the authorizations: Shutdown the System, Enable Login, and Set File Privilege, and the action: Admin Editor. The profile enables an administrative role to enable privilege debugging and execute the /usr/sbin/runpd command.

    2. If desired, use the Administrative Roles tool to create an administrative role (such as PrivDebug).

    3. Assign the role the new profile and the All profile, if desired.

      Place the more restrictive rights profile, Privilege Debug, before the less restrictive profile, All.

    4. If you created a new role, open the User Accounts tool and assign the privilege PrivDebug role to an account.

  3. Assume the new role, or stay in the Security Administrator role.

  4. Use the Admin Editor action to change the tsol_privs_debug setting to 1 in the /etc/system file.


    set tsol_privs_debug=1

  5. Use the Admin Editor action to remove the comment (#) at the beginning of the line that begins kern.debug in the /etc/syslog.conf file.

    The following line logs the privileges requested by system calls and daemons in the /var/log/privdebug.log file. 


    kern.debug;daemon.debug;local0.debug /var/log/privdebug.log

  6. Reboot to enable privilege debugging.

  7. Log in and assume the Security Administrator role or, if you created a new privilege debugging role in Step 2, assume the new role.

  8. Create a workspace at the label at which the test program will typically be run.

  9. In a terminal at the appropriate label, enter the runpd command followed by the name of the command and any options whose use of privilege you want to check.

    As shown in the following example, runpd displays the name of the privilege(s) that the program needs in order to succeed followed by the type of access attempted (for example, create) followed by the name of the resource (for example, RAW_SOCKET).


    $ runpd pathname_of_command_and_any_options

runpd: child terminated with a status of 0

process pathname_of_command pid process_ID 
lacking privilege privilege_name
to perform type_of_access 
upon resource resource_name (MM DD HH:MM)

    The following example shows the result of running runpd(1M) on ping(1M) (for the purpose of the example, Trusted Solaris privileges were removed from the command).


    $ runpd /usr/sbin/ping sif 
sif is alive runpd: child terminated with a status of 0 
process /usr/sbin/ping pid 5138 lacking privilege net_rawaccess 
to create raw socket (Oct 25 18:33) 
process /usr/sbin/ping pid 5138 lacking privilege 
sys_net_config to manage transport opts (Oct 25 18:33)

  10. Open an ADMIN_HIGH workspace, and check the log file for the privilege debugging messages.

    A typical privilege debugging log entry is similar to the following:


    $ cat /var/log/privdebug.log
Mar 29 12:18:43 hostname unix: 
DEBUG: pathname_of_command pid 
process_ID lacking privilege number to 
number_of_type_of_access number_resource

    The following screen shows the privdebug.log entries from when runpd was run on ping.


    Oct 25 18:33:35 tern unix: 
DEBUG: /usr/sbin/ping pid 5138 lacking privilege
36 to create raw socket
Oct 25 18:33:35 tribble unix: 
DEBUG: /usr/sbin/ping pid 5138 lacking privilege
68 to manage transport opts

    The privilege numbers appear after the word "privilege." You can look up a privilege number in the /usr/include/sys/tsol/priv_names.h file to find its name. For example, the privilege number 36 is associated with the name net_rawaccess. The numbers following the privilege number and the word "to" are the number of the type of access attempted followed by the number of the resource.

  11. Have the security administrator evaluate whether to give the program the privileges it is missing.

  12. If the privileges should be granted, see "To Give Forced Privileges to a Command" and "Adding or Modifying a Rights Profile" for how to assign privileges.

  13. Turn off privilege debugging: restore the changes you made to the /etc/system file and the /etc/syslog.conf file in Step 3 and Step 5 and reboot the machine.

To Make a Library Directory Trusted

The following procedure describes how to determine which libraries should be trusted, and then describes how to add them to the trusted library directories list.

  1. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

  2. Remove any forced privileges assigned to the program.

    If the program does not have forced privileges, then you do not need to do the following substeps or Step 4.

    1. Check the command for forced privileges.

      The following example gets the list of privileges and saves them in a file. The file can be used to reset the privileges, if any, after the ldd(1) command is run.


      $ getfpriv -s -f program_name > filename

    2. Remove the privileges from the program.


      $ setfpriv -s -f none program_name

  3. Use theldd command to find out which library directories the application program is using.


    $ ldd program_name
    Note -

    The program that is using the shared libraries may be imbedded in a script, so make sure you are running ldd on the actual program that needs the libraries.

  4. If you removed forced privileges from the program in Step 2, add the privileges back to the program.

    The following example uses setfpriv to set the privileges stored in filename in Step a.


    $ setfpriv -s -f `cat filename` program_name

  5. Use the Rights tool to add the crle command to the Custom Secadmin Profile with a real UID of 0, and a label and clearance of ADMIN_LOW.

    See the crle(1) man page for more information.

  6. Use the crle command to add the library directories from Step 3 to the list of trusted library directories.


    $ crle -u -s [directory_1[: . . . :directory_N]

  7. To regenerate the list of trusted directories at every reboot, add the crle command to a boot-time script.

    Use the Admin Editor to create or modify a script in the /etc/init.d directory.

    If a privileged application already has a script, modify the existing script. Otherwise, create a new script.

    Caution - Caution -

    Do not modify any default Trusted Solaris scripts. Modify only scripts that are installed with new applications that need privileges.

    The following is an example of executing the crle command in a script:


    crle -u -s directory_1[: . . . :directory_N]

  8. Make a hard link from the script in the /etc/init.d directory.

    Use the S prefix in the target file's name for starting the script. Use the proper two-digit number in the target file's name to determine the order in which the script is executed during the run level. See the README in /etc/init.d and /etc/rc2.d, if needed.

    In the following example, the name of the new script in /etc/init.d is new_script, which is linked to /etc/rc2.d/S87new_script.


    $ cd /etc/rc2.d
$ ln /etc/init.d/new_script S87new_script

To Add Commands to the /etc/inittab File

  1. Assume the Security Administrator role and use the Admin Editor action at ADMIN_LOW to edit the file /etc/inittab.

    The following example adds /usr/local/bin/mysite to the file.


    lo:234:respawn:/usr/local/bin/mysite

  2. Save and quit the file.


    :wq

  3. Use the Rights tool in the Files scope to add the script /usr/local/bin/mysite to the boot rights profile with a real UID of 0.

To Run rc Scripts With Security Attributes

Note -

To add security to rc scripts, create a new profile and use the setprof command to refer to the new profile in a new sysh(1M) script, as described in this procedure.

  1. Assume the Security Administrator role and use the Admin Editor action at ADMIN_LOW to create a new sysh script in /etc/init.d.

    See the sysh(1M) man page and "System Shell". The first line of the script should read as follows: 


    #!/bin/sysh

  2. On the second line of the script, type in the setprof option to identify the name of a rights profile.


    setprof new_profile_name

  3. Save and quit the file.


    :wq

  4. In the /etc/init.d directory, make a hard link from the new script to the desired /etc/rcn.d directories.

    1. For each run level at which the command should be started or stopped, go to the appropriate /etc/rcn.d directory and create a hard link from a properly-named target file to the /etc/init.d directory.

    2. Use the proper prefix in the target file's name for either starting (S) or stopping (K).

    3. Use the proper numbers in the target file's name to help determine the order in which the script is executed during the run level.

      In the following example, the name of the new script in /etc/init.d is new_script, which is linked to /etc/rc2.d/S89new_script and /etc/rc2.d/K8new_script.


      $ pwd
/etc/init.d
$ ln new_script /etc/rc2.d/S89new_script
$ ln new_script /etc/rc2.d/K89new_script

  5. Use the Rights tool with the Files scope to create a new rights profile.

  6. Add the command and any desired security attributes.

  7. Reboot to effect the change.

To Add Services to the inetd.conf File

  1. Assume the Security Administrator role and use the Admin Editor action in an ADMIN_LOW workspace to open the /etc/inet/inetd.conf file for editing.

    For example, the following line adds a service in /usr/local/bin named newservice with the CLIENT keyword in the UID field so that the service executes with the UID and GID(s) of the CLIENT. In the flags field, the trusted keyword causes the service to run with the trusted path attribute, and the setaudit keyword causes the service to run with the client's audit characteristics:


    myport stream tcp6 nowait,trusted,setaudit CLIENT /usr/local/bin/newservice

  2. Save and quit the file.


    :wq

  3. If the service needs to run with privileges or a restricted label range, use the Rights tool to add the service to the inetd rights profile along with any desired security attributes.

To Install a Java Jar File

The security administrator must verify that the source of the Java program is trustworthy, that the method of delivery is secure, and that the program can run in a trustworthy manner. To limit the security risk, the system administrator can download the software to a single label within the users' accreditation range, where the security administrator can test it at that label. The administrator can then downgrade the label to ADMIN_LOW, and install it on an application server to make it available to all users.

  1. Assume the System Administrator role and go to an ADMIN_LOW workspace.

  2. Download the Java jar file to the /tmp directory.

    For example, if you are selecting software from the http://www.sunfreeware.com, download the link that is described with "Web Start Wizard form of application.

  3. Open a File Manager to the /tmp directory.

    The Software Installation profile includes the Open action for Java code.

  4. Double-click the downloaded file.

  5. Answer the questions in the dialog boxes to install the software.

  6. Read the installation log.