This chapter covers tasks that you can use to manage RBAC elements. The following is a list of the task maps in this chapter. To find the tasks for the initial setup of RBAC, see Configuring RBAC (Task Map). For general management of the RBAC elements, see Chapter 19, Role-Based Access Control (Tasks).
The topics that are covered in this chapter include the following:
The preferred method for performing RBAC-related tasks is through the Solaris Management Console. The console tools for managing the RBAC elements are contained in the User Tool Collection.
You can also operate on local files with the Solaris Management Console command-line interface and other command-line interfaces. The Solaris Management Console commands require authentication to connect to the server. As a result, they are not practical in scripts. The other commands require superuser or a role, and cannot be applied to databases in a name service.
Another drawback to using the command line to manage RBAC information is that the edit may not take effect immediately. To enable the edit, you need to stop and restart the name service cache daemon, nscd(1M).
Task |
Description |
For Instructions |
---|---|---|
Learn the concepts behind RBAC, examine your site's security needs, and plan how to integrate RBAC into your operation. | ||
2. Start the User tools from the Solaris Management Console |
All RBAC tasks can be performed by the User tools. | |
3. Install initial users if needed |
One or more existing users must be available for assignment to the first role. | |
4. Install the first role |
The first role, typically Primary Administrator, needs to be installed by root user. | |
5. (Optional) Make root a role |
To eliminate anonymous root login, root can be made a role. |
RBAC can be an integral part of how an organization manages its information resources. Planning requires a thorough knowledge of the RBAC capabilities as well as the security requirements of the organization.
Learn the basic RBAC concepts.
Read Chapter 18, Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX. You should be familiar with the RBAC concepts before you start your implementation. For greater detail, see Chapter 20, Role-Based Access Control (Reference).
Examine your security policy.
Your organization's security policy should detail the potential threats to your system, measure the risk of each threat, and have a strategy to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can install the suggested roles and their configurations as is, you might need to customize your RBAC configuration to adhere to your security policy.
Decide how much RBAC your organization needs.
Depending on your security needs, you can use varying degrees of RBAC, as follows:
No RBAC – You can perform all tasks as root user. In this instance, you log in as yourself and when you select a console tool, you type root as the user.
Root as a Role – This method eliminates anonymous root logins by preventing all users from logging in as root. Instead, they must log in as normal users prior to assuming the root role. See Making Root a Role.
Single Role Only – This method adds the Primary Administrator role only and is similar to the superuser model.
Suggested Roles – Three suggested roles that can be easily configured are available: Primary Administrator, System Administrator, and Operator. These roles are suitable for organizations with administrators at different levels of responsibility whose job capabilities fit the suggested roles.
Custom Roles – You can create your own roles to meet the security requirements of your organization. The new roles can be based on existing or customized rights profiles.
Decide which suggested roles are appropriate for your organization.
Review the capabilities of the suggested roles and default rights profiles. Three rights profiles are available for configuring the suggested roles:
Primary Administrator rights profile – For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.
System Administrator rights profile – For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts, but cannot set passwords or grant rights to other users.
Operator rights profile – For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.
These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.
To further examine rights profiles, use the Rights tool to display the contents. You can also refer to Contents of Rights Profiles for a summary of some typical rights profiles. With the console tools, you can customize the roles and rights profiles that are provided to meet the needs of your organization.
Decide if any additional roles or rights profiles are appropriate for your organization.
Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC.
Determine which commands are needed for the new task.
Decide which rights profile is appropriate for this task.
Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.
Determine which role is appropriate for this rights profile.
Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the other rights profiles are appropriate for users who are assigned to this role.
Decide which users should be assigned to the available roles.
According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. Keeping users away from tasks that they do not need to use reduces potential problems.
To install the initial users to their assigned roles, you first log in as yourself. When you authenticate yourself to the Solaris Management Console, specify root user.
Log in as a normal user and start the Solaris Management Console.
% whoami johnDoe % /usr/sadm/bin/smc& |
Navigate to the User Tool Collection and click the icon, as follows:
Find the icon that is labeled This Computer under Management Tools in the navigation pane.
Click the turner icon to its left.
The turner icon is shaped like a lever. When the lever is horizontal, the contents of the folder are hidden. When the lever is vertical, the contents are displayed. Clicking the turner icon toggles the folder between the hidden and displayed states.
Click the turner icon next to the System Configuration folder to display its contents.
Click the User icon to open the User Tool Collection.
The user login dialog box is displayed.
Type root and the root password in the Login: User Name dialog box. Click OK.
Generally, you should type your user name here and then assume a role. However, for the first time, you need to be root user because no roles exist yet. This step opens the User Tool Collection (see the following figure).
If all users who are assigned to roles are already installed on this system, you can skip this task and go to Setting Up Initial Roles.
Click the User Accounts tool icon in either the navigation pane or the view pane of the User Tool Collection.
The User Accounts tool is started. The Action menu now provides options for this tool.
Select Add User->With Wizard from the Action menu.
This step starts the Add User wizard, a series of dialog boxes that request information that is necessary for configuring a user. Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role.
The following figure shows the first dialog box, Step 1: Enter a user name.
Type the name of the first user and the other identification information.
In the Step 2: Enter a User Identification Number dialog box, type the UID.
This entry should match the existing UID for the user.
In the Step 3: Enter the User's Password dialog box, indicate whether you or the user will be setting the password.
If you are setting up this account for yourself, click the second option. Then, type and confirm your password.
In the Step 4: Select the User's Primary Group dialog box, select the appropriate group.
In the Step 5: Create the User's Home Directory dialog box, specify the path for the home directory.
In the Step 6: Specify the Mail Server dialog box, check out the default mail server and mailbox.
You can change these settings later in the User Properties dialog box.
Check the information in the Review dialog box. Click Finish to save, or click Back to reenter information.
If you discover missing or incorrect information, click the Back button repeatedly to display the dialog box where the incorrect information is displayed. Then, click Next repeatedly to return to the Review dialog box.
The first role to create is the role that is responsible for managing users and roles, typically the Primary Administrator. First, you should install the users and the roles on your local host. After you have set up a toolbox for the name service scope, you need to create the same users and roles in the name service. See “Using the Solaris Management Tools in a Name Service Environment (Task Map)” in System Administration Guide: Basic Administration. After the first role is established and assigned to you, then you can run the console tools by assuming a role instead of becoming root.
To install the first role, you should log in as yourself. When you authenticate yourself to the Solaris Management Console, specify root user. You should first install the role on your local host. After the first role is established and assigned to you, you can run the console tools by assuming a role instead of as root user.
Type root and the root password in the Login: User Name dialog box. Click OK.
Click the Administrative Roles icon in either the navigation pane or the view pane of the User Tool Collection.
The Administrative Roles tool is started. The Action menu now provides options for this tool.
Select Add Administrative Role from the Action menu.
This step starts the Add Administrative Role wizard, a series of dialog boxes that request information that is necessary for configuring a role. Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role.
The following figure shows the first dialog box, Step 1: Enter a Role Name.
Type primaryadmin, or whatever role name you are using, and the other identification information.
If you select the role mailing list option, you can create an alias of users who can assume this role.
In the Step 2: Enter a Role Password dialog box, type the password for the new role in the Role Password field and again in the Confirm Password field.
Confirmation helps prevent a misspelled password from being saved.
In the Step 3: Enter Role Rights dialog box, select the Primary Administrator rights profile.
Double-click the Primary Administrator rights profile in the Available Rights column (on the left). The rights profiles in the Granted Rights column (on the right) are the rights profiles that are assigned to this role. In this instance, only the Primary Administrator rights profile is needed.
In the Step 4: Select a Home Directory dialog box, specify the server and path for the home directory.
In the Step 5: Assign Users to This Role dialog box, type the login names for any users to be assigned to the Primary Administrator role.
Any users that you add must be defined in the same name service scope in which you are working. If you selected the role mailing list option in the Step 1: Enter a Role Name dialog box, these users will receive email that is addressed to the Primary Administrator role.
Check the information in the Review dialog box. Click Finish to save, or click Back to reenter information.
If you discover missing or incorrect information, click the Back button repeatedly to display the dialog box where the incorrect information is displayed. Then, click Next repeatedly to return to the Review dialog box.
Open a terminal window, become root, and start and stop the name service cache daemon.
The new role does not take effect until the name service cache daemon is restarted. After becoming root, type as follows:
# /etc/init.d/nscd stop # /etc/init.d/nscd start |
This procedure shows how to change root from a user to a role within a local scope. Changing root to a role prevents users from logging in to that server directly as root. Users must first log in as themselves so their UIDs are available for auditing.
If you make root a role without assigning it to a valid user or without a currently existing role equivalent to root, no one can become root.
Log in to the target server.
Become superuser.
Edit the /etc/user_attr file.
Here is an excerpt from a typical user_attr file.
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All johnDoe::::type=normal |
Check that your name is in the file.
Add root to the roles that are assigned to your record.
Assign the root role to any applicable users. If you intend to use primaryadmin as your most powerful role, you do not have to assign root to any users.
johnDoe::::type=normal;roles=root |
Go to the root record in the file and change type=normal to type=root.
root::::type=role;auths=solaris.*,solaris.grant;profiles=All |
Save the file.
The following task map shows where to obtain information for performing specific RBAC tasks.
Task |
Description |
For Instructions |
---|---|---|
Use privileged applications |
To run applications that can affect security or system operations requires becoming superuser or assuming a role. | |
Create roles |
To add new roles, that is, special identities for running privileged applications. | |
Change role properties |
To change the properties of a role, that is, the assigned users, rights profiles, and authorizations that are assigned to a role. | |
Create or change rights profiles |
To add or change a rights profile, including the assignment of authorizations, commands with security attributes, and supplementary rights profiles. |
How to Create or Change a Rights Profile by Using the Rights Tool |
Change a user's RBAC properties |
To change the roles, rights profiles, or authorizations that are assigned to a user. |
How to Modify a User's RBAC Properties by Using the User Accounts Tool |
Secure legacy applications |
To turn on the set ID permissions for legacy applications. Scripts can contain commands with set IDs. Legacy applications can check for authorizations, if appropriate. |
How to Add Security Attributes to a Legacy Application |
These procedures manage the elements that are used in role-based access control (RBAC). For user management procedures, refer to “Managing User Accounts and Groups (Tasks)” in System Administration Guide: Basic Administration.
To run privileged applications, you must first become superuser or assume a role. Although running privileged applications as a normal user is possible, it is discouraged to avoid errors that are caused by users who inadvertently exercise this privilege.
Use the su command as follows:
% su my-role Password: my-role-password # |
Typing su by itself lets you become superuser. Typing su with a role name lets you assume that role (if it has been assigned to you). You must supply the appropriate password. Assuming a role switches the command line to the profile shell for that role. The profile shell has been modified to run commands with the security attributes that are assigned in the role's rights profiles.
Type a command in the shell.
The command is executed with any assigned security attributes and setuid or setgid permissions.
Start the Solaris Management Console.
Use one of the following methods:
Type smc at the command line.
Click the Solaris Management Console icon in the Tools subpanel.
Double-click the Solaris Management Console icon in the Application Manager.
All Solaris Management Console tools have extensive context-sensitive help that document each field. In addition, you can access various help topics from the Help menu. Note that it does not matter whether you are logged in as root or as a normal user when you start the console.
Select the toolbox for your task.
Navigate to the toolbox that contains the tool or collection in the appropriate scope and click the icon. The scopes are files (local), NIS, NIS+, and LDAP. If the appropriate toolbox is not displayed in the navigation pane, choose Open Toolbox from the Console menu and load the relevant toolbox.
Select the tool.
Navigate to the tool or collection to be used and click the icon. The tools for managing the RBAC elements are all part of the User Tool Collection.
Authenticate yourself in the Login: User Name dialog box.
Your choices are the following:
Type your user name and password to assume a role or to operate as a normal user.
Type root and the root password to operate as superuser.
Note that if you have not yet set up any roles or if the roles that are set up cannot perform the appropriate tasks, you need to log in as root. If you authenticate yourself as root (or as a user with no roles assigned), the tools are loaded into the console and you can proceed to Step 6.
Authenticate yourself in the Login: Role dialog box.
The Role option menu in the dialog box displays the roles that are assigned to you. Choose a role and type the role password. If you are to operate as a normal user, type your user name and password.
Navigate to the tool to be run and click the icon.
To create a role, you must either assume a role that has the Primary Administrator rights profile assigned to it or run as root user. See RBAC Roles and Configuring Recommended Roles to learn more about roles.
Start the Administrative Roles tool.
Run the Administrative Roles tool, start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Administrative Roles icon.
Start the Add Administrative Role wizard.
Select Add Administrative Role from the Action menu to start the Add Administrative Role wizard for configuring roles.
Fill in the fields in the series of dialog boxes. Click Finish when done.
Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role. Table 19–1 summarizes the dialog boxes.
Open a terminal window, become root, and start and stop the name service cache daemon.
The new role does not take effect until the name service cache daemon is restarted. After becoming root, type as follows:
# /etc/init.d/nscd stop # /etc/init.d/nscd start |
Dialog Box |
Fields |
Field Description |
---|---|---|
Step 1: Enter a role name |
Role Name |
Short name of the role. |
|
Full Name |
Long version of the name. |
|
Description |
Description of the role. |
|
Role ID Number |
UID for the role, automatically incremented. |
|
Role Shell |
The profile shells that are available to roles: Administrator's C, Administrator's Bourne, or Administrator's Korn shell. |
|
Create a role mailing list |
Makes a mailing list for users who are assigned to this role. |
Step 2: Enter a role password |
Role Password |
******** |
|
Confirm Password |
******** |
Step 3: Select role rights |
Available Rights / Granted Rights |
Assigns or removes a role's rights profiles. Note that the system does not prevent you from typing multiple occurrences of the same command. The attributes that are assigned to the first occurrence of a command in a rights profile have precedence and all subsequent occurrences are ignored. Use the Up and Down arrows to change the order. |
Step 4: Select a home directory |
Server |
Server for the home directory. |
|
Path |
Home directory path. |
Step 5: Assign users to this role |
Add |
Adds users who can assume this role. Must be in the same scope. |
|
Delete |
Deletes users who are assigned to this role. |
Become superuser or assume a role that is capable of creating other roles.
Select a method for creating a role:
For roles in the local scope, use the roleadd command to specify a new local role and its attributes.
Alternatively, for roles in the local scope, edit the user_attr file to add a user with type=role.
This method is recommended for emergencies only, as it is easy to make mistakes while you are typing.
For roles in a name service, use the smrole command to specify the new role and its attributes.
This command requires authentication by superuser or a role that is capable of creating other roles. You can apply the smrole to all name services. This command runs as a client of the Solaris Management Console server.
Start and stop the name service cache daemon.
New roles do not take effect until the name service cache daemon is restarted. As root, type as follows:
# /etc/init.d/nscd stop # /etc/init.d/nscd start |
The following sequence demonstrates how a role is created with the smrole command. In this example, a new version of the Operator role is created that has assigned to it the standard Operator rights profile and the Media Restore rights profile.
% su primaryadmin # /usr/sadm/bin/smrole add -H myHost -- -c "Custom Operator" -n oper2 -a johnDoe \ -d /export/home/oper2 -F "Backup/Restore Operator" -p "Operator" -p "Media Restore" Authenticating as user: primaryadmin Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password :: <type primaryadmin password> Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost Login to myHost as user primaryadmin was successful. Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful. Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password ::<type oper2 password> # /etc/init.d/nscd stop # /etc/init.d/nscd start |
To view the newly created role (and any other roles), use smrole with the list subcommand, as follows:
# /usr/sadm/bin/smrole list -- Authenticating as user: primaryadmin Type /? for help, pressing <enter> accepts the default denoted by [ ] Please enter a string value for: password :: <type primaryadmin password> Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost Login to myHost as user primaryadmin was successful. Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful. root 0 Super-User primaryadmin 100 Most powerful role sysadmin 101 Performs non-security admin tasks oper2 102 Backup/Restore Operator |
To change a role, you must either assume a role that has the Primary Administrator rights profile assigned to it, or run the User Tool Collection as root user if roles have not yet been set up.
Start the Administrative Roles tool.
To run the Administrative Roles tool, you need to start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Administrative Roles icon.
After the Administrative Roles tool starts, the icons for the existing roles are displayed in the view pane.
Click the role to be changed and select the appropriate item from the Action menu, as follows:
To change users who are assigned to a role, select Assign Administrative Role.
The Assign Administrative Role dialog box is displayed. The Assign Administrative Role dialog box is a modified version of the Role Properties dialog box and has a Users tab only. Use the Add field to assign a user in the current scope to this role. Use the Delete field to remove a user's role assignment. Click OK to save.
To change rights that are assigned to a role, select Assign Rights to Role.
The Assign Rights to Role dialog box is displayed. The Assign Rights to Role dialog box is a modified version of the Role Properties dialog box and has a Rights tab only. Use the Available Rights and Granted Rights columns to add or remove rights profiles for the selected role. Click OK to save.
To change any of the role's properties, select Properties (or simply double-click the role icon).
The Role Properties dialog box is displayed, which provides access to all role properties (see the following figure and table). Use the tabs to navigate to any information to be changed, make your changes, and click OK to save.
Tab Description |
|
---|---|
General |
Specifies the role identification information and the default login shell. |
Password |
Specifies the role password. |
Users |
Specifies the users who are assigned to the role. |
Group |
Sets the role's primary groups and secondary groups for the purpose of accessing and creating files and directories. |
Home Directory |
Specifies the role's home directory, home directory server, automounting, and directory access. |
Rights |
Allows rights profiles to be assigned to the role. The precedence of the assigned rights profiles can be changed here. |
Become superuser or assume a role that is capable of changing other roles.
Use the command that is appropriate for the task:
Use the rolemod command to modify the attributes of a role that are defined locally.
Use the roledel command to delete a role that is defined locally.
Edit the user_attr file to change the authorizations or rights profiles that are assigned to a local role.
This method is recommended for emergencies only, as it is easy to make a mistake while you are typing.
Use the smrole command to modify the attributes of a role in a name service.
This command requires authentication as superuser or as a role that is capable of changing other roles. The smrole command runs as a client of the Solaris Management Console server.
To create or change a rights profile, you must either assume a role that has the Primary Administrator rights profile assigned to it, or run the User Tool Collection as root user if roles have not yet been set up. To learn more about rights profiles, see RBAC Roles and Configuring Recommended Roles.
Start the Rights tool.
To run the Rights tool, you need to start the Solaris Management Console as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Rights icon.
After the Rights tool starts, the icons for the existing rights profiles are displayed in the view pane.
Take the appropriate action for creating or changing a rights profile:
To create a new rights profile, select Add Right from the Action menu.
To change an existing rights profile, click the rights profile icon and select Properties from the Action menu (or simply double-click the rights profile icon).
Both actions display a version of the Rights Properties dialog box. The Add Right version (which follows) has a writable Name field. The standard Rights Properties dialog box has a read-only Name field because the name of a rights profile cannot be changed after it has been defined.
Type the new information. Click OK to save the rights profile.
The following table lists the tabs and fields in the Right Properties dialog box.
Tab |
Field |
Field Description |
---|---|---|
General |
Name |
Name of the new rights profile. |
|
Description |
Description of the new rights profile. |
|
Help File Name |
Name of the HTML help file for the new rights profile. |
Commands |
Add Directory |
Opens a dialog box for adding directories that are not already in the Commands Denied or Commands Permitted columns. |
|
Commands Denied / Commands Permitted |
Assigns or removes a rights profile's commands. |
|
Opens a dialog box for assigning or removing a command's security attributes, that is, real or effective UIDs or GIDs (see Figure 19–6). Note – Assigning effective IDs is preferred over assigning real IDs. Use real IDs only when they are required by the command, such as pkgadd. |
|
|
Find (command) |
Searches the two command lists for the specified string. |
Authorizations |
Authorizations Excluded / Authorizations Included |
Assigns or removes a rights profile's authorizations. |
Supplementary Rights |
Rights Excluded / Rights Included |
Assigns or removes a rights profile's supplementary rights profiles. |
The data in the following table shows sample data for a hypothetical rights profile that is called “Restart” could be created. The example rights profile, Restart, has the commands in the subdirectory /etc/init.d assigned to it. These commands have an effective UID of 0. This rights profile would be useful for administrators who are permitted to stop and start the daemons in /etc/init.d.
Tab |
Field |
Example |
---|---|---|
General |
Name |
Restart |
|
Description |
For starting and stopping daemons in /etc/init.d |
|
Help File Name |
Restart.html |
Commands |
Add Directory |
Click Add Directory, type /etc/init.d in the dialog box, and click OK. |
|
Commands Denied / Commands Permitted |
Select /etc/init.d and click Add to move the command to the Commands Permitted column. |
|
Set Security Attributes |
Select /etc/init.d, click Set Security Attributes, and set Effective UID = root (see Figure 19–6). |
|
Find (command) |
|
Authorizations |
Authorizations Excluded / Authorizations Included |
|
Supplementary Rights |
Rights Excluded / Rights Included |
|
Become superuser or assume a role with the PrimaryAdministration rights profile.
Use the subcommand of smprofile that is appropriate for the task.
This command requires authentication. You can apply the command to all name services. smprofile runs as a client of the Solaris Management Console server.
To add a new profile, use smprofile with the add subcommand.
To change an existing profile, use smprofile with the modify subcommand.
To modify a user's properties, you must either be running the User Tool Collection as root user or assume a role that has the Primary Administrator rights profile assigned to it.
Start the User Accounts tool.
To run the User Accounts tool, you need to start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the User Accounts icon.
After the User Accounts tool starts, the icons for the existing user accounts are displayed in the view pane.
Click the user account icon to be changed and select Properties from the Action menu (or simply double-click the user account icon).
Click the appropriate tab in the dialog box for the property to be changed, as follows:
To change the roles that are assigned to the user, click the Roles tab and move the role assignment to be changed to the appropriate column: Available Roles or Assigned Roles.
To change the rights profiles that are assigned to the user, click the Rights tab and move it to the appropriate column: Available Rights or Assigned Rights.
It is not good practice to assign rights profiles directly to users. The preferred approach is to force users to assume roles in order to perform privileged applications. This strategy avoids the possibility of normal users abusing privileges.
Become superuser or assume a role that can modify user files.
Use the appropriate command:
To change the authorizations, roles, or rights profiles that are assigned to a user who is defined in the local scope, use the usermod command.
Alternatively, to change the authorizations, roles, or rights profiles that are assigned to a user who is defined in the local scope, edit the user_attr file.
This method is recommended for emergencies only, as it is easy to make a mistake while you are typing.
To change the authorizations, roles, or rights profiles that are assigned to a user who is defined in a name service, use the smuser command.
This command requires authentication as superuser or as a role that is capable of changing user files. You can apply smuser to all name services. smuser runs as a client of the Solaris Management Console server.
This section discusses how to make legacy applications more secure. To add legacy applications to the Solaris Management Console, see “Adding Tools to the Solaris Management Console” in System Administration Guide: Basic Administration.
You add security attributes to a legacy application in the same way as you would for any command. You need to add the command (or its directory) to the Commands Denied column in the Commands tab of the Rights property dialog box. Then move the command to the Commands Permitted column.
If a command in a script needs to have the setUID bit set to run, simply add the security attributes to that command in the same rights profile. See How to Create or Change a Rights Profile by Using the Rights Tool.
To have a script for authorizations, you need to add a test that is based on the auths command (see the auths(1) man page). For example, the following line would test if the user has the authorization entered as the $1 argument:
if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then echo Auth granted else echo Auth denied fi |
To be more complete, the test should include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.admin.usermgr.write authorization, you need to check for the strings: solaris.admin.usermgr.write, solaris.admin.usermgr.*, solaris.admin.*, and solaris.*.
If you are writing a program, use the getauthattr()function to test for the authorization.