test

Trusted Solaris Administrator's Procedures

Chapter 5 Managing Roles

This chapter provides background about administrative roles and describes how to expand a role's powers. This chapter contains the following procedures:

Roles and the Trusted Path Attribute

Roles in the Trusted Solaris environment divide the privileges of the root account into discrete accounts. In the Trusted Solaris environment, privileged actions require the trusted path attribute.

The trusted path attribute is available during boot and when a program is launched from a role workspace.

Many administrative commands and actions require the trusted path attribute. For instance, when the Solaris Management Console (SMC) is launched on behalf of an administrative role, the SMC checks for the trusted path attribute.

Allowing Remote Logins by Administrative Roles

In both the Trusted Solaris and Solaris environments, remote logins may or may not require authorization. "Managing Remote Logins" describes the conditions and types of logins that require authorization. The administrative roles by default have the Remote Login authorization, but the Security Administrator role needs to change a setting in the /etc/default/login file on each computer where administrative roles work, to allow remote logins from that computer. See "To Enable Any Role to Log In Remotely" for the procedure.

Creating a New Role

Sites may create a new administrative role to enable a users to perform a defined set of administrative tasks. While in the role, the users share the role's home directories (at different labels) and ownership of files. A site might create a new administrative role, for example, to handle auditing review.

If the new role needs capabilities that the Security Administrator role does not have to give away, the Primary Administrator role creates the new role. The procedure is described in "To Modify a Role".

Caution - Caution -

If site security policy permits, root's capabilities can be extended to allow root to do NIS+ administration from a NIS+ client, although this is not recommended. See "To Enable a Role to Administer NIS+" for the procedure.

A new role may require a new profile. If the profile needs capabilities that the Security Administrator role does not have, the primary administrator role must create the profile.

Before creating the profile, the Security Administrator role should analyze whether any of the commands or actions in the new profile need privilege to be successful, as described in "To Find Out Which Privileges a Program Needs". See the man pages for individual commands for the required and override privileges a command might need.

Modifying a Role With the SMC

Adding or modifying a role account in the SMC is similar to adding or modifying a user, with the following exceptions.

Customizing Profiles for the Recommended Roles

Custom role profiles are used when customizing default profiles that are assigned to the recommended roles. Making all changes for each role in its custom profile makes it much easier to debug problems or characterize the system if you ever need to call for service.

Enabling Role Assumption from Untrusted Systems

In the Trusted Solaris environment, users assume roles through the Trusted Path menu. The roles then operate in protected trusted workspaces. By default, roles cannot be assumed outside of the trusted path. If site policy permits users on unlabeled hosts that are running SMC 2.0 client software, to assume a role and administer trusted hosts, the Security Administrator role can change the default policy.

See "To Enable Remote Role Assumption from Untrusted Systems" for the procedure.

If this policy change is made, it only applies when the user on the remote untrusted computer has an account on the Trusted Solaris system with the ability to assume the desired role.

Managing Roles (Tasks)

To Alias vi to adminvi

By default, all roles have the adminvi(1M) editor and the dtterm terminal assigned by default.

The default profile(4) file in the home directories for all roles has the following function to alias vi to adminvi: 

vi() { adminvi $1 ; }

However, the alias does not by defaults since the .profile file is not sourced by default. For more information about startup files in the Trusted Solaris environment, see the discussion in Chapter 3, Managing User Accounts under "Managing Initialization Files".

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

  2. Create an .Xdefaults file for each hostname the role uses.

    For example, when the role works on computers named tern and toucan, create a $HOME/.Xdefaults-toucan and a $HOME/.Xdefaults-tern.

  3. Add the following entry to the $HOME/.Xdefaults-hostname file in the SLD at each label at which the role works:


    Dtterm*LoginShell: true

  4. Make sure that a copy of the file is in every SLD at which the role works.

    See "Using .copy_files and .link_files" for how to copy or link files into every SLD.

To Assign the trusted_edit Editor to a Role

The /usr/dt/bin/trusted_edit script is a wrapper that launches an editing window using the $EDITOR environment variable. The wrapper audits all changes.

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

  2. If the trusted_edit command is not in one of the role's profiles, use the SMC Rights tool to add the trusted_edit command to the Custom rolename profile.

    Refer to the online help when modifying the rights profile.

    1. Add the /usr/dt/bin/trusted_edit script to the Custom rolename profile.

    2. Give the script the proc_audit_tcb privilege.

  3. Make sure that the role has the Custom rolename profile assigned to it or subsumed in one of its assigned rights.

To Alias vi to trusted_edit

Caution - Caution -

Because trusted_edit launches a window, it cannot be used for command line editing. Command line editing may be the only option available in a remote login session, so for this reason, do not assign trusted_edit as the only editor for a role, unless the role never needs to do remote editing on the command line.

  1. Search for the vi function in the .profile file in the role's home directory:


    vi() {adminvi $1;}

  2. Replace adminvi with trusted_edit:


    vi() {trusted_edit $1;}

  3. Make sure the following entry is also made in the $HOME/.Xdefaults-hostname file in the SLD at each label at which the role works:


    Dtterm*LoginShell: true
    Note -

    Make a file for each hostname the role uses. For example, when the role works on computers named tern and toucan, create a $HOME/.Xdefaults-toucan and a $HOME/.Xdefaults-tern in each SLD.

