Role-based access control in simple steps

A step-by-step approach with examples

Rajesh K. Jeyapaul June 23, 2009

Security is a major concern of operating systems. This article series provides an understanding
of the new features on AIX®, role-based access control and multi-level security. Part 1 of this
series discusses AIX role-based access control (RBAC) and how roles, responsibilities, and the
authorization of a root user can be delegated to more than one user.

Introduction
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

Traditional
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.

© Copyright IBM Corporation 2009 Trademarks

Role-based access control in simple steps Page 1 of 9
developerWorks® ibm.com/developerWorks/

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.

RBAC
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.

Role-based access control in simple steps Page 2 of 9

ibm.com/developerWorks/ developerWorks®

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?

Role-based access control in simple steps Page 3 of 9

developerWorks® ibm.com/developerWorks/

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

User Roles Responsibility

ISSO ISSO • Establishing and maintaining security

policy
• Setting passwords for user
• Network configuration
• Device configuration

SO SO • System shutdown reboot

• File system backup, restore, and quotas
• System error logging, trace, and
statistics
• Workload administration

SA SA • 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

Tasks Command

Creating authorization mkauth (auth_name) OR smitty rbac-> Authorizations-> Add an

Authorization ->Authorization Name

Verifying authorization lsauth

How to associate a command with authorization: setsecattr -c accessauths= (auth_name) (command)

Creating Roles mkrole 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]

Role-based access control in simple steps Page 4 of 9

ibm.com/developerWorks/ developerWorks®

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
setkst

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.

Role-based access control in simple steps Page 5 of 9

developerWorks® ibm.com/developerWorks/

Privileges
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 accessauths=aix.system.boot.info innateprivs=PV_DAC_R,
PV_DAC_W,PV_DEV_CONFIG,PV_KER_RAS,PV_MAC_,PV_MIC secflags=FSF_EPS
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?

Role-based access control in simple steps Page 6 of 9

ibm.com/developerWorks/ developerWorks®

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
/etc/environment writeauths=aix.security.user

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, aix.security.user,
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 aix.security.user
(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,
PV_DAC_X,PV_DAC_O

• A privileges command has the following attribute:

Role-based access control in simple steps Page 7 of 9

developerWorks® ibm.com/developerWorks/

accessauths,innateprivs,authprivs,inheritprivs
• A privileges file has the following attribute:
readauths and writeauths
• Privileges Device has the following attribute:
readprivs and writeprivs

Summary
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

- DAC Authorization Role Privileges Comments

File, command, YES NO NO NO Follows DAC

device permission

File, command, YES YES YES NO Follows DAC

device permission.

File, command, YES YES YES YES Authorized user gets

device 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.

Role-based access control in simple steps Page 8 of 9

ibm.com/developerWorks/ developerWorks®

Related topics
• "Documentation:AIX6.1 Information"
• "Redbook:AIX V6 Advanced Security Features Introduction and Configuration"

© Copyright IBM Corporation 2009

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Role-based access control in simple steps Page 9 of 9