Go to main content

Securing Users and Processes in Oracle® Solaris 11.3

Exit Print View

Updated: September 2018
 
 

Expanding Users' Rights

Example 12  Creating a Trusted User to Administer DHCP

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 DHCP

In 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 Role

In 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" dnsadmin
Example 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_time
Example 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 Application

Typically, 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> exit
Example 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 secadmin
Example 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.3.

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" username
Example 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.

Copyright © 2002, 2018, Oracle and/or its affiliates. All rights reserved. 
Previous
Next