In this article, security expert Carol Woodbury answers those nagging questions you have about AIX security.

Security terms are thrown about in articles and manuals, but do you know what they really mean? Below are some of the questions I asked when I was first learning about AIX security. Perhaps you have some of the same questions I did. Let's take a look.

What Is the umask?

The umask (user file-creation mode mask) sets the permissions (authorities) on newly created files. While one might think that the value specified for the umask represents the authorities granted to the file, it doesn't. It represents the authorities removed from the file's permissions (r for read, w for write, and x for execute). In other words, without the umask, the permissions on a file would be set to user rwx, group rwx, and other rwx. The umask allows you to remove authorities so that files don't end up with everyone having all authorities. Confusing…or at least not obvious!

Another confusing element to this is that umask does not use the same format as the chmod, with three strings—one each for user, group, and other. Instead, umask uses one string—as in umask nnn, where, starting from the left, the first number represents the value for the user (owner of the file), the second is the group, and third is for other. You have to decide what authorities you want removed from user, group, and other and then add up their numeric value for each position; that's the umask. To determine what the number should be, use the following:

• r (read) = 4
• w (write) = 2
• x (execute) = 1

If you want to leave the user (owner) of the file with all authorities, specify 0 for the user position. If you are removing write authority from the group, specify 2 for the group position and finally, to remove all permissions from other, specify 7 (to get the number 7, I've added up the values of read, write, and execute, which equals 7.) The umask in this case is 027.

Now let's create a new file and see what the effect is. The system starts out by assuming that all permissions are going to be granted to user, group, and other (chmod 777 newfile). Then the umask is applied, and the permissions not to be granted to the file are removed by subtracting the umask for each from 7 (the total number of the permissions that can be granted.) So the user permission is set to 7 (7-0=7, which equals rwx), the group permission is set to 5 (7-2=5, which equals rx), and other permission is set to 0 (7-7=0, which equals no authority). The permissions after the file is created are these:

$ ls –l newfile

rwxr-x---

AIX defaults to a umask of 022, which has the effect of leaving the owner with rwx and the group and others with rx. You can change the default umask value by running chsec. You can override an individual's default umask value by running chuser. Finally, you can change the umask value for the current process by running the umask nnn command after logging in.

What Is the Sticky Bit?

The sticky bit is the savetext (SVTX) attribute in AIX, one of the three extended attributes that can be added to an access control list—the other two being the set user id (SUID) and set group id (SGID) mod bits. When the SVTX attribute is set on a directory, only the file owner can link or unlink the files in that directory. When set on a file, it enables the save-text attribute. Enabling the save-text attribute causes the file to be saved in text file format.

And now that I've explained the SVTX attribute, I might as well explain the other two attributes. Setting the SUID bit causes the process running the executable to run with the UID (user ID) of the file's owner. Setting the SGID bit causes the process running the executable to run with the GID (group ID) of the file's group.

All of these attributes can be changed using the chmod command.

How Do I Grant Individual Permissions?

On occasion, you may want to allow or deny individuals or groups access to a specific file or set of files beyond what is specified by using the base permissions of owner, group, and others. How do you do this? Extended permissions. Extended permissions allow you to permit or deny permissions to users or groups or specify specific access rights to users or groups.

Extended attributes can be enabled or disabled and the permissions granted by using the acledit command. Permissions can be displayed using the aclget command.

What Is su?

The su (switch user) command allows you to change the UID under which the current process is running. If you don't specify a user name, the process is switched to run as root—as long as you know root's password. You can also specify a user account name and switch to the UID—again as long as you know the user account's password and as long as the account is configured to allow others to switch to it.

So a follow-on question is… 

Is sudo the Same Thing as su?

No. While both su and sudo (superuser do) allow you to run tasks as a different user, sudo continues in the same process but runs the command specified after sudo as a different user. If you missed this from the previous discussion, su logs you in as either root or the user specified. For example, suppose John runs the following command:

            su carol

John will be prompted for carol's password. Assuming he enters the correct password, he is now logged in under her account. Everything he does is now run as carol's UID. To get back to his own account, he types exit.

su is obviously not the most secure means of running with privileged access. That's because you have to know the password of the account you're switching to. In the case of root, if you are the only administrator and you want to run most of your tasks with your own privileges and use su to run as root for only those tasks requiring them, su may be OK. But in shops of any size, using su to run with administrator privileges means sharing the root password amongst all users of su. Sharing passwords, as we all know, causes accountability to be lost because you don't know the exact person who performed the task.

With sudo, the command specified after sudo is run with root privileges. What commands are allowed via sudo and what users or groups are allowed to run them are configured via the /etc/sudoers file. This is a more secure way to run with root privileges because you aren't required to know root's password. In fact, you have to re-authenticate yourself before it runs the command. Also, you can be very specific about which users/groups are configured to use sudo and which commands they're allowed to run.

Going back to an attribute we discussed earlier, setting the SUID or SGID bit on executables is another way to allow users to perform tasks that need more capabilities or access than they have themselves. If the executable is owned or has a group with the privileges required, then the function can be run without giving the individual user accounts higher capabilities than is typically required for their job function.

This leads me to the final question in this series.…

What Is RBAC?

The concept of role-based access control (RBAC) is that privileges and capabilities sufficient to perform job functions are granted to a "role." Typical roles include system administrator, operator, network administrator, developer, end user, etc. RBAC is a way of implementing "least privilege access," meaning that you give only enough capabilities to users for them to perform their work…never any more. When implementing RBAC, you determine the roles that exist across your servers, the tasks these roles perform, and the capabilities and access rights needed to perform the tasks. Then you enable the role to perform these tasks. When new employees are hired, all you have to do is add them into the appropriate roles and they automatically have the privileges and capabilities to perform their jobs. While this concept is simple, the implementation in AIX is (in my opinion) a bit complex and not for the faint of heart. Here's a summary of the implementation.

In AIX 6.1, IBM extended the RBAC capabilities it introduced in AIX 4.2.1. In 6.1, IBM has predefined three roles: isso (Information Security Officer, the most powerful role), sa (System Administrator), and so (System Operator.) You can also define your own roles using the mkrole command if these roles do not meet your organization's needs. Users can be assigned to a specific role or roles using the roles attribute on chuser. Using this method, the user is required to run the swrole after signing on to switch to run as a specific role. swrole is similar to su because it launches a new process and, by default, requires a user to re-authenticate before being able to run as the role (although this can be turned off). However, unlike su, swrole uses the UID and GID of the process that launched it; only the role ID (RID) is changed. You can also use the default_roles attribute to automatically set the roles when the user logs in.

Once you determine whether you're going to use an IBM-supplied role or create one of your own, you must determine what tasks the role needs to perform. To facilitate allowing non-privileged users to run privileged commands, IBM has predefined some new authority definitions. They took logical sets of privileged functions and lumped them into this thing called an authority. For example, the PV_FS_MOUNT authority allows a process to mount and unmount a file system. Under the covers, it allows the mount and unmount system calls to be made. If the authorities that IBM has created don't meet your needs, you can create your own user-defined authorities. To determine whether a command you want a non-administrator user to run is in a predefined authority, run the lssecattr command.

Roles are then assigned authorities. In other words, roles are assigned the tasks they're allowed to perform. You can use the lsrole command to list the authorizations assigned to a role. Use the lsauth command with the roles attribute to find out which role(s) an authority has been assigned to.

For more information, including details on how to create user-defined roles and user-defined authorities, see the AIX V6 Advanced Security Features Redbook.

How Do I Set the Password Configuration Rules to Meet PCI DSS Requirements?

Perhaps this is a bit of a random question, but because my company works with a lot of organizations that have to be in compliance with the Payment Card Industry's Data Security Standards (PCI DSS), this was one of the questions I needed an answer to. The PCI DSS has the following requirements for password composition:

• Minimum length seven characters
• Must contain both alpha and numeric characters
• Must be changed every 90 days
• Cannot be re-used for four iterations

 To ensure the password rules on your AIX servers meet these requirements, set the following:

• minlen = 7 (minimum length is seven characters)
• histsize = 4 (number of times a new password is required before a password can be reused)
• maxage = 12 (maximum number of weeks before a password is required to be changed)
• minalpha = 1 (minimum number of alphabetic characters the password must contain)
• minother = 1 (minimum number of non-alphabetic characters the password must contain)
• loginretries = 6 (number of times a password can be guessed before the account is locked)

The server-wide rules are kept in /etc/security/usr. However, these rules can also be overridden at the user level. This may be appropriate for some user accounts. For instance, you may want to require administrators to change their passwords more frequently than every 90 days. That way, if an administrator's password is compromised, there are fewer days when it can be abused. Or you may have process profiles that are connecting to the server. These accounts may have a longer period between password changes. This is usually only acceptable to auditors if there is a process to change these passwords at least annually. Beyond these two reasons, it is best to have the password rule requirements come from the global server configuration settings rather than the individual accounts so that composition rule changes can be more easily implemented. You can check to see whether any users have password rules specified by running the lsuser command and looking for password entries for each user account. There will be no entries if they are coming from the server settings.

Also, just because these are the requirements for PCI, this is not necessarily the entire list of values you might want to specify for your password rules or the values your organization's security policy requires. For example, some standards are starting to recommend a minimum length of eight characters to meet security best practices for password composition.

Clear Now?

I hope that this article has been helpful in answering some of your AIX security questions.