HiR Reading Room: AIX 5L Administration

While AIX 6.1 is the new hotness, it's mostly feature additions. If you know AIX 5, you can get around AIX 6 without a problem -- you just might be missing out on cool things like enhanced RBAC and workload partitions.

The writing, grammar and editing of this book leaves a little bit to be desired, but the concepts covered in AIX 5L Administration are vitally important for any AIX sysadmin to be familiar with. This book is great for people who have a casual working knowledge of the UNIX command line (linux, solaris or BSD) who want to expand their horizons all the way up to seasoned intermediate AIX users, who will find new things and helpful tips within these pages.

I personally bought this book while I was job hunting. I had some rusty familiarity with AIX 4, but was looking at the prospect of landing a job that required working, functional knowledge of Solaris 8, Solaris 10, and AIX 5.3. It was a great refresher course for AIX, and gave me the information I needed to confidently blaze through a pre-employment AIX knowledge test. Now, more than a year later, this book sits next to my desk and is occasionally referenced when I need to do something on AIX that I'm not too familiar with.

Whether for reference, for job advancement, or for the fun of tinkering around with something new, this book comes highly recommended for anyone dealing with AIX, either daily or occasionally.

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.

AIX 6 goes General Availability

AIX 6.1 was released earlier this week. During the initial beta phase, they were considering calling it AIX 5.4.  There was no AIX 5.4, nor was there a 6.0.  They're debuting AIX 6 as version 6.1. 

AIX is IBM's enterprise UNIX offering for their pSeries servers, which replaced the old RS/6000 line years ago. New features include:

• Improved RBAC (Role Based Access Control) functionality
• Workload Partition (WPAR) virtualization - multiple virtual environments within one AIX instance, versus Logical Partition (LPAR) virtualization, which is multiple AIX instances on one system.
• Support for Encrypted Journaling file systems (JFS2/EFS)
• Trusted Computing Base - An optional secure-by-default installation
• AIX Security Expert - a template-based console for setting up security options
• Concurrent kernel updates - no reboot needed for certain types of kernel upgrades
• First-failure data capture functionality to aid in troubleshooting or reproducing obscure faults
• System routines that can gracefully recover from certain kernel crashes

I've had some time to use AIX 6 while it was in beta, and I must say that I'm impressed by the enhancements that I've been able to use so far.  Built-in virtualization is slick and seems to be working well in the general available release of AIX 6.1 now that it's out of beta.  You won't likely be playing with AIX on your next workstation, but you'll start to see it rolling out to an enterprise environment near you.