Using RBAC on (Open)Solaris

30 Sep '05 - 23:20 by benr

The second worst thing a sysadmin can be asked for is the root password on a system[1]. Generally there are a small handful of things the user (namely DBAs) need to actually do as root, the rest of the time they tend to just be lazy and use root rather than setup permissioning properly. The classic solution to this problem has been "sudo", by which you can either allow users to access certain specific commands as root, or alternatively let them access everything as root, but in both cases the user is identified and logged. Of course, the worst thing that a user with root access can do is log in as root, such that you have to guess based on IP which user is actually messing with your system.

Trusted Solaris 8 introduced an alternative to "sudo", known as Role-based Access Control, or RBAC. RBAC is a flexible method of dishing out permissions in a variety of ways. RBACs chief advantage of "sudo" is that its fully integrated and supported by Sun, rather than a 3rd party unsupported package. However, sudo is simpler to use, more widely used and known, is portable, and has an excellent logging mechanism. Lets see if we can't change some of this.

When using RBAC we want to first clarify some concepts and definitions, namely: Users and Roles, Authorizations and Rights. Notice that I group these together. Lets define these:

  • User: A plain ol' user account, who can login, and do everything you expect.
  • Role: Similar to a user, but is not allowed to login, can only be accessed via "su" allowing a user to assume a role.
  • Authorizations: A named permission, which can be used by applications that adhere to the Solaris permission system.
  • Rights: Description of access to execute a specific executable as a privileged user (typically root)

Both Users and Roles can be assigned rights and authorizations, but because a role can't login to the system your ensured that any user assuming a role is identified. In all other respects a role is just like a normal user, able to have its own home directory, shell, etc, which is useful in instances where you want to have certain environmental variables set prior doing something as that user, plus unlike "sudo", you don't have to append each command with "sudo". Roles are so flexible, in fact, that in Trusted Solaris root itself is a role. Something that you can do as well on Solaris10. Roles are specified in /etc/passwd, just like users, except that they use one of the "Profile" (RBAC) aware shells: pfsh, pfcsh, or pfksh.

Authorizations can become confusing when looking at RBAC. They are specified in /etc/security/auth_attr. Here is an example:

solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html

You'll notice that this line isn't terribly informative. Its merely mapping an authorization ("solaris.system.shutdown") with a description and a pointer to the help file. So where do I find out where that authorization is actually mapped to something? The answer is you don't, its application specific. If an application is written to be authorization aware it gains the ability to use this fine grain authentication method. Many of the Solaris tools are able to leverage these authorizations. You can use them in your own applications by using the getauthattr() function. [See getauthattr(3SECDB) for details.]

Rights, on the other hand, are much more "sudo-like". They are specified in /etc/security/exec_attr. Lets look at some example lines:

DHCP Management:suser:cmd:::/usr/lib/inet/dhcp/svcadm/dhcpconfig:uid=0
Zone Management:solaris:cmd:::/usr/sbin/zoneadm:uid=0
Zone Management:solaris:cmd:::/usr/sbin/zonecfg:uid=0
User Management:solaris:cmd:::/usr/sbin/useradd:euid=0

So in these examples your mapping a specific executable (zoneadm for example) with a profile name (more on this in a minute), and the permissions the executable should be executed as (uid 0 for example). You'll notice one line above specifies "suser" in the second field while the others use "solaris", this defines the security policy associated with the executable; solaris is used for executables that understand the Solaris privileges system and suser for those that don't. For details on the solaris privilege system have a look at the privileges(5) man page.

Now, with that out of the way, we can group authorizations and rights into profiles. Profiles don't do anything except to allow us to group things nicely. They are defined in /etc/security/prof_attr. Here are some examples:

Operator:::Can perform simple administrative tasks:profiles=Printer Management,Media Backup,All;help=RtOperator.html
User Security:::Manage passwords, clearances:auths=solaris.role.*,solaris.profmgr.*,solaris.admin.usermgr.*;help=RtUserSecurity.html
Zone Management:::Zones Virtual Application Environment Administration:help=RtZoneMngmnt.html

