Role-based access control in simple steps

A step-by-step approach with examples


Traditionally, there is a single user, root, that controls the security mechanism of the system. The root user decides who can log in, who can access the data, which process has the privileges to get into the kernel mode, and so on. But, the drawback of a single root user is that the system becomes vulnerable to attack if an unauthorized person takes control of the root user.

To avoid this problem, latest releases of AIX (6.1 onwards) introduces new security features like Role Based Authentication Control (RBAC) and Multi level security (MLS) along with various other features like Trusted Execution (TE), Encrypted File System (EFS) and more, in addition to the existing traditional ROOT user based authentication.

This article explains, with examples, how the new features like RBAC and MLS can be easily understood and applied.

Security management overview

  • Traditional
  • RBAC


One can use the DAC (Discretionary Access Control) to control access to the data (in a process/file relationship). However, the root user, who has all the privileges, is considered to be the sole user. The root user succeeds any access control and performs any operation that it wants to do. This can pose a major security threat.

Moreover, the root user plays many roles like system administrator, security officer to maintain security policy, and systems operator for day-to-day activities. It is the single user which controls the system and the system as such does not have any control over the activities within the system.

RBAC distributes the root user's roles and authorization to more than one user. This article shows how RBAC provides enhanced security to the system.


Traditional AIX systems have a limited set of authorizations that can be used to determine access to certain administrative commands. The following example shows that the passwd command is the setuid program, which has the authorization and privileges to be executed as a non-root user. It is also able to modify the /etc/security/passwd file as a non-root user. DAC does not allow this.

setuid programs like the passwd command
$ ls -l 'which passwd'
-r-sr-xr-x    1 root     security      40014 May 07 2008  /usr/bin/passwd

# ls -l /etc/security/passwd
-rw-------    1 root     security        467 Mar 10 23:48 /etc/security/passwd

This opens up a major risk of anyone who gets control of the root shell through malicious setuid programs can then do anything they want.

Prior to AIX version 6, portions of root-user authority could be assigned to non-root users. Different root user tasks (commands) are assigned different authorizations. These authorizations are grouped into roles and assigned to different users:

  • Tasks -> Authorization
  • Authorization -> Roles
  • Roles -> Users

But the root user is still the sole boss. Anyone that can get access to root can do anything.

Starting with AIX release version 6, the role-based access mechanism is been enhanced.

  • root access can be disabled.
  • root tasks are assigned to three system-defined users.
  • Privileges, authorization, and roles are assigned as per the users' responsibility.

In this way, the single path to destruction is avoided.

How do authorization, role and privileges work?

  • Authorizations are assigned to commands
  • Roles are assigned to users.
  • Privileges are associated with specific processes.
  • Explicit privileges are assigned to commands required for execution and their execution is governed by authorization.

The system has a pre-defined authorization to certain commands and roles for system-defined users.

Further, a user who is considered as administrator can provide an (user-defined) authorization to an executable program and assign the authorization to a role. Each user is assigned a role.

Hence, a user with a defined role should be able to execute any authorized command.

shutdown command
Command: Shutdown
Authorization: aix.system.boot.shutdown 
Role: isso, so
Privileges: Root privileges

Should a user with information system security officer (ISSO) or a similar role be able to execute shutdown?

Should a user with information system security officer (ISSO) or a similar role be able to execute shutdown?

The answer is Yes. The user should have the roles authorized to them to execute shutdown. From the previous example, you can understand that only the user who has the roles, authorization, and privileges should be able to execute shutdown.

Is it possible that a malicious user can get the role of ISSO and use his own shutdown program to attack the system?

Is it possible that a malicious user can get the role of ISSO and use his own shutdown program to attack the system?

The answer is No provided if the isso role is not assigned intentionally. Since the malicious user in this case will be malicious administrator who does NOT have complete authorization to do whatever he wants.

