RBAC with AIX 5L and what the future holds

IBM recently announced that its latest version of the AIX operating system will now be called AIX 6.1 instead of 5.4 as was originally announced. AIX 6 is currently in beta with certain customers, and as an employee of one of those customers, I've already gotten to kick the tires of its security features.

Unfortunately for you, I can't go into a whole lot of detail about those features. They're pushing Workload Partitions (WPARs) pretty hard in their press, but they also provided a very nice revamp to their Role-Based Access Control features in 6.1. I'll cover those features once AIX 6 goes public beta.

For the time being, though, I'll discuss Role-Based Access Control in AIX 5L. First off, I wasn't even aware that there had been any attempt at RBAC with AIX until after I read that AIX 6's RBAC built on the RBAC that AIX has had since the 4.x days. So, I fired up my old RS/6000 Model 250 (running AIX 5L Version 5.1) to see what I could find. I know for fact that many companies who rely on AIX don't make use of its built-in RBAC where it might be appropriate. That's probably why I hadn't heard about RBAC until now. With the new features in AIX 6.1, I'm going to be very disappointed if this functionality remains under-utilized.

What I found wasn't particularly exciting, but it does work for what it is. Wikipedia defines RBAC as "an approach to restricting system access to authorized users." In short and sweet terms, that just about does it. Role-Based Access Control is about separation of duties, too. Traditionally, on UNIX-like operating systems, if a person on the helpdesk should only have access to reset passwords, they would still need the root password. With that access, they could format all the disks in the server, install or remove software, access personal files, shut down or start services that they shouldn't, or even bring the server offline. For many years, there have been third-party tools such as Sudo that attempt to grant permission for trusted users to perform the tasks they need to perform without giving away the keys to the kingdom, so to speak.

With integrated RBAC, though, things begin to change a bit.

While I think that the RBAC in AIX 5L is sorely lacking, it's certainly better than nothing at all.

Enough chit-chat about the future, though. Let's look at the present tense, shall we?

AIX has some conventions that are a little awkward compared to other UNIX-like operating systems. They make excessive use of "mk" (make), "ls" (list), "ch" (change) and "rm" commands. To add a new user on the command line, for example, you must pass the correct syntax to the mkuser command. To show attributes of an existing user, you'd use the lsuser command. Logical volumes (partitions, basically) are managed with commands such as mkvg, lsvg, and chvg.

It should come as no surprise, then, that roles for use in RBAC are managed with the mkrole, chrole, lsrole, and rmrole commands for creating, modifying, listing, and removing roles respectively. I'll cover managing the roles in just a moment.

There are three elements to RBAC on AIX. The user itself, the roles of the user, and the authorizations that the roles have.

Roles are given to users by placing them in the correct group if needed, and then by using the chuser command to assign a role or set of roles to the user, as follows:

chuser groups=security,system roles=ManageAllUsers,RunDiagnostics axon

I assigned axon to the security and system groups as secondary groups because the programs that axon needs to run (diag, passwd, mkuser, lsuser, rmuser etc) are owned by those groups.

A role is composed of different authorizations. Roles may also inherit authorizations from other roles. You can think of roles as keychains that are issued to users, and authorizations as individual keys to unlock certain privileged functionality. One keychain (role) might have just a few keys on it, or it might have a few other keychains (functionality of other roles) hanging off of it, with a few extra keys as well, if need be.

Authorizations are the most granular part of RBAC. You can't assign authorizations directly to a user, and it would be pointless to do so. A backup operator, for example, would need authorization to not only back up all files on the system, but also to restore files to anywhere on the system. AIX comes with a pre-defined "ManageBackupRestore" role that gives the role holders access to do both of these things.

In AIX 5L, there aren't that many authorizations that I know of. I can say that IBM's greatly expanded the number, granularity, and functionality of authorizations and roles in the new version of AIX.

Our imaginary helpdesk staff is responsible for not only changing passwords and unlocking accounts, but also for restoring files from backup for users who accidentally erased or corrupted their files. Let's make a role for them:

mkrole authorizations=Restore,PasswdManage Helpdesk

Now, we add this role to Jim Adams and Terry Zabel, our wonderful imaginary helldesk techs. Don't forget to add them to the system group (for restoring files) and security group (for managing passwords). When in doubt, look at the group ownership of the tools they will need to run. In this case, /usr/sbin/restore and /usr/bin/passwd.

chuser groups=security,system roles=Helpdesk jadams
chuser groups=security,system roles=Helpdesk tzabel


Now, without giving away the root password or installing third-party software, our helpdesk technicians can perform their duties. Of course, granting this kind of access still requires users with elevated privileges to be mindful of their responsibilities and careful when executing commands that could cause potential harm to the system. The same would hold true with sudo or other solutions, though.

Look for more information about RBAC with other operating systems, and an overview of new security features in AIX 6 coming soon.