If you look at these 3 examples you can see that the first field specifies the profile name itself, then a pretty description is listed, and the last field is an HTML help file. Between the description and helpfile we can specify authorizations that are associated with this profile, these come directly from the auths database we just looked at (/etc/security/auth_attr). Along with authorizations profiles can also be associated, such as the "Operator" profile above that groups the "Printer Management", "Media Backup" and "All" profiles together under a single easy to assign profile.

Now, look back at the rights database example for just a moment, you'll note that the first field of each line in that database is a profile name. This is why some profiles in the profile database have nothing associated with them at all (such as "Zone Management" in our example above), the associations are actually made in the rights database.

So, to briefly review the files we've looked at so far:

  • /etc/security/auth_attr: Database mapping Solaris Authorizations to descriptions, which can later be added to Profiles.
  • /etc/security/exec_attr: Database mapping Rights to Profiles.
  • /etc/security/prof_attr: Database mapping Profiles to Authorizations and other Profiles.

Now that you understand those you can now start associating these authorizations, rights and profiles with users and roles. This is done in the /etc/user_attr database. Lets look at an example:

root::::auths=solaris.*,solaris.grant;profiles=Web Console Management,All;lock_after_retries=no
myrole::::type=role;profiles=All

Looking at the root example, you can see that here is where we associate authorizations, rights, and profiles to users and roles. The mappings in this file can be done via direct editing or by using the "usermod" and "rolemod" tools.

Lets take a quick example. Say that I want to manipulate SMF services without having to become root all the time. I notice that SMF has authorizations in the /etc/security/auth_attr database, as well as 2 profiles that map those authorizations in /etc/security/prof_attr. I can associate the auths directly with my user account or use the profiles, but for cleanliness I'll use a profile. So lets try it:

benr@monolyth benr$ svcadm disable svc:/network/talk:default
svcadm: svc:/network/talk:default: Permission denied.

Now I add the following line to /etc/user_attr: "benr::::profiles=Service Management". Lets try it again.

benr@monolyth benr$ tail -1 /etc/user_attr
benr::::profiles=Service Management
benr@monolyth benr$ svcadm disable svc:/network/talk:default
benr@monolyth benr$ svcs svc:/network/talk:default
STATE          STIME    FMRI
disabled       15:10:17 svc:/network/talk:default

Kool. Now I can bring services up and down without having to become root all the time.

If you look at the argument list to the useradd and usermod commands you'll notice that right there are arguments for associating authorizations (-A) and profiles (-P), as well as linking users to roles (-R). You can play around and do all kinds of stuff.

Is this better or worse than sudo? Thats for you to decide. Clearly it has its advantages. Using Solaris Authorizations profiles a fine grained permissioning scheme that is superior in many ways to the on/off black and white world of UNIX permissions, but of course is dependent upon whether or not the application your accessing understands them. In my opinion, however, sudo has two things up on RBAC: first, each user has to enter their own password (if configured) before executing the command in question which is a nice "You better know what your doing" message to the user, and secondly all commands executed with sudo (if configured) are logged by syslog making a nice audit trail. RBAC integrates "nicely" with Solaris BSM Auditing (Basic Security Module) but honestly thats getting your hands way dirtier than you typically want to. So, there is give and take, but RBAC is already there and fully supported which definitely makes it worth while. You be the judge.

For more information about RBAC, check out these resources:

[1]: The first worst thing that a user can ask for is how to do something they should know how to do, such as failover clusters, restart services, shutdown databases, etc. Its bad enough that they have root access, but knowing how to use it is even worse. ;)


- - C O M M E N T S - -

I like this site!

nickolas (Email) (URL) - 13 June '06 - 00:46

Very interesting & professional site. You done great work.

miriam (Email) (URL) - 13 June '06 - 15:23

Personal information





Remember your information?
Comment

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.


^M