Sysadmin Sunday: Quick RBAC primer for AIX 6

A while back ago, I promised to revisit AIX's RBAC functionality to show what kind of cool features have been added for the latest incarnation of Big Blue’s enterprise server operating system. In this week’s Sysadmin Sunday, I’m going to deliver on that promise and take a stroll through the enhanced RBAC functionality in AIX 6. I have previously mentioned AIX 5L’s RBAC implementation was minimal. That’s certainly changed quite a bit. There are 263 default authorizations on my AIX 6 installation fresh out of the box, and you can add more. The real bonus, however, comes from you to give meaning to the authorizations. Prior to AIX 6, only a select few tools recognized roles and authorizations. Now, you can apply security attributes to practically anything on the system, and grant or restrict access based on the authorizations a given user has active.

Conventions
I will be using green block quotes to symbolize commands run as a normal user, and red to symbolize commands run as root. Bold, bright text represents user input.

Overview of RBAC
RBAC stands for Role Based Access Control. In AIX’s implementation, there are three pieces to the RBAC puzzle: Security Attributes, Authorizations and Roles. I'll use some commands in this section, but I'll outline the commands in more detail later on in the article.

Security Attributes
Security attributes may be set for any command (executable), file, device, or process. These attributes determine which authorizations get which privileges. Think of security attributes as a lock on certain parts of the system. For instance, this is the list of security attributes for the “passwd” command:

# lssecattr -F -c /usr/bin/passwd
/usr/bin/passwd:
egid=0
accessauths=aix.security.passwd
innateprivs=PV_AU_ADD,PV_AU_ADMIN,PV_AU_PROC,PV_DAC_O,PV_DAC_R,PV_DAC_W,PV_DAC_X,PV_DEV_QUERY,PV_FS_CHOWN,PV_FS_CNTL,PV_FS_MKNOD,PV_FS_MOUNT,PV_FS_RESIZE,PV_PROC_CRED,PV_PROC_ENV,PV_PROC_PRIO,PV_PROC_RAC,PV_PROC_RSET,PV_PROC_RTCLK,PV_PROC_SIG,PV_PROC_VARS
secflags=FSF_EPS

The innateprivs and secflags attributes look quite intimidating at first glance. They're actually quite simple, but there are so many different privileges that it would be preposterous for me to cover them here. They are well-documented in the IBM Redbook titled AIX V6 Advanced Security Features Introduction and Configuration.

The short and sweet version of it all is that you can run any command as the root user and use tracepriv to determine what privileges were used during the execution of the program. Then, when you go to add a new entry for a device, command, file, or process, you can specify the privileges that tracepriv displayed, adding them to innateprivs for the entry.

# tracepriv passwd axon
Changing password for "axon"
axon's New password:
Enter the new password again:

758004: Used privileges for /usr/bin/passwd:
PV_AU_ADD PV_AU_PROC
PV_DAC_O PV_PROC_TIMER
PV_TCB

The set of privs listed above is the bare minimum that would need to be added to run /usr/bin/passwd. Using this method to determine what's needed for other privileged commands (such as third-party software) is a trivial task.

Authorizations
Authorizations are assigned to roles. Think of authorizations as keys to the security attribute “locks”. There’s not much to the actual authorizations themselves. They are just handy labels for unlocking security attributes. The only things that really matter to us here are the name (aix.security.passwd) and the dfltmsg, which is a human readable description of the authotization. In order for our sysadmins to set passwords for other users, they must have a role which contains the aix.security.passwd role, shown below:

# lsauth -f aix.security.passwd
aix.security.passwd
id=6320
dfltmsg=Password Administration
msgcat=sysauths.cat
msgset=8
msgnum=40

Roles
You can’t just give a sysadmin user access to the aix.security.passwd authorization, though. There’s a role, in this case, SecPolicy, which contains this authorization and a bunch of other ones that are relevant to a sysadmins’ job.

Roles are assigned to a user or group of users, and themselves contain one or more authorizations. They can also inherit all of the authorizations within other roles. You could think of this as a keychain with only the keys that a user or group needs to do their job. In the case of a role that inherits other roles, it would be more like a keychain with other keychains on it. The important fields we're concerned about:

• Authorizations is obviously the major item here, with a comma-separated list of auths that the role is capable of using.
• Rolelist contains a list of sub-roles which this role can get permissions from as we'll see later.
• Groups is a comma-separated list of groups that a user must be a member of in order to invoke the role.
• Dfltmsg is, again, a friendly description, this time for the role itself.
• auth_mode may be set to either NONE or INVOKER. If it's set to INVOKER, the swrole command will prompt the user for their own password (kind of like sudo). If set to NONE, swrole will simply create a new shell with the role's permissions.

