Securing Users and Processes in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

Restricting Users' Rights

The examples in this section limit the rights of regular users, or remove some administrative rights from an administrator. They show how to modify users, roles, and rights profiles. For information about rights, see Chapter 1, About Using Rights to Control Users and Processes.

Example 3-21  Removing Privileges From a User's Limit Set

In the following example, all sessions that originate from jdoe's initial login are prevented from using the sys_linkdir privilege. The user cannot make hard links to directories or unlink directories even after running the su command.

# usermod -K 'limitpriv=all,!sys_linkdir' jdoe
# userattr limitpriv jdoe
all,!sys_linkdir
Example 3-22  Removing a Basic Privilege From a Rights Profile

In the following example, after thorough testing, the security administrator removes another basic privilege from the Sun Ray Users rights profile. When the administrator created the profile in Example 5–6, the administrator removed one privilege from the limit set. This time, the administrator removes two basic privileges. Users who are assigned this profile cannot examine any processes outside their current session, and they cannot add another session.

# profiles -p "Sun Ray Users"
profiles:Sun Ray Users> set defaultpriv="basic,!proc_session,!proc_info"
profiles:Sun Ray Users> end
profiles:Sun Ray Users> exit
Example 3-23  Removing a Basic Privilege From Yourself

In the following example, a regular user modifies .bash_profile to remove the proc_info basic privilege. The output of programs like ps and prstat contain only the user's own processes, which can highlight useful information.

##  .bash_profile
## Remove proc_info privilege from my shell
##
ppriv -s EI-proc_info $$

The ppriv line removes the proc_info privilege from the user's effective and inheritable privilege sets (EI-) in the current shell process ($$).

In the following prstat output, the totals shrink from 74 to three processes:

## With all basic privileges
Total: 74 processes, 527 lwps, load averages: 0.01, 0.00, 0.00

## With proc_info removed from the effective and inheritable set
Total: 3 processes, 3 lwps, load averages: 0.00, 0.00, 0.00
Example 3-24  Modifying a System to Limit the Rights Available to Its Users

In this example, the administrator creates a system that is useful only to administer the network. The administrator removes the Basic Solaris User rights profile and any authorizations from the policy.conf file. The Console User rights profile is not removed. The affected lines in the resulting policy.conf file are the following:

...
##AUTHS_GRANTED=
##AUTH_PROFS_GRANTED=
##PROFS_GRANTED=Basic Solaris User
CONSOLE_USER=Console User
...

Only a user who has been explicitly assigned authorizations, commands, or rights profiles is able to use this system. After login, the authorized user can perform administrative duties. If the authorized user is sitting at the system console, the user has the rights of the Console User.

Example 3-25  Restricting an Administrator to Explicitly Assigned Rights

    You can restrict a role or user to a limited number of administrative actions in two ways.

  • Assign the Stop rights profile as the last profile in the user's list of profiles.

    The Stop rights profile is the simplest way to create a restricted shell. The authorizations and rights profiles in the policy.conf file are not assigned to the user or role.

  • Modify the policy.conf file on a system, and require the role or user to use that system for administrative tasks. See Example 3–24.

The following command limits the auditrev role to performing only audit reviews.

# rolemod -P "Audit Review,Stop" auditrev

Because the auditrev role does not have the Console User rights profile, the auditor cannot shut down the system. Because this role does not have the solaris.device.cdrw authorization, the auditor cannot read from or write to the CD-ROM drive. Because this role does not have the Basic Solaris User rights profile, no commands from that profile can be run in this role. Because the All rights profile is not assigned, the ls command will not run. The role uses the File Browser to select the audit files for review.

For more information, see Order of Search for Assigned Rights and Rights Profiles Reference.

Example 3-26  Preventing Selected Applications From Spawning New Processes

In this example, the administrator creates a rights profile for applications that do not require subprocesses for correct operation. For convenience, the administrator creates a directory to hold these executables. When new applications are added that do not require subprocesses, the executables can be added to this directory. Or, if the executable is required to be in a specific directory, the administrator can link to it from /opt/local/noex/app-executable.

