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.

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

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:

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 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
dfltmsg=Password Administration

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
dfltmsg=Security Policy Administration
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
dfltmsg=Information System Security Officer
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:
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

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

$ swrole secstaff
axon's Password:
$ whoami
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
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.

blog comments powered by Disqus