To List All Roles

Once the SMC is initialized, users or roles can use the smrole(1M) command described below to see a list of all roles.

  1. Assume the Security or System Administrator role.

  2. To list the roles in a name service domain, use the smrole list command with the -D option to specify the name_service_type:/server_name/domain_name. Provide a password when prompted.

    The following screen example lists the roles that are defined in the NIS+ domain tropics.example.com whose NIS+ master server is toucan. The command is being executed on the tern system:


    $ /usr/sadm/bin/smrole list -D nisplus:/toucan/tropics.example.com --
Authenticating as user: admin

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password ::  rolePassword
Loading Tool: usermgr.cli.role.UserMgrRoleCli from tern
Login to tern as user janez, role admin was successful.
Download of usermgr.cli.role.UserMgrRoleCli from tern was successful.
admin           100             System Admin
secadmin        101             Security Admin
oper            102             Operator
primaryadmin    104             Primary Administrator Role
root            0               Super-User

  3. To list the roles defined in the local system, use the smrole list command followed by the double dash --.


    $ /usr/sadm/bin/smrole list --

    To list all roles defined in local files on a system named tern:


    /usr/sadm/bin/smrole list  -- -h tern

To Modify a Role

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

    If the role requires authorizations that the Security Administrator cannot grant, the Primary Administrator role must change the role.

  2. Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

  3. Double-click the Rights tool, then select the Custom rolename Role.

    To modify a role, you modify the contents of one or more of its rights profiles.

  4. Make any needed modifications to the Custom rolename profile.

    Add or change any of the following security attributes in the Custom rolename profile:

    • Commands or actions with security attributes

    • Authorizations

    • Profile

  5. Double-click the Administrative Roles tool, select the role, and choose Action->Assign Rights.

    If you modified an existing Custom rolename Role profile, make sure that it is assigned to the role. The rights profile should be ordered before the All profile.

    For example, if you are changing the System Administrator role, and the Custom Admin Role profile is not assigned to the role, you would use the Administrative Roles tool to add the Custom Admin Role to the list of Rights for the role. You would also move the Custom Admin Role before the All profile in the list.

To Configure a New Role

  1. Define the role's responsibilities, and decide what commands, actions, security attributes, and authorizations the role needs to do its work.

  2. Decide whether any of the commands or actions need privileges or other security attributes to do their work, and, if so, decide whether the role and the command or action can use these security attributes in a trustworthy manner.

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

  4. Bring up the SMC in the desired scope and click the Users tool. Supply a password when prompted.

  5. If the role needs to have a new or modified rights profile, double-click the Rights tool to create or modify the rights profile.

    See "To Create a Help File for a Rights Profile" and "To Create a Rights Profile" if you need to create a new rights profile.

    To modify a right, select it and follow the online help.

  6. Double-click the Administrative Roles tool, and choose Action->Add Role.

    Refer to the online help when naming and describing the role.

  7. Order the Custom rolename Role profile before other profiles you assign to the role.

    For example, you would order a Custom Auditadmin Role before the All profile.

  8. If you are running the NIS+ naming service, make an entry for the new role in the NIS+ admin group.

    See "To Enable a Role to Administer NIS+", if needed.

To Enable a Role to Administer NIS+

  1. Log into the NIS+ master and assume the Security Administrator role.

  2. Double-click the Add to NIS+ Administrative Group action in the System_Admin folder in the Application Manager.

  3. To enable a new role to administer NIS+, add the role to the NIS+ admin group.

    Use your domain name with the format subdomain.domain.suffix.. For example:


    Group Name: admin
Principal Name: rolename.security.example.com.
    Note -

    Remember to type a period (.) at the end of the the domain name.

  4. Close the Add to NIS+ Group dialog box.

    For example:


    Group "rolename.security.example.com." created.
*** Select Close or Exit from the window menu to close this window ***

To Enable Remote Role Assumption from Untrusted Systems

Untrusted systems are computers running an operating environment other than the Trusted Solaris operating environment.

Do this procedure on the Trusted Solaris machine where you want to be able to log in remotely.

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

  2. Stop the init.wbem program if it is running.


    $ /etc/init.d/init.wbem stop

  3. Use the Admin Editor action to open the /usr/sadm/lib/smc/bin/smcwbemserver file for editing.

  4. Modify the following line to include the -u option


    com.sun.management.viperimpl.server.ViperWbemServer "$@" |&
>
com.sun.management.viperimpl.server.ViperWbemServer -u "$@" |&

    When the -u option is specified, after being authenticated the user is presented with a list of the roles that user can assume that are available on the server. The user can then choose a role, enter the role's password, and select the Login as Role button.

  5. Save and quit the file.

  6. Restart init.wbem.


    $ /etc/init.d/init.wbem start