# profiles -p "Prevent App Subprocess"
profiles:Prevent App Subprocess> set desc="Keep apps from execing processes"
profiles:Prevent App Subprocess> add cmd=/opt/local/noex/mkmod
... Subprocess:mkmod> set limitprivs=all,!proc_exec
... Subprocess:mkmod> end
... Subprocess> add cmd=/opt/local/noex/gomap
... Subprocess:gomap> set limitprivs=all,!proc_exec
... Subprocess:gomap> end
... Subprocess> commit
... Subprocess> exit
Example 3-27  Preventing Guests From Spawning Editor Subprocesses

In this example, the administrator prevents users from creating subshells from one or more editors by removing the proc_exec basic privilege from the editor command.

  1. The administrator creates a rights profile that removes proc_exec from the limit privilege set of the vim editor.

    # profiles -p -S ldap "Editor Restrictions"
    profiles:Editor Restrictions> set desc="Site Editor Restrictions"
    ... Restrictions> add cmd=/usr/bin/vim
    ... Restrictions:vim> set limitprivs=all,!proc_exec
    ... Restrictions:vim> end
    ... Restrictions> commit
    ... Restrictions> exit
  2. The administrator adds other popular editors to the rights profile.

    # profiles -p "Editor Restrictions"
    profiles:Editor Restrictions> add cmd=/usr/bin/gedit
    ... Restrictions:gedit> set limitprivs=all,!proc_exec
    ... Restrictions:gedit> end
    ... Restrictions> add cmd=/usr/bin/gconf-editor
    ... Restrictions:gconf-editor> set limitprivs=all,!proc_exec
    ... Restrictions:gconf-editor> end
    ... Restrictions> add cmd=/usr/bin/ed
    ... Restrictions:ed> set limitprivs=all,!proc_exec
    ... Restrictions:ed> end
    ... Restrictions> add cmd=/usr/bin/ex
    ... Restrictions:ex> set limitprivs=all,!proc_exec
    ... Restrictions:ex> end
    ... Restrictions> add cmd=/usr/bin/edit
    ... Restrictions:edit> set limitprivs=all,!proc_exec
    ... Restrictions:edit> end
    ... Restrictions> commit
    ... Restrictions> exit
  3. The administrator reviews the rights profile entries for errors such as typographical errors, omissions, or repetition.

    # profiles -p "Editor Restrictions" info
    Found profile in files repository.
    name=Editor Restrictions
    desc=Site Editor Restrictions
    cmd=/usr/bin/vim
    limitprivs=all,!proc_exec
    ...
  4. The administrator assigns the Editor Restrictions rights profile to the guest user.

    # usermod -K profiles+="Editor Restrictions" guest

    By using profiles+, the administrator adds this rights profile to the account's current rights profiles.

  5. To verify that the editor privileges are limited, the administrator opens the editor and in a separate window, examines the privileges on the editor process.

    # ppriv -S $(pgrep vi)
    2805:   vi .bash_profile
    flags = PRIV_PFEXEC User is running a profile shell
            E: basic,!proc_info proc_info is removed from basic set
            I: basic,!proc_info
            P: basic,!proc_info
            L: all,!proc_exec proc_exec is removed from limit set
Example 3-28  Assigning the Editor Restrictions Rights Profile to All Users

In this example, the administrator adds the Editor Restrictions rights profile to the policy.conf file. The administrator ensures that this file is distributed to all public systems where guests can log in.

# cd /etc/security; cp policy.conf policy.conf.orig
# pfedit /etc/security/policy.conf
...
AUTHS_GRANTED=
AUTH_PROFS_GRANTED=
#PROFS_GRANTED=Basic Solaris User
PROFS_GRANTED=Editor Restrictions,Basic Solaris User

The User Security administrator has assigned a profile shell to every user. For the reasons and the procedure, see Assigning Rights to Users.