pfexec

pfexec

The Role-Based Access Control (RBAC) scheme in the OpenSolaris OS, Sun’s open-source project for the Solaris OS, offers rights profiles. A rights profile is defined as "a collection of administrative capabilities that can be assigned to a role or to a user" in the RBAC and Privileges tutorial. Rights profiles can contain authorizations, commands with security attributes, and other rights profiles - a convenient way for grouping security attributes.

With RBAC, you as the system administrator first create profiles and then assign them to roles. Those two tasks are beyond the scope of this article. Finally, you grant users the ability to assume the roles.

You can also assign a profile directly to a user - the method described later in this article. Afterwards, that user can perform the tasks that are defined by the rights profile - even execute root commands without having to log in as superuser. All that person needs to do is prepend the utility pfexec to the commands. In effect, pfexec functions as a passwordless su or sudo in Linux.

This article shows you how to delegate administration tasks and assign root capabilities to regular users by way of rights profiles. It is assumed that you are familiar with RBAC concepts and commands in the OpenSolaris OS and have read the RBAC and Privileges tutorial referenced above.

Note: pfexec has been available on the Solaris OS since Solaris 8 and Trusted Solaris 8 and is not unique to the OpenSolaris OS.

Delegating Administration Tasks

Let’s assume that user testuser would like to regularly share and unshare directories with other systems through a Network File System (NFS). Normal user privileges do not allow him to do so, as shown below:

$ /usr/sbin/share /export/home/testuser
Could not share: /export/home/testuser: no permission

However, you can add a profile with the share right for testuser. Do the following:

  1. As root, create a new user and assign a password to that person. In the OpenSolaris OS, the first user you create is already assigned to a profile that allows that person to perform all the root tasks. Following are the related commands and output:

    # mkdir -p /export/home
# useradd -m -d /export/home/testuser testuser
80 blocks
# passwd testuser
New Password:
Re-enter new Password:
passwd: password successfully changed for testuser

  2. Log out and log in again as the new user.

  3. Look for a matching profile in the exec\_attr file with the share command. Here are the command and subsequent output, which shows a match in File System Management:

    $ grep "share" /etc/security/exec_attr
File System Management:suser:cmd:::/usr/sbin/dfshares:euid=0
File System Management:suser:cmd:::/usr/sbin/share:uid=0;gid=root
File System Management:suser:cmd:::/usr/sbin/shareall:uid=0;gid=root
File System Management:suser:cmd:::/usr/sbin/sharemgr:uid=0;gid=root
File System Management:suser:cmd:::/usr/sbin/unshare:uid=0;gid=root
File System Management:suser:cmd:::/usr/sbin/unshareall:uid=0;gid=root
[...]

  4. Become root and assign the File System Management rights profile to testuser. Here are the commands and subsequent output:

    $ su root
Password:
# usermod -P'File System Management' testuser
UX: usermod: testuser is currently logged in, some changes may not take
effect until next login.

In this case, despite the warning that some changes are only effective after user logout, the user needs not do so. This change is effective immediately.Voila! testuser can now share and unshare directories by prepending pfexec to the share command without becoming superuser:

$ pfexec /usr/sbin/share /export/home/testuser
$ /usr/sbin/share
      - /export/home/testuser rw ""

Granting Root Capabilities to Regular Users

Warning: Even though you can grant regular users root capabilities with pfexec, do so with care and discretion. Ensure that those to whom you grant root capabilities are trusted, knowledgeable administrators and that they protect their own passwords as they would their root passwords.

The Primary Administrator profile in the OpenSolaris OS grants the capabilities traditionally associated with root. That is, users who are assigned that profile can execute root commands without logging in as root. See the profile’s entry in the exec_attr file:

# cat /etc/security/exec_attr | grep "Primary"
Primary Administrator:suser:cmd:::*:uid=0;gid=0

That means all the commands that are executed with this profile with pfexec prepended are run with uid=0 and gid=0, hence with root privileges.Granting users the root capabilities through the Primary Administrator rights profile has several advantages:

  • You need not reveal the root password to the users.

  • To withdraw a user’s root privilege, simply delete the Primary Administrator profile from the user setup-no need to set a new root password.

  • Users with the Primary Administrator rights profile can set up a root shell and need not prepend root commands with pfexec afterwards.

See this example:

  1. As root, assign the Primary Administrator profile to testuser. Here are the commands and subsequent output:

    $ usermod -P'Primary Administrator' testuser
UX: usermod: testuser is currently logged in, some changes may not take
effect until next login.

  2. As a test, log in as testuser and execute the id -a command twice: once without pfexec and once with pfexec. Note the output:

    $ id -a
uid=100(testuser) gid=1(other) groups=1(other)
$ pfexec id -a
uid=0(root) gid=0(root) groups=1(other)

Without pfexec, testuser’s uid and gid values are those of testuser and other, respectively-that is, nonroot. With pfexec, uid and gid assume the value of root.To avoid having to type pfexec over and over again, testuser can set up a root Bash shell on his system, like this:

$ pfexec bash
bash-3.2# id
uid=0(root) gid=0(root)

To remove the profile, log in as root and type:

# usermod -P '' testuser
#

Afterwards, uid and gid revert to the normal values of the user, as reflected in the output of the id -a command when executed under the control of pfexec. Without an assigned profile, pfexec yields no additional privileges to the user:

$ pfexec id -a
uid=100(testuser) gid=1(other) groups=1(other)

An important advice

As you may have recognized, there is no further password protection between a user with the Primary Administrator and running programs with root capabilities. You shouldn’t use such an account for your daily work, when you are using scripts or programms downloaded from the Internet, as such a script has just to prepend a pfexec to a command to yield administrative capabilities. On OpenSolaris 200x.y it’s a good practice to create a second account for your daily work without the Primary Administrator profile.

Conclusion

Again, passwordless pfexec is the OpenSolaris version of Linux’s sudo. Assigning and revoking the root capabilities through the Primary Administrator profile is simple and straightforward. In addition, you can monitor user actions by logging the executions of pfexec with the auditing subsystem of the Solaris OS.

By default, the user account that you create while installing OpenSolaris 2008.11, the latest version of the OS, is automatically assigned the Primary Administrator rights profile even though the user cannot directly log in as root. Subsequently, that user can run pfexec with the root privilege - a big convenience to all!

Networking