Introduction
Roles are implemented in Oracle Solaris as shared accounts, which require authentication prior to use. When an
authorized user successfully assumes a role, the actions of the role are attributed to the user in the audit
trail, but the user's authorizations, rights profiles, and home directory are replaced by those of the role.
Alternatively, administrative rights profiles can be assigned directly to users, so that they don't need to
assume roles. Such users can enable profile-based execution by starting a profile shell, e.g pfbash, which
sets the process flag PRIV_PFEXEC. While this is more convenient, it presents the risk that users may not
realize they are using their rights, or that someone else could abuse those rights if they leave their terminal
unlocked.
Oracle Solaris 11.2 has a new feature, authenticated rights profiles, which mitigates that risk, while maintaining the
convenience of profile-based execution. A new keyword, auth_profiles, can be used to specify which of a
user's rights profiles require re-authentication prior to use. Unlike role assumption which is initiated explicitly,
the re-authentication challenge for these authenticated profiles occurs automatically, via a new PAM service
called pfexec. For example, if a user is running with profile-based execution enabled and attempts to
execute a command matching one of her authenticated rights profiles, a re-authentication challenge is
issued, which explains why privilege escalation is required. The user then has the option to re-authenticate
and run the command with the attributes specified in the profile, or to bypass the challenge, and run the
command with default attributes
If the user is successfully authenticated the new process associated with the command is marked with the
flag, PRIV_PFEXEC_AUTH, so that any rights specified in the user's set of authenticated rights profiles are
effective for this process and its children. In addition, after a successful re-authentication, a grace period,
defaulting to 5 minutes, enables automatic re-authentication for any process associated within the terminal
session, unless overridden by other time-based restrictions.
For desktop programs, which are not associated with a terminal, re-authentication challenges are issued via
a desktop dialog using the X11 $DISPLAY variable. In this case, the grace period for re-authentication is
associated with the $DISPLAY variable, so that it applies to applications started via desktop icons.
Although the authorizations that are specified via normal profiles are implicitly effective, those in
authenticated rights profiles are ignored unless the PRIV_PFEXEC_AUTH flag is set. However, a
re-authentication challenge may be issued by a privileged process if a required authorization is assigned via
an authenticated rights profile. In this case the explanation for the challenge identifies the relevant
authorization. Since the challenge uses the same pfexec PAM service, it is subject to the same grace period
policy as command-based challenges.
Providing Feedback about the State of Profile-based Execution
As an aid to the user, the state of profile-based execution can be conveyed via the shell prompt. In the
following example the last character of the prompt reflects the current status. An appended $ indicates
normal execution, % indicates profile-based execution, and # indicates that authenticated profiles are
effective. This fragment could be inserted into the user's ~/.bashrc file. Alternatively, the prompts could be
color-coded.
#!/bin/bash
if [ -z "$LOGIN_SHELL" ]; then
x=$(ppriv $$|grep flags|grep -w PRIV_PFEXEC)
if [ $? = 1 ]; then
PS1="\u@\h[\#]\$ "
else
echo "$x"|grep -qw PRIV_PFEXEC_AUTH
if [ $? = 0 ]; then
PS1="\u@\h[\#]# "
else
PS1="\u@\h[\#]% "
fi
fi
fi
Assigning Authenticated Rights Profiles
The following example demonstrates how to create a customized rights profile and assign it to a user. The
Test profile grants the right to run the Print Manager as root. The program /usr/bin/xterm is also added
since it will be used in a later exercise.
gfaden@solaris:~$ su -
Password:
root@solaris# profiles -p Test
profiles:Test> set desc="Test Profile"
profiles:Test> add cmd=/usr/bin/system-config-printer
profiles:Test:system-config-printer> set uid=root
profiles:Test:system-config-printer> end
profiles:Test> add cmd=/usr/bin/xterm
profiles:Test:xterm> end
profiles:Test> exit
Next, the test account is created and assigned the Test profile:
root@solaris# useradd -m -K auth_profiles=Test test
root@solaris# passwd test
New Password:
Re-enter new Password:
The previous shell script is copied into ~test/.bashrc, and the ownership it set to test. The Administrator
Message Edit profile is also added since it will be used later.
root@solaris# usermod -K auth_profiles+="Administrator Message Edit" test"
The previous steps can also done graphically by selecting System->Administration->User Manager.
When the dialog appears, click on the lock icon in upper right corner and assume the root role. After
creating the test account, use the Advanced Settings to assign the authenticated profiles using the
following dialog:
These assignments can be verified using the -x option which shows the profiles and authorizations that
require authentication. Without the -x option, only regular profiles and authorizations are shown:
gfaden@solaris:~$ profiles test
test:
Basic Solaris User
All
Basic Solaris User
All
gfaden@solaris:~$ profiles -lx test
test:
Administrator Message Edit
Administrator Message Edit
Test
auths=solaris.admin.edit/etc/issue,solaris.admin.edit/etc/motd
/usr/bin/xterm
/usr/bin/system-config-printer
uid=0
Re-authentication Challenges on the Desktop
Authenticated rights profiles apply to both GUIs and command line programs. The re-authentication
functionality can be shown by logging in to the GNOME desktop as the test user. After selecting
System->Administration->Print Manager, the following dialog appears:
If the challenge is accepted by entering test's password, then the Print Manager runs as root. This allows creating a New printer, using this dialog:
However, if the challenge is Canceled, the following dialog appears:
If Yes is selected, the Print Manager runs as the test user. In this case, selecting New results in yet another
authentication dialog.
This dialog is requesting the user to assume the root role. By default, this requires the root password.
However, the following command changes the policy to require the user's password:
root@solaris# rolemod -K roleauth=user root
Access Time Restrictions
The re-authentication grace period can be changed on a per-user basis by creating a customized PAM
configuration file. The following procedure sets a 1 minute grace period for the test user:
root@solaris# cd /etc/security/pam_policy
root@solaris# cp unix unix-test
root@solaris# vi unix-test
The existing entry assumes the default value specified in the pam_tty_tickets(4) man page.
pfexec auth sufficient pam_tty_tickets.so.1
An explicit timeout value can be appended as follows:
pfexec auth sufficient pam_tty_tickets.so.1 timeout=1
After updating the unix-test file, the policy can be applied to the test user as follows:
root@solaris# usermod -K pam_policy=unix-test test
It is also possible to restrict the days and times when re-authentication is permitted using the access_times
property. The following example specifies that the test user can only re-authenticate on weekdays between
8 am and 5 pm:
root@solaris# usermod -K access_times={pfexec}:Wk0800-1700 test
If the user selects the Print Manager after 5 pm, re-authentication will fail, and the following dialog will be displayed:
Re-athenticating to Edit a Restricted File
A Terminal window is used to start pfedit, which is an authorization-aware wrapper for editing restricted
files. The profile shell pfbash is used to enable profile-based execution. This state is reflected in the new
shell prompt suffix. The following example shows the re-authentication challenge that is issued when
attempting to edit /etc/motd:
test@solaris[20]$ pfbash
test@solaris[21]% pfedit /etc/motd
Reauthentication by test is required to use authorization:
solaris.admin.edit/etc/motd
Password:
After successfully authenticating, the editor specified by $EDITOR is launched using a temporary file. When
that editor exits, pfedit writes the changes back to the original file, and generates an audit record including
the differences.
Passing the Authentication State to Child Processes
An xterm window can be used to demonstrate how subsequent re-authentication can be bypassed. The
profiles command can be used to verify that xterm is included in an authenticated rights profile that is
assigned to test:
test@solaris[22]% profiles -lxc xterm test
name=Test
id=/usr/bin/xterm
test@solaris[22]%
id=/usr/bin/xterm
test@solaris[22]% xterm&
Assuming the timer has expired for the current Terminal the following prompt will appear:
Re-authentication by test is required to use profile:
Test
Password:
After successful re-authentication, a new xterm window appears, and the shell prompt suffix changes to #
indicating that the authentication state has been inherited from xterm. In addition, the following command
can be used to verify that both process flags are set for all processes started from this xterm>window:
test@solaris[22]# ppriv $$
485931: bash
flags = PRIV_PFEXEC|PRIV_PFEXEC_AUTH
E: basic
E: basic
P: basic
L: all