Custom Roles Using RBAC in the Solaris OS

Role Based Access Control (RBAC) started shipping with the Solaris 8 release of Sun Microsystems' UNIX operating system. It can now be found within the Solaris 8, 9, and 10 releases. Simply defined, RBAC is a security tool to allow any non-root users access to complete tasks, scripts, and so on, with superuser privileges. For example, you have a second-shift operator who has been tasked to reboot some servers. RBAC can be used to set up permissions for the operator to carry out this task, which normally requires superuser authority. This is done simply by first creating a user, or defining an existing user. Next, a role and profile are created, and the profile is assigned to the role. After the profile has been assigned to a valid role, the role is now assigned to the OS user. The profile will have associated with it the task or script that is required to be run.

Most system administrators are familiar with Sudo. Sudo is similar to the RBAC feature. As a system administrator, I am often asked by our users, "Do we have Sudo here?" Or occasionally I'm asked, "Is Sudo set up on these servers, and if not, when will it be?" Sudo is a great tool, however, there exists one primary problem with it -- Sudo is not a software product supported by Sun Microsystems. If you have trouble implementing it, or if it somehow interferes with your system's ability to operate correctly, there may not be assistance available to you under your support contract. It's something any system administrator or IT manager should take into consideration when planning. The native Solaris RBAC allows you to have similar Sudo-like capabilities without having to add unwanted third-party software.

The intended purpose of this document is to provide a cookbook to give any system administrator a quick example of how RBAC is used in the industry, along with a very basic understanding of the features and inner workings of RBAC itself. I detail two real-world scenarios, with examples to help you get started. The third section is a brief overview of some of the profiles provided by Sun, with a discussion of how they can be implemented. I jump right into the creation and configuration of RBAC roles without providing too much detail on what each file is. I assume the reader will pick up on that stuff as they read ahead. The References I list at the end are excellent sources for this type of information, most of which can be found online at docs.sun.com.

There are six important files that are updated as you are creating the roles and accounts. You need to become familiar with these files because you will be updating some or all of them manually. As with most configuration files, any typos can result in the failure of parts of the RBAC feature or the entire RBAC feature. I recommend these files be checked frequently for syntax as you are configuring these roles. You'll also see in the examples provided that /usr/bin/rolemod and /usr/bin/usermod are used. I suggest you become familiar with these commands by perusing the man pages or reading Sun's online documentation. If you are creating a new user, /usr/bin/useradd is another command that you should become familiar with.

The examples found here are from documentation that I created when initially setting up these roles and accounts. The actual roles, accounts, user names, and scripts should be changed as it pertains to your environment. These examples were tested on Sun servers running Solaris releases 8, 9, and 10. I also think it's interesting to note that different versions of the Solaris Operating System have dissimilar entries in their RBAC configuration files. Therefore you may see more or less content within these files on your various servers, depending on which release of the operating system you have in use.

Here are the files that you will be modifying as you work with and configure RBAC for your environment. These first four files are also known as RBAC databases. The last two are the OS user account files. They are listed in no particular order.

1. /etc/security/auth_attr

2. /etc/security/prof_attr
3. /etc/security/exec_attr       
4. /etc/user_attr
5. /etc/passwd                   
6. /etc/shadow

Note on #1 above: The /etc/security/auth_attr file is not used in the examples described above. This is partly because I am working with custom profiles. The auth_attr database is typically updated when certain profiles are assigned to roles and when the Solaris Management Console (SMC) is used to work with RBAC.

It helps to identify the user, role, and script that will be involved before starting. In most cases, the user will already exist, and the role and script are left to be created. You can provide your own names here:

User:                   _________________________

Rolename:               _________________________
Location of Script:     _________________________
Profile Name:           _________________________

Scenario One

In our local IT environment, we have a user who maintains an application on numerous servers running the Solaris OS. On average these application processes need to be started or stopped several times a week. Because these processes are typically started and owned by root, they must be stopped by root or someone with superuser privileges. Oftentimes, a system administrator is not available for several hours or even a day or more to perform this task. This slows down productivity for the user.

When trying to determine a better solution for our user, RBAC fit the puzzle exactly. Ultimately, this solution helped the user work more efficiently and eased the workload for both the user and system administrator involved. The name of the application in this example is Harvest. As I understand it, Harvest is commercial software used to aid in migrating data and software applications from their test environments out to development or production, and so on. The user maintains this application while logged on to the system as the user: harvest. Here is what I do in this situation:

1. Create the role account.
2. Set the password for the role account.
3. Edit the /etc/security/prof_attr file and create a profile with a description of the profile.
4. Edit the /etc/security/exec_attr file to define what the profile is doing.
5. Use /usr/bin/rolemod to associate the new profile with the role account.
6. Add the role to a user.

Let's get started.

Example:

Use Solaris Role Based Access Control (RBAC) to allow a general non-root user to stop and start Harvest Agent.

Rolename:

                
harvasst
Username:  
                
harvest
Profile Name:  
                
