UNIX has always had a mechanism whereby users are allowed to run programs that they normally would not be allowed to run because of their user id number. Even with modern-day Solaris you still have the ability to run programs as set user id or set group id. For accessing files you could use access control lists to fine tune your permissions settings. And if all else fails, you could use the venerable third-party program sudo or commercial software such as Symark's PowerBroker.

Things changed just a tad with Solaris 8 though. We now have a built-in process known as Role-based Access Control (RBAC). Although sudo or PowerBroker can provide some of the functionality of RBAC, with RBAC you no longer need to compile or purchase another program to provide this functionality.

Foundation

There are a couple of directories and a few files that you need to be aware of to fully implement RBAC.. The files in the /etc directory are passwd, shadow, and user_attr. The files in the /etc/security directory are auth_attr, device_policy, exec_attr, prof_attr, and policy.conf.

The /etc/user_attr file is an extension to /etc/passwd and /etc/shadow. When you create a role it is normally stored in this file. A role is used to grant the user access to do things that they normally would not be allowed to do. This includes things such as starting programs that use a port number below 1024. You can add roles to the /etc/user_attr file or you can add them directly to the users listed in /etc/passwd. The recommendation is to store all role related user accounts in /etc/user_attr.

Depending on where you store the role information plays a vital role in how the user will interact with RBAC. If you attach the roles directly to their user accounts then they will not need to enter a password when they wish to use a command line utility.

If you store the roles in /etc/user_attr as recommmended then the user will need to use the su command to switch to the role user account so they can use the command line utility.

su requires you to use a password. You can set the password to a null value if you desire but some company's auditing team may catch this and require you to actually set it to a real password.

A role is similar to a typical user account except that you cannot log on to the system with a role user account. You log on as a normal user and then su to the role. The role determines which commands your users have access to outside of the usual commands that they are allowed to run. You might find this to be a benefit if you don't want people to logon to your systems as user root. Convert the root user to a role and then the administrator has to logon as a normal user first and then su to the root role. Then there is an audit trail that you can follow to see who is using su to assume the root role.

A role is a generic term. Most publicly traded companies have the role of CEO. The role of CEO is generally occupied by someone. Along with the role of CEO comes the rights of being a CEO. You get to do things such as set company direction or participate on phone calls to stock broker's to brag about project X that has just started to ship and will change the world.

A role on Solaris can be occupied by more than one person. Role accounts stored in /etc/user_attr have passwords associated with them and anyone who has been granted the rights to the role and who has the role password can assume the role and use the commands/applications that are associated with that role.

You can attach a role directly to a normal user accounts and then those users would not need to provide a password. They would use the pfexec command or switch to a role shell to begin using privileged commands.

Next Section: The Basics - 2 of 7