2007 Locus winner "When Sysadmins Ruled the Earth" by Cory Doctorow, full text. (found via wilwheaton.net)
If Cory doesn't make you want to well up a tear or two, you are most surely a true BOFH.
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.
Following the July 2600 Meeting on July 6th, you're all invited over for a cookout at my new place. It's a little over a mile from the 2600 Meeting.
I'd prefer if those who plan on attending would comment here and say so, although I'm pretty sure that my fellow HiR writers will be there. We'll have some burgers, 'dogs, some drinks and snacks.
Bring your own WPA-compatible laptop.
After the cookout and geekout session, we might go on a little treasure-hunt, if you know what I'm saying.
I recieved my copy of the August Issue of SysAdmin this week. The very first column of SysAdmin is always syslog, where the Editor in Chief -- currently Amber Ankerholz -- writes a short essay relevant to the current issue.
This latest issue's syslog has me saddened. It opens as follows:
This is the last issue of SysAdmin magazine that you will receive. The magazine is ceasing publication after this issue.
This is a really hard time for publishers and for print media in general. 2600: The Hacker Quarterly has repeatedly said that things are pretty tense, changing publishers and thus slightly changing the format and binding of the magazine itself. It's industry-wide, and smaller publications are victims of collateral damage, I'm afraid.
Unfortunately for those of us who read and enjoy SysAdmin, there really isn't anything else out there to take its place. Sure, there's a slough of Linux publications out there, but I personally don't use Linux all that often. On a daily basis, I use AIX, Solaris, OpenBSD, and Mac OS X. Also, with the market shifting Linux towards desktop focus, the world is a lot more interested in Ubuntu than it is in SLES, Red Hat Enterprise, or CentOS. Most Linux magazines are now focused on graphics, games, and productivity suites for Linux. That's definitely a far cry away from the content in my beloved departed SysAdmin.
There are other magazines focused on security in general. 2600 comes to mind, but it covers more than just security -- often focusing on mischief or malice beyond the realm of the digital world. Hakin9 is published out of Poland, and the English version of their magazine is written in translated, slightly broken English. It resembles e-zines of old in writing style, which is great for nostalgia but terrible for clearly conveying information. I could name a few others, but they're also sorely lacking in UNIXish-specific systems and applications administration content.
So, a moment of silence for SysAdmin. RIP, Buddy. You will be missed.