# lsrole -f SecPolicy
SecPolicy:
authorizations=aix.security.audit,aix.security.auth,aix.security.cmd,aix.security.config,aix.security.device,aix.security.file,aix.security.kst,aix.security.network,aix.security.proc,aix.security.role,aix.security.passwd,aix.security.su,aix.security.tcb,aix.security.tsd
rolelist=
groups=
visibility=1
screens=*
dfltmsg=Security Policy Administration
msgcat=role_desc.cat
msgnum=8
msgset=1
auth_mode=INVOKER
id=8

Although, if you look, you can see that SecPolicy is inherited by another role, isso. So, if a user has the role of isso assigned to them, then it is not necessary to also grant them a role of SecPolicy.

# lsrole -f isso
isso:
authorizations=aix.device,aix.fs.chroot,aix.fs.manage.export,aix.fs.stat,aix.network,aix.proc.fuser,aix.proc.ipc,aix.proc.status
rolelist=DomainAdmin,SecPolicy,SysConfig
groups=
visibility=1
screens=*
dfltmsg=Information System Security Officer
msgcat=role_desc.cat
msgnum=1
msgset=1
auth_mode=INVOKER
id=1

Users and Roles
When creating a user (with mkuser) or modifying one (with chuser), you can set the roles or default_roles attributes. This is a comma-separated list of roles as found with lsrole ALL. default_roles defines roles that become active as soon as the user logs in. roles are additional privileged roles that require the user to activate the role with swrole.

Example: Adding a role to a user

# chuser roles=isso axon

Now, with my user-level account, you can see that I cannot change root's password until I've switched to the isso role:

$ passwd root
3004-664 You are not authorized to change "root's" password.
$ rolelist
isso Information System Security Officer
$ swrole isso
axon's Password:
$ passwd root
Changing password for "root"
root's New password:

Commands
AIX makes excessive use of mk (make), ch (change), rm (remove), and ls (list) commands. RBAC is no different, as you'll see. You'll see example of how to use these commands in the following sections of the article.

Auth commands:
lsauth - Lists an authorization. lsauth ALL lists all auths.
chauth - Changes authorization
rmauth - Removes authorization
mkauth - Make a new authorization

Example: Creating and listing a new authorization for the security team.

# mkauth dfltmsg="Test auth for security team" secauth
# lsauth secauth
secauth id=10013 dfltmsg=Test auth for security team

role commands:
lsrole - Lists a role's attributes. lsrole ALL lists all roles.
chrole - Changes a role's attributes.
rmrole - Remove a role
mkrole - Make a new role

Example: Creating and listing a new role for our security team staff members that contains the secauth authorization we just made

# mkrole authorizations=secauth dfltmsg="Security staff priv. commands" secstaff
# lsrole secstaff
secstaff authorizations=secauth rolelist= groups= visibility=1 screens=* dfltmsg=Security staff priv. commands msgcat= auth_mode=INVOKER id=11

Security attribute commands:
lssecattr -c -F [/file/path] | ALL - show priv. commands
lssecattr -d -F [/dev/path] | ALL - show priv. Devices
lssecattr -f -F [/file/path] | ALL - show priv. file access
lssecattr -p -F -h [pid] | ALL - show priv. processes
setsecattr - set security attributes

Example: Placing security attributes on a command

# setsecattr -c euid=0 egid=0 accessauths=secteam innateprivs=PV_SU_ROOT,PV_SU_UID /usr/bin/whoami

Whenever you modify any roles, authorizations or security attributes, you should run the setkst command to update the kernel security tables.

# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.

Now that we have updated the security tables, the only thing we need to do is assign roles to a user to see how they work.

Example: Adding a new role to a user. axon was already a member of isso, so we add secstaff to the list:

# chuser roles=isso,secstaff axon

End-user commands:
rolelist - displays a list of roles on the system which you are authorized to swrole to.
swrole [rolename | ALL] - creates a new shell with all of the privileges of the selected roles. Will prompt for your password if auth_mode is set to INVOKER for any of the roles.

With my user-level account, I can now run "whoami" with root privileges thanks to the security attributes, authorizations and role that I added.

$ whoami
axon

$ rolelist
isso Information System Security Officer
secstaff Security staff priv. commands

$ swrole secstaff
axon's Password:
$ whoami
root

To remove security attributes, use the rmsecattr command.

# rmsecattr -c /usr/bin/whoami
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.

Now, my user-level account runs whoami with usual privileges, despite still being in the secstaff role.

$ swrole secstaff
axon's Password:
$ whoami
axon

This should be enough to get you started reaping the benefits of the completely revamped RBAC solution that comes out of the box with AIX 6.1.

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.