Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Security Services Oracle Solaris 11 Express 11/10 |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Using the Basic Audit Reporting Tool (Tasks)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Managing and Using Privileges (Task Map)
Managing Privileges (Task Map)
How to Determine the Privileges on a Process
How to Determine Which Privileges a Program Requires
How to Add Privileges to a Command
How to Assign Privileges to a User or Role
Determining Your Privileges (Task Map)
Determining Your Assigned Privileges
How to Determine the Privileges That You Have Been Directly Assigned
How to Determine the Privileged Commands That You Can Run
How to Determine the Privileged Commands That a Role Can Run
Part IV Oracle Solaris Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Solaris Secure Shell (Tasks)
20. Solaris Secure Shell (Reference)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
The most secure way to manage privileges for users and roles is to confine use of privilege to commands in a rights profile. The rights profile is then included in a role. The role is assigned to a user. When the user assumes the assigned role, the privileged commands are available to be run in a profile shell. The following procedures show how to assign privileges, remove privileges, and debug privilege use.
This procedure shows how to determine which privileges are available to your processes. The listing does not include privileges that have been assigned to particular commands.
% ppriv pid $ ppriv -v pid
Is the process number. Use a double dollar sign ($$) to pass the process number of the parent shell to the command.
Provides a verbose listing of the privilege names.
Example 11-1 Determining the Privileges in Your Current Shell
In the following example, the privileges in the parent process of the user's shell process are listed. In the second example, the full names of the privileges are listed. The single letters in the output refer to the following privilege sets:
Is the effective privilege set.
Is the inheritable privilege set.
Is the permitted privilege set.
Is the limit privilege set.
% ppriv $$ 1200: -csh flags = <none> E: basic I: basic P: basic L: all % ppriv -v $$ 1200: -csh flags = <none> E: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session I: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session P: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time
Example 11-2 Determining the Privileges of a Role That You Can Assume
Roles use an administrative shell, or profile shell. You must assume a role and use the role's shell to list the privileges that have been directly assigned to the role. In the following example, the role sysadmin has no directly assigned privileges.
% su - sysadmin Password: <Type sysadmin password> $ /usr/ucb/whoami sysadmin $ ppriv -v $$ 1400: pfksh flags = <none> E: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session I: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session P: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time
This procedure determines which privileges a command or process requires to succeed.
The command or process must have failed for this procedure to work.
% ppriv -eD touch /etc/acct/yearly touch[5245]: missing privilege "file_dac_write" (euid = 130, syscall = 224) needed at zfs_zaccess+0x258 touch: cannot create /etc/acct/yearly: Permission denied
% grep 224 /etc/name_to_sysnum creat64 224
Example 11-3 Using the truss Command to Examine Privilege Use
The truss command can debug privilege use in a regular shell. For example, the following command debugs the failing touch process:
% truss -t creat touch /etc/acct/yearly creat64("/etc/acct/yearly", 0666) Err#13 EACCES [file_dac_write] touch: /etc/acct/yearly cannot create
The extended /proc interfaces report the missing privilege after the error code in truss output.
Example 11-4 Using the ppriv Command to Examine Privilege Use in a Profile Shell
The ppriv command can debug privilege use in a profile shell. If you assign a rights profile to a user, and the rights profile includes commands with privileges, the commands must be typed in a profile shell. When the privileged commands are typed in a regular shell, the commands do not execute with privilege.
In this example, the jdoe user can assume the role objadmin. The objadmin role includes the Object Access Management rights profile. This rights profile allows the objadmin role to change permissions on files that objadmin does not own.
In the following excerpt, jdoe fails to change the permissions on the useful.script file:
jdoe% ls -l useful.script -rw-r--r-- 1 aloe staff 2303 Apr 10 10:10 useful.script jdoe% chown objadmin useful.script chown: useful.script: Not owner jdoe% ppriv -eD chown objadmin useful.script chown[11444]: missing privilege "file_chown" (euid = 130, syscall = 16) needed at zfs_zaccess+0x258 chown: useful.script: Not owner
When jdoe assumes the objadmin role, the permissions on the file are changed:
jdoe% su - objadmin Password: <Type objadmin password> $ ls -l useful.script -rw-r--r-- 1 aloe staff 2303 Apr 10 10:10 useful.script $ chown objadmin useful.script $ ls -l useful.script -rw-r--r-- 1 objadmin staff 2303 Apr 10 10:10 useful.script $ chgrp admin useful.script $ ls -l objadmin.script -rw-r--r-- 1 objadmin admin 2303 Apr 10 10:11 useful.script
Example 11-5 Changing a File Owned by the root User
This example illustrates the protections against privilege escalation. For a discussion, see Prevention of Privilege Escalation. The file is owned by the root user. The less powerful role, objadmin role needs all privileges to change the file's ownership, so the operation fails.
jdoe% su - objadmin Password: <Type objadmin password> $ cd /etc; ls -l system -rw-r--r-- 1 root sys 1883 Oct 10 10:20 system $ chown objadmin system chown: system: Not owner $ ppriv -eD chown objadmin system chown[11481]: missing privilege "ALL" (euid = 101, syscall = 16) needed at zfs_zaccess+0x258 chown: system: Not owner
You add privileges to a command when you are adding the command to a rights profile. The privileges enable the role that includes the rights profile to run the administrative command, while not gaining any other superuser capabilities.
The command or program must be privilege-aware. For a fuller discussion, see How Processes Get Privileges.
For more information, see How to Obtain Administrative Rights.
You might trust some users with a particular privilege all the time. Very specific privileges that affect a small part of the system are good candidates for assigning to a user. For a discussion of the implications of directly assigned privileges, see Security Considerations When Directly Assigning Security Attributes.
The following procedure enables user jdoe to use high resolution timers.
You must be assigned the User Security rights profile.
For more information, see How to Obtain Administrative Rights.
$ usermod -K defaultpriv=basic,proc_clock_highres jdoe
The values for the defaultpriv keyword replace the existing values. Therefore, for the user to retain the basic privileges, the value basic must be specified. In the default configuration, all users have basic privileges.
$ grep jdoe /etc/user_attr jdoe::::type=normal;defaultpriv=basic,proc_clock_highres
You can limit the privileges that are available to a user or role by reducing the basic set, or by reducing the limit set. You must have good reason to limit the user's privileges in this way, because such limitations can have unintended side effects.
Caution - You must thoroughly test any user's capabilities where the basic set or the limit set has been modified for a user.
|
For the procedure, see How to Determine the Privileges on a Process.
$ usermod -K defaultpriv=basic,!priv-name username
By removing the proc_session privilege, you prevent the user from examining any processes outside the user's current session. By removing the file_link_any privilege, you prevent the user from making hard links to files that are not owned by the user.
Caution - Do not remove the proc_fork or the proc_exec privilege. Without these privileges, the user cannot use the system. In fact, these two privileges are only reasonably removed from daemons that do not fork() or exec() other processes. |
$ usermod -K limitpriv=all,!priv-name username
Log in as username and try to perform the tasks that username must perform on the system.
Example 11-6 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. That is, the user cannot make hard links to directories, nor can the user unlink directories, even after the user runs the su command.
$ usermod -K limitpriv=all,!sys_linkdir jdoe $ grep jdoe /etc/user_attr jdoe::::type=normal;defaultpriv=basic;limitpriv=all,!sys_linkdir
Example 11-7 Removing Privileges From a User's Basic Set
In the following example, all sessions that originate from jdoe's initial login are prevented from using the proc_session privilege. That is, the user cannot examine any processes outside the user's session, even after the user runs the su command. This removal is useful for Sun Ray clients. The users cannot view other users' processes.
$ usermod -K defaultpriv=basic,!proc_session jdoe
$ grep jdoe /etc/user_attr jdoe::::type=normal;defaultpriv=basic,!proc_session;limitpriv=all
Note - When you create a shell script that runs commands with inherited privileges, the appropriate rights profile must contain the commands with privileges assigned to them.
#!/bin/pfsh # Copyright (c) 2009 by Sun Microsystems, Inc.
% ppriv -eD script-full-path
For more information, see How to Obtain Administrative Rights.
For the steps, see How to Create or Change a Rights Profile.
For more information, see Example 9-17.
The rights profile name connects the commands in the exec_attr entry to the rights profile definition in the prof_attr file.
To execute the profile, the user assumes the role and runs the script in the role's profile shell.
To add the rights profile to a role, see How to Change the Properties of a Role.
To assign the role to a user, see Example 9-16.