The tasks and examples in this section add rights to the rights that users receive by default. For information about rights, see About Using Rights to Control Users and Processes.
Assign a role to a trusted user –
Assign a rights profile to a trusted user –
Assign an authenticated rights profile to a trusted user –
Assign an authorization to a trusted user or role –
Assign privileges directly to a user or role –
Caution - Inappropriate use of directly assigned privileges and authorizations can result in unintentional breaches of security. For a discussion, see Security Considerations When Assigning Rights. |
Enable a user to use own password when assuming a role –
Create a rights profile for the administrator of a third-party application – Example 19, Creating a Rights Profile for Administrators of a Third-Party Application
Modify a rights profile – Removing Privileges From Users
Add security attribute to a command in a rights profile –
Enable a user to read a root-owned file –
Enable a user or role to edit a root-owned file – Example 51, Cloning and Removing Selected Rights From a Rights Profile
Assign a rights profile that contains a new authorization – Example 53, Adding Authorizations to a Rights Profile
The security administrator creates a user who can administer DHCP.
# useradd -K profiles="DHCP Management" -s /usr/bin/pfbash -S ldap jdoe
Because the user is assigned the pfbash login shell, the rights in the DHCP Management rights profile are always evaluated, so the DHCP administrative commands succeed.
Example 13 Requiring a User to Type Password Before Administering DHCPIn this example, the security administrator requires jdoe to provide a password before managing DHCP.
# usermod -K auth_profiles="DHCP Management" profiles="Edit Administrative Files" jdoe
When jdoe types a DHCP command, the password prompt appears. After authenticating jdoe, the DHCP command completes. In search order, authenticated rights profiles are processed before regular profiles.
jdoe$ dhcpconfig -R 120.30.33.7,120.30.42.132
Password: xxxxxxxx
/** Command completes **/
Example 14 Assigning Authorizations Directly to a User
In this example, the security administrator creates a local user who can control screen brightness.
# useradd -c "Screened KDoe, local" -s /usr/bin/pfbash \ -K auths=solaris.system.power.brightness kdoe
This authorization is added to the user's existing authorization assignments.
Example 15 Assigning Authorizations to a RoleIn this example, the security administrator creates a role that can change the configuration information for the DNS server service.
# roleadd -c "DNS administrator role" -m -K auths="solaris.smf.manage.bind" dnsadminExample 16 Assigning Privileges Directly to a User
In this example, the security administrator trusts the user kdoe with a very specific privilege that affects system time. To assign the privilege to a role, see Example 10, Assigning Privileges Directly to a Role.
# usermod -K defaultpriv='basic,proc_clock_highres' kdoe
The values for the defaultpriv keyword replace the existing values. Therefore, for the user to retain the basic privileges, the value basic is specified. In the default configuration, all users have basic privileges. For the list of basic privileges, see Listing Privileges.
The user can view the added privilege and its definition.
kdoe$ ppriv -v $$ 1800: pfksh flags = <none> E: file_link_any,…,proc_clock_highres,sys_ib_info I: file_link_any,…,proc_clock_highres,sys_ib_info P: file_link_any,…,proc_clock_highres,sys_ib_info L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,...,win_upgrade_sl $ ppriv -vl proc_clock_highres Allows a process to use high resolution timers.Example 17 Adding to a Role's Basic Privileges
In the following example, the role realtime is directly assigned privileges to handle date and time programs. You assigned the proc_clock_highres to realtime in Example 10, Assigning Privileges Directly to a Role.
# rolemod -K defaultpriv='basic,sys_time' realtime
$ su - realtime Password: xxxxxxxx $ ppriv -v $$ 1600: pfksh flags = <none> E: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time I: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time P: file_link_any,...,proc_clock_highres,sys_ib_info,sys_time L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,...,sys_timeExample 18 Enabling a User to Use Own Password for Role Password
By default, users must type the role's password to assume a role. By requiring a user password, the administrator makes assuming a role in Oracle Solaris similar to assuming a role in a Linux environment.
# rolemod -K roleauth=user auditrev
To assume this role, the assigned users can now use their own passwords, not the password that was created specifically for the role.
If the user has been assigned other roles, the user's password authenticates to those roles, too.
Example 19 Creating a Rights Profile for Administrators of a Third-Party ApplicationTypically, administrators of third-party applications are not given root privileges. If the application uses commands that are not included in an Oracle Solaris rights profile, the root administrator should create a rights profile for the application administrators. This example shows a rights profile for an application whose user management commands rely on Oracle Solaris commands in the User Management and User Security rights profiles. The application also uses the mv, rm, and cp commands in ways that require privilege.
To determine which privileges the cp, mv, and rm commands required, the administrators tested the application as described in How to Determine Which Privileges a Program Requires.
# profiles -p "Application User Management" profiles:Application User Management> set desc="Application User Management Profile" profiles:Application User Management> add profiles="User Management,User Security" profiles:Application User Management> add cmd=/usr/bin/cp profiles:Application User Management:cp> set privs=zone profiles:Application User Management:cp> end profiles:Application User Management> add cmd=/usr/bin/mv profiles:Application User Management:mv> set privs=zone profiles:Application User Management:mv> end profiles:Application User Management> add cmd=/usr/bin/rm profiles:Application User Management:rm> set privs=zone profiles:Application User Management:rm> end profiles:Application User Management> add cmd=/opt/Appl/bin/addusr profiles:Application User Management:addusr> set privs=zone profiles:Application User Management:addusr> end profiles:Application User Management> add cmd=/opt/Appl/bin/addgrp profiles:Application User Management:addgrp> set privs=zone profiles:Application User Management:addgrp> end profiles:Application User Management> commit profiles:Application User Management> info name=Application User Management desc=Application User Management Profile profiles=User Management,User Security cmd=/usr/bin/cp ... profiles:Application Administrator> exitExample 20 Modifying a Rights Profile to Enable a User to Use Own Password for Role Password
# profiles -p "Local System Administrator" profiles:Local System Administrator> set roleauth="user" profiles:Local System Administrator> end profiles:Local System Administrator> exit
When a user who is assigned the Local System Administrator rights profile wants to assume the role, the user is prompted for a password. In the following sequence, the role name is admin:
$ su - admin
Password: xxxxxxxx
$ /** You are now in a profile shell with administrative rights**/
Example 21 Changing the Value of roleauth for a Role in the LDAP
Repository
In this example, the root role enables all users who can assume the role secadmin to use their own password when assuming a role. This ability is granted to these users for all systems that are managed by the LDAP server.
# rolemod -S ldap -K roleauth=user secadminExample 22 Enabling a Trusted User to Read Extended Accounting Files
You can enable a trusted user or group of users to read a file that is owned by the root account. This right can be useful to users who can run an administrative application that includes a root-owned file. This example adds one or more Perl scripts to the Extended Accounting Net Management rights profile.
After assuming the root role, the administrator creates a rights profile that adds the ability to read accounting files whose names begin with network.
The following profile uses extended privilege policy to grant the file_dac_read privilege to a script which can then access /var/adm/exacct/network* files only. This profile adds the existing Extended Accounting Net Management rights profile as a supplementary profile.
# profiles -p "Extended Accounting Perl Scripts" profiles:Extended Accounting Perl Scripts > set desc="Perl Scripts for Extended Accounting" ... Scripts> add profiles="Extended Accounting Net Management" ... Scripts> add cmd=/usr/local/bin/exacctdisp.pl ... Scripts:exacctdisp.pl> set privs={file_dac_read}:/var/adm/exacct/network* ... Scripts:exacctdisp.pl> end ... Scripts> commit ... Scripts> exit
For sample scripts, see Using the Perl Interface to libexacct in Administering Resource Management in Oracle Solaris 11.4.
After reviewing the rights profile entries for errors such as typographical errors, omissions, or repetition, the administrator assigns the Extended Accounting Perl Scripts rights profile to a role or a user.
# profiles -p "Extended Accounting Perl Scripts" info Found profile in files repository. name=Extended Accounting Perl Scripts desc=Perl Scripts for Extended Accounting profiles=Extended Accounting Net Management cmd=/usr/local/bin/exacctdisp.pl privs={file_dac_read}:/var/adm/exacct/network*
# rolemod -K profiles+="Extended Accounting Perl Scripts" rolename # usermod -s /usr/bin/pfbash -K profiles+="Extended Accounting Perl Scripts" usernameExample 23 Enabling a Non-root Account to Read a root-Owned File
In this example, the administrator creates a rights profile that uses extended privilege policy to enable authorized users and roles to read the /var/adm/sulog file that root owns. The administrator adds the commands that the user can use to read the file. Unlisted commands cannot be used, such as the head command.
# profiles -p "Read sulog File" profiles:Read sulog File set desc="Read sulog File" ... File> add profiles="Read Log Files" ... File> add cmd=/usr/bin/cat ... File:cat> set privs={file_dac_read}:/var/adm/sulog ... File:cat> end ... File> add cmd=/usr/bin/less ... File:less> set privs={file_dac_read}:/var/adm/sulog ... File:less> end ... File> add cmd=/usr/bin/more ... File:more> set privs={file_dac_read}:/var/adm/sulog ... File:more> end ... File> add cmd=/usr/bin/page ... File:page> set privs={file_dac_read}:/var/adm/sulog ... File:page> end ... File> add cmd=/usr/bin/tail ... File:tail> set privs={file_dac_read}:/var/adm/sulog ... File:tail> end ... File> add cmd=/usr/bin/view ... File:head> set privs={file_dac_read}:/var/adm/sulog ... File:head> end ... File> commit ... File> exit
The view command enables the user to read a file but not to edit it.