Harvest
              

1. Using the name defined for your environment, create the role here:

# roleadd -u 2000 -g 10 -d /export/home/harvasst -m
harvasst
              

Assign a password to the role account.

# passwd  harvasst
              

2. Create a profile to allow the user to stop or start the Harvest agent.

Edit the /etc/security/prof_attr file and insert the following line:

Harvest:::Permit stop and start of Harvest agent:

Save and exit file.

3. The next step is to create the execution attribute entry in the /etc/security/exec_attr. This defines the task or script to be run and the uid the role will assume when running this task. Note that we specify the profile at the start of the line.

Note: There are seven fields to this file, with each one separated by a colon; only fields one, two, three, six and seven should be used at this time.

Edit the /etc/security/exec_attr file and insert the following line:

Harvest:suser:cmd:::/etc/init.d/harvestagent:uid=0

4. Use the rolemod command to add the Harvest and All [ 1] profiles to the role as follows:

# rolemod -P Harvest,All harvasst

5. The rolemod command updates the /etc/user_attr file. Verify that the changes have been made.

# more /etc/user_attr


harvasst::::type=role;profiles=Harvest,All
harvest::::type=normal;roles=harvasst

Here you can easily see that the harvasst role has been assigned to the harvest user account. The Harvest profile is now associated with the harvasst role.

6. Use the usermod command to assign the role account to the harvest user.

# usermod -R harvasst <username>

Note: Notice how we used different variations of the word Harvest to create our role and profile. These names are case sensitive as you are implementing them into the necessary files. Keep this in mind if you find yourself troubleshooting.

Congratulations! You have just created your first role using RBAC. Take a few minutes now to review the files you just modified and to do some testing before turning this over to the user.

Now you must instruct the user on how to use this new role.

Instructions for User:

You must be logged in as the required account (in this case, it is harvest).

Switch user to the Harvest agent role as shown here:

$ su - harvasst

Password: <enter password> 

Once you are authenticated, the command to start the agent is as follows:

$ /etc/init.d/harvestagent start

To stop the agent:

$ /etc/init.d/harvestagent stop

To check the status of the process:

$ ps -ef | grep harvest

To exit the role and return to original user, type exit.

This example clearly shows how to use RBAC to create a role that can be assumed by a user to execute superuser tasks.

Scenario Two

In the next example of using RBAC, I am setting up a role to allow the Oracle user to run a script to roll over some web server log files which are generally owned by root. The script, called rollover_logs.sh, is used by DBAs typically during weekend maintenance when the web server software is stopped and started and to clean up space on the disk drives. In preparation, I make sure the script has been tested, remove oracle:dba ownership, and replace with root ownership. Changing ownership prevents the script from being modified to perform other actions. Since this task is often done at obscure times, the DBAs have access to run this at their leisure. I provide the details of this script below.

This example is very similar to the previous role setup except that we use completely different role names and user accounts, and I create a unique profile for each script located in different directories. I use orassist for the role, and then assign that role to the Oracle user account. Oracle_Assistant is the profile name and defines what script will be run by the Oracle user. If there were another script, possibly located in another directory, I would create another profile using Oracle_Assistant as the profile name, and add the location to the new script in the /etc/security/exec_attr file. Specifying multiple tasks or scripts with the same profile name is a standard practice. Just remember to keep them separated by placing each new task on its own line in the exec_attr file.

Rolename:

               
orassist
Username:  
                
oracle
Profile Name:  
                
Oracle_Assistant
              

1. Using a role name of your choice, use roleadd to create the role:

# roleadd -u 2100 -g 10 -d /export/home/

                
orassist -m  
              
orassist
              

Assign a password to the role account.

# passwd  orassist
              

2. Create a profile to allow the oracle user to run scripts in a specified location.

Edit the /etc/security/prof_attr file and enter the following line:

Oracle_Assistant:::Permit Oracle user to run Oracle scripts:

Save and exit file.

3. The next step is to create the execution attribute entry in the /etc/security/exec_attr. This defines the task or script to be run and the uid the role will assume when running this task. Note that we specify the profile at the start of the line.

Note: There are seven fields to this file with each one separated by a colon; only fields one, two, three, six and seven should be populated at this time.

Insert the execution attributes entry in /etc/security/exec_attr as follows:

Oracle_Assistant:suser:cmd:::

                
<location of script>:uid=0
              

4. Add the Oracle_Assistant and All [ 1] profiles to the role as follows:

# rolemod -P Oracle_Assistant,All orassist

5. The rolemod command updates the /etc/user_attr file. Verify that the changes have been made.

# more /etc/user_attr


oracle::::type=normal;roles=orassist
orassist::::type=role;profiles=Oracle_Assistant,All

Here you can see that the orassist role has been assigned to the oracle user account. The Oracle_Assistant profile is now associated with the orassist role.

6. Use the usermod command to assign the role account to the oracle user:

# usermod -R orassist

                
<user_name>  <-- insert oracle here.
              