Here the point to understand is that only a user with administrator authorization can assign authorizations and roles. Anyone who gets control of the administrative user maliciously cannot do anything, since the administrator alone cannot do anything destructive.

Only certain users are allowed to do certain actions. The onus on a single user root is delegated. In this way, higher security is achieved.

System-defined authorizations are prefixed with aix in the authorization hierarchy (as shown in previous example, which may not be modified or removed).

What happened to the root user?

Who replaces the roles of the root user?

You have the option of disabling the root access to the system and performing all tasks through one or more user accounts.

AIX V6 has three pre-defined roles assigned to three pre-defined users:

  • ISSO, the Information System Security Officer
  • SO, the System Operator
  • SA, the Security Administrator

The roles and authorizations of these users are defined in the following table:

Table 1. The pre-defined roles for the pre-defined users
  • Establishing and maintaining security policy
  • Setting passwords for user
  • Network configuration
  • Device configuration
  • System shutdown reboot
  • File system backup, restore, and quotas
  • System error logging, trace, and statistics
  • Workload administration
  • User administration excluding password
  • Filesystem administration
  • Software Installation and Update
  • Network Daemon management and device allocation

Commands and examples

The following table shows the command details in the order of how authorization and roles can be used.

Table 2. Command details
Creating authorizationmkauth (auth_name) OR smitty rbac-> Authorizations-> Add an Authorization ->Authorization Name
Verifying authorizationlsauth
How to associate a command with authorization: setsecattr -c accessauths= (auth_name) (command)
Creating Rolesmkrole authorizations= (auth_name) (role name)
How to associate the role to a user?chuser roles=(role_name) (user name)

Update the kernel tables using setkst

When the roles become active?rolelist -a [To verify the roles associated with the user with which the session is logged in]

swrole (role_name) [switch to activate the role ]

rolelist -e [To verify which role is active in the session]

Use the following example to understand the command:

How to execute the shutdown command as testuser
Step A: Creating and assigning (user defined) Authorization and Roles:
	mkauth test_auth
	setsecattr -c accessauths=test_auth shutdown
	mkrole authorizations=test_auth test_role
	chuser roles=test_role testuser

Step B: Execution

	Login as  testuser
	Switch to the role test_role using the following command:
	swrole test
	(prompts for testuser password )
	verify whether the testuser has the role using the following command:
	rolelist -e
	This displays the role associated as test_role
	Execute shutdown command

So far, I have shown how authorization and roles are used. The previous example explains how a non-root user can be given authorization to execute commands such as shutdown. This example is shown to explain the usage of RBAC. Giving authority to a non-root user to execute commands like shutdown is not suggested or recommended. Further, following this example shows how creating the user and setting the password for the user is not a single-user responsibility. You need more than one role (users) to create and set a password for the user.

How to create, modify, and set the password of a user
1.	login as isso
2.	swrole isso
3.	mkuser (user_name)
4.	login as so
5.	swrole so
6.	passwd (user_name)

This shows how the roles and authentications are distributed and how it is difficult to tamper the activities without the proper authorization.

How to mount a file system
1.	login as isso
	a.	swrole isso
2.	mount the filesystem
	a.	mount: Write permission is required to mount over /mnt.  - FAILS
3.	login as so
	a.	swrole so
	b.	mount the filesystem
	c.	verify the mount with df command.    - SUCCEEDS

In this way, you delegate the root responsibility to other users and reduce the security risk.

To summarize, authorizations can be assigned to an executable command. Roles are assigned to users and users having the defined role should be able to execute. On top of RBAC Authorization, it checks for DAC permission. To bypass DAC, privileges are required.


So far, you have seen how authorization and roles play a role in enhancing the security of the system.

Now, you will see how privilege is part of this security system.

  • Privileges are for the process to bypass certain (kernel) restrictions while executing an authorized command.
  • Privileges are for the commands and process to access the files, even if it has the required authorization.
  • Privileges provide device access control.

