Using role-based access control with the Virtual I/O Server

Authorizations

The Virtual I/O Server creates authorizations that closely emulate the authorizations of the AIX® operating system. The authorizations emulate naming conventions and descriptions, but are only applicable to the Virtual I/O Server specific requirements. By default, the padmin user is granted all the authorizations on the Virtual I/O Server, and can run all the commands. The other types of users (created by using the mkuser command) retain their command execution permissions.

The mkauth command creates a new user-defined authorization in the authorization database. You can create authorization hierarchies by using a dot (.) in the auth parameter to create an authorization of the form ParentAuth.SubParentAuth.SubSubParentAuth.... All parent elements in the auth parameter must exist in the authorization database before the authorization is created. The maximum number of parent elements that you can use to create an authorization is eight.

You can set authorization attributes when you create authorizations through the Attribute=Value parameter. Every authorization that you create must have a value for the id authorization attribute. If you do not specify the id attribute using the mkauth command, the command automatically generates a unique ID for the authorization. If you specify an ID, the value must be unique and greater than 15000. The IDs 1 - 15000 are reserved for system-defined authorizations.

The following table lists the authorizations corresponding to the Virtual I/O Server commands. The vios and subsequent child authorizations, for example, vios and vios.device are not used. If a user is given a role that has either the parent or subsequent child authorization, for example, vios or vios.device, that user will have access to all the subsequent children authorizations and their related commands. For example, a role with the authorization vios.device, gives the user access to all vios.device.config and vios.device.manage authorizations and their related commands.

Roles

The Virtual I/O Server retains its current roles and will have the appropriate authorizations assigned to the roles. Additional roles that closely emulate the roles in the AIX operating system can be created. The roles emulate naming conventions and descriptions, but are only applicable to the Virtual I/O Server specific requirements. Users cannot view, use, or modify any of the default roles in the AIX operating system.

The following roles are the default roles in the AIX operating system. These roles are unavailable to the Virtual I/O Server users, and are not displayed.

• AccountAdmin
• BackupRestore
• DomainAdmin
• FSAdmin
• SecPolicy
• SysBoot
• SysConfig
• isso
• sa
• so

The following roles are the default roles in the Virtual I/O Server:

• Admin
• DEUser
• PAdmin
• RunDiagnostics
• SRUser
• SYSAdm
• ViewOnly

The mkrole command creates a role. The newrole parameter must be a unique role name. You cannot use the ALL or default keywords as the role name. Every role must have a unique role ID that is used for security decisions. If you do not specify the id attribute when you create a role, the mkrole command automatically assigns a unique ID to the role.

Privileges

A Privilege is an attribute of a process through which the process can bypass specific restrictions and limitations of the system. Privileges are associated with a process and are acquired by running a privileged command. Privileges are defined as bit-masks in the operating system kernel and enforce access control over privileged operations. For example, the privilege bit PV_KER_TIME might control the kernel operation to modify the system date and time. Nearly 80 privileges are included with the operating system and provide granular control over privileged operations. You can acquire the least privilege required to perform an operation through division of privileged operations in the kernel. This feature leads to enhanced security because a process hacker can only get access to one or two privileges in the system, and not to root user privileges.

Authorizations and roles are a user-level tool to configure user access to privileged operations. Privileges are the restriction mechanism used in the operating system kernel to determine if a process has authorization to perform an action. Hence, if a user is in a role session that has an authorization to run a command, and that command is run, a set of privileges are assigned to the process. There is no direct mapping of authorizations and roles to privileges. Access to several commands can be provided through an authorization. Each of those commands can be granted a different set of privileges.

The following table lists the commands related to role-based access control (RBAC).