With the script owned by root and tested several times, I have peace of mind in turning it over to another user. I'll continue to use RBAC to assist those who have tasks that require superuser privileges. I have included instructions for the user on how to gain access to the role and execute the script.

Instructions for User:

You must be logged in as the required account (in this case, it is oracle). Switch user to the Oracle Assistant role as shown here:

$ su - orassist

Password: <enter password>

Once you are authenticated, the command to run the script is as follows:

$ /<location of script>/rollover_logs.sh 

To exit the role and return to original user, type exit.

Disabling Roles

Roles are similar to user accounts. They require a password to be authenticated. The role feature can be disabled easily by manually disabling or locking the role account. One way this is done is by placing an "LK" in the encrypted password field in the /etc/shadow file.

Example:

orassist:LK:12937:7:56:7:::

Script Example (As Described in Scenario Two)

#!/bin/ksh#   set today's date extension
cleandate=`date '+%c%m%d' | awk '{ print $5 }'`
echo $cleandate
#
#   Roll over logs:  save copy with current date
#                    create new ( empty ) file
#
#
#   rename Apache logs  must be done by root
#
cd <APACHE_HOME>/Apache/Apache/logs
cp access_log access_log.$cleandate
echo > access_log
cp error_log error_log.$cleandate
echo > error_log
cp ssl_request_log ssl_request_log.$cleandate
echo > ssl_request_log

Profiles in the Solaris OS

The next and final section reviews several RBAC profiles that ship with the Solaris OS. You can easily create new roles and add these existing profiles to them to create unique combinations for your users and junior administrators and even backup administrators.

As you were following along with the examples above, you probably noticed the long list of profiles while editing the /etc/prof_attr file. These profiles have been created to aid in system administration functions. By comparing the prof_attr and exec_attr files, you can easily distinguish which profiles are allowed to do what. Knowing this information will allow you to implement these. Most IT data centers employ computer room operators who have the responsibility to monitor activities that take place on numerous servers and mainframes. These folks are often involved in the data backup process. When this becomes true, these folks make good candidates for new roles that allow them to run backup and tape related commands. For example, a system administrator could create a new role called bkadmin and add the Media Backup profile (shown below) which would give bkadmin access to tar files and to mount and unmount tapes.

$ more /etc/security/exec_attr | grep Backup

                
Media Backup:suser:cmd:::/usr/bin/mt:euid=0
Media Backup:suser:cmd:::/usr/sbin/tar:euid=0
Media Backup:suser:cmd:::/usr/lib/ufs/ufsdump:euid=0;gid=sys
              

Another helpful set of profiles is the Printer Management profiles. These allow a user access to a large group of printer-related commands used to manage printers and print devices. Creating a role and assigning this group of profiles might help ease the workload of a system administrator.

$ more /etc/security/exec_attr | grep PrinterPrinter Management:suser:cmd:::/etc/init.d/lp:euid=0;uid=0
Printer Management:suser:cmd:::/usr/bin/cancel:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/bin/lpset:egid=14
Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/lib/lp/local/accept:uid=lp
Printer Management:suser:cmd:::/usr/sbin/lpadmin:egid=14;uid=lp;gid=8
Printer Management:suser:cmd:::/usr/lib/lp/local/lpadmin:uid=lp;gid=8
Printer Management:suser:cmd:::/usr/sbin/lpfilter:euid=lp;uid=lp
Printer Management:suser:cmd:::/usr/sbin/lpforms:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpmove:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpshut:euid=lp
Printer Management:suser:cmd:::/usr/sbin/lpusers:euid=lp
Printer Management:suser:cmd:::/usr/bin/lpstat:euid=0
Printer Management:suser:cmd:::/usr/lib/lp/lpsched:uid=0
Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
Printer Management:suser:cmd:::/usr/ucb/lprm:euid=0
              

As with most tasks and scripts in UNIX, there is almost always more than one way to accomplish something. This also holds true in the case of creating roles and profiles. If you're familiar with and use the Solaris Management Console (SMC), then you have access to the GUI tool that allows you to review, create, and modify users and roles. There are also several other role management commands that can be utilized to create and manage your roles. The Sun documentation located online has all the additional information needed to use those methods.

[1] A special note about the All (All Rights) profile. The All profile provides a role giving access to all commands not currently assigned to other roles. At the time of role creation, I could have chosen to omit the All profile. This would prevent the role from doing anything else but the assigned role. To give the user some flexibility, I always choose to add it in. Just something to keep in mind as you design your own roles and profiles.

About the Author

Kristopher March, a certified System Administrator for both Solaris and HP-UX operating systems, works for Electronic Data Systems as a senior UNIX system administrator at the Defense Supply Center in Richmond, Virginia. Kristopher supports a large number of UNIX servers and is involved in several ongoing projects. He is involved in DSCR's disaster recovery planning and design and takes an active interest in enterprise storage technology. He joined EDS three years ago after working for several large IT companies and a four-year enlistment in the U.S. Navy.

The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.