In short, the operating system uses authorization to determine eligibility before performing a privileged operation like system calls.

Examples of privileges

lsconf example
lsconf  -  is not a privileged command, it has no authorization 
to perform a privileged operation.
Access permission as per DAC. 

It has the following DAC permission:

# ls -l 'which lsconf'
-r-xr-xr-x    2 root     system        12712 Mar 14 2008  /usr/sbin/lsconf

In this case, whoever has the DAC privilege should be able to execute lsconf. Interestingly, the lsconf command internally executes commands like bootinfo, which is a privileged command. This means that the user needs an authorization and privileges to execute bootinfo. Hence, a user who does not have the required authorization will fail to execute bootinfo.

bootinfo example
Command:  bootinfo -k   
Authorization and Privileges:
$ lssecattr -c 'which bootinfo'
/usr/sbin/bootinfo innateprivs=PV_DAC_R,
DAC permission:
$ ls -l 'which bootinfo'
-r-xr-x---    1 bin      bin           13984 Mar 14 2008  /usr/sbin/bootinfo

In this case, the user with the authorization aix.system.bootinfo, assigned through a role, should be able to execute the bootinfo command. However, DAC does not allow the file to be executed by any non-root user.

Is it possible to execute a command by a user who has the required authorization but no DAC permission?

Yes, it is possible if the process has the required privilege to execute the command. In this case, as the previous output shows, bootinfo has PV_DAC* privileges.

The following command shows the privileges associated with the shell:

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=
Editing /etc/hosts file
$ lssecattr -f /etc/hosts
"/etc/hosts" does not exist in the privileged file database.

This is not a privileged file.
Hence, whoever has DAC access should be able to edit the file.

$ ls -l /etc/hosts
-rw-rw-r--    1 root     system         1962 Mar  3 16:35 /etc/hosts

DAC shows except root user and users belong to system group, 
others do not have write access to the file

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

Hence, in this case, DAC access is followed where the non-root user has only READ permission.

Editing /etc/environment file
$ lssecattr -f /etc/environment

This is a privileged file.
$ ls -l /etc/environment
-r--r--r--    1 root     system         1907 Mar 12 22:45 /etc/environment
DAC access permission shows no one has WRITE permission. 

$ lssecattr -p $$
282824 eprivs= mprivs= iprivs= lprivs=PV_ROOT uprivs=

The shell process has the root privileges but the vi command which is used to
access the file is not privileged command. This means that vi cannot 
access the file even if a user has the required authorization,, 
to edit the file.

$ lssecattr -c 'which vi'
/usr/bin/vi does not exist in the privileged command database.

What is the requirement to edit /etc/environment file ?
(i)   User to have the required privilege
(ii)	Executing shell to have the required privilege
(iii)	Command which access the file to have the required privilege

In such cases, AIX provides a privileged vi editor called pvi which 
has the privilege to access and write into the file. 

$ lssecattr -c 'which pvi'
/usr/bin/pvi accessauths=ALLOW_ALL innateprivs=PV_PROC_PRIV,PV_DAC_R,PV_DAC_W,
  • A privileges command has the following attribute:
  • A privileges file has the following attribute:
    readauths and writeauths
  • Privileges Device has the following attribute:
    readprivs and writeprivs


This has been a tour of the RBAC features with examples and scenarios. I hope it gives you a better understanding of the advanced features in AIX, RBAC and MLS.

Table 3. Rule of thumb in RBAC
File, command, deviceYESNONONOFollows DAC permission
File, command, deviceYESYESYESNOFollows DAC permission.
File, command, deviceYESYESYESYESAuthorized user gets priority to execute privileged operations. Bypasses DAC.
  • Single-user responsibility is delegated.
  • Single-user does not have any authority to damage the system.
  • Root access can be disabled.

Contact IBM® technical support for any further assistance. Contact the author for any further clarification on this topic.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=AIX and UNIX
ArticleTitle=Role-based access control in simple steps