rbac(5)

NAME

rbac: RBAC — role-based access control

DESCRIPTION

RBAC (Role-Based Access Control) is an alternative to the all-or-nothing security model of traditional root user-based systems. With RBAC, an administrator can assign roles to non-root users or UNIX groups. Each role has authorizations composed of an operation and object, where the operation is an action that can be performed on an object, and the object is an object the user can access with a given operation. HP-UX RBAC database files are installed in the /etc/rbac directory.

The following is a list of the HP-UX RBAC commands, presented in the sequence they are typically used:

roleadm

Creates and manages role-related information in the roles, user_role, and role_auth databases.

authadm

Creates and manages authorization information in the auths, role_auth, and cmd_priv databases.

cmdprivadm

Creates and manages a command's authorization and privilege information in the cmd_priv database.

rbacdbchk

Verifies the syntax and cross references between of all the HP-UX RBAC databases and performs cross reference checks between all the RBAC databases.

privrun

Executes privileged commands for users with proper authorizations.

privedit

Allows users with the proper authorization to invoke an editor for editing restricted files.

The following are the main steps in configuring roles and authorizations are:

1.: Create roles using the roleadm command. The roles are added to the /etc/rbac/roles database.
2.: Add authorizations using the authadm command. The authorizations are added to the /etc/rbac/auths database.
3.: Assign authorizations or subroles to the roles using the authadm command. The roles, subroles and authorizations are added to the /etc/rbac/role_auth database.
4.: Associate users or UNIX groups to roles using the roleadm command. The users or groups and their corresponding roles are added to the /etc/rbac/user_role database.
5.: Define the commands or files to edit that will be associated with authorizations using the cmdprivadm command. The commands are added to the /etc/rbac/cmd_priv database.
6.: Check the databases using the rbacdbchk command.
7.: The authorized user can then either run privileged commands using the privrun wrapper command or edit restricted files using the privedit wrapper command.

The privrun wrapper command determines what authorization is required for a given command. This authorization-command information is defined in the /etc/rbac/cmd_priv database file. privrun consults the roles and auths database files to decide whether the user calling privrun has the necessary authorization based on the roles assigned to the user directly or indirectly via a UNIX group.

See privrun(1M) for details on the privrun command, and refer to the /etc/rbac/cmd_priv section in privrun(1M) for information about the cmd_priv database file.

The privedit wrapper command works similarly to the privrun command by determining the required authorization needed to edit a given file. This authorization-file information is defined in the /etc/rbac/cmd_priv database file. privedit consults the roles and auths database files and decides whether the user calling privedit has the necessary authorization to edit the file based on the roles assigned to the user directly or indirectly via UNIX group.

See privedit(1M) for details on the privedit command, and refer to the /etc/rbac/cmd_priv section in privedit(1M) for information about the cmd_priv database file.

DATABASES

In each of the HP-UX RBAC databases, white space is ignored within an entry. (This excludes the newline (\n) character, which is used as a record separator.)

All of the fields in the HP-UX RBAC databases are case sensitive.

The following is a list of the HP-UX RBAC databases are currently provided:

/etc/rbac/cmd_priv
/etc/rbac/roles
/etc/rbac/auths
/etc/rbac/user_role
/etc/rbac/role_auth

There are two HP-UX RBAC database files which define valid roles and authorizations. The /etc/rbac/roles database defines valid roles, and the /etc/rbac/auths database defines valid authorizations. The authorizations are specified in the form of (operation, object) pairs.

Two additional database files assign roles to users or UNIX groups and authorizations to roles. /etc/rbac/user_role maps users or UNIX groups to their assigned role(s). /etc/rbac/role_auth defines a set of authorizations or subroles for each role.

The /etc/rbac/cmd_priv database associates commands or files with authorizations.

/etc/rbac/cmd_priv

The /etc/rbac/cmd_priv file contains the required authorizations needed to execute certain commands or edit certain files. It also has the resulting privileges (real and effective UID and GID, Fine grained privileges, and compartment) associated with the command. If the user is required to re-authenticate prior to successful authorization, a PAM service name is specified in this file indicating how privrun or privedit should identify itself to PAM.

The file contains any number of entries, where each entry is specified on a single line and in the following format:

command | file: arguments : (operation, object) : ruid/euid/rgid/ egid : compartment : privs : pam service : flags

These fields are explained in privrun(1M) and privedit(1M).

There may be multiple entries with the same command line (with different authorizations required and resulting privileges.) privrun and privedit evaluate each entry sequentially in the order specified in the file, continuing on to the next entry only if the user does not have the required authorization.

If the user desires a particular entry, they can use command-line options with privrun or privedit to specify the set of privileges or authorization for a particular entry. Note that only authorizations can be specified to privedit.

See privrun(1M) or privedit(1M) for more information on /etc/rbac/cmd_priv database.

/etc/rbac/roles

The /etc/rbac/roles database contains definitions of all valid roles in the system. An administrator must define new roles in this file before the roles can be assigned to a user.

The roles are added and removed from the /etc/rbac/roles file by authorized users using the roleadm command (see roleadm(1M)).

The /etc/rbac/roles database contains any number of entries, where each entry is defined on a single line in the following format:

rolename[:comment]

These fields are defined as follows:

Field: Description
rolename: The name of a role. For example, administrator, accountant, engineer, manager, etc.
[:comment]: (Optional) Either an optional simple comment or an optional uri to a detailed description of the role.

For example:

administrator:uri=http://www.site.com/adm.html 

The following example has just the role name, no comment or optional uri:

SecurityOfficer 

/etc/rbac/auths

The /etc/rbac/auths database contains definitions of all valid authorizations in the form of (operation, object) pairs in the system. An administrator must define new (operation, object) pairs in this file before the (operation, object) pairs can be assigned to a role.

The authorizations are added and removed from the /etc/rbac/auths file by authorized users using the authadm command (see authadm(1M)).

The /etc/rbac/auths database contains any number of entries, where each entry is defined on a single line in the following format:

(operation, object)[:comment]

These fields are defined as follows:

Field: Description
operation: Denotes an action that can be performed on an object. For example, hpux.printer.add is the operation of adding a printer. hpux.printer.delete is the operation of deleting a printer.
object: The object the user can access with a given operation. If * is specified, all objects can be accessed by the operation.
[:comment]: (Optional) Either an optional simple comment or an optional uri to a detailed description of the role.

For example:

(hpux.printer.add, bldg7printer): Add printers in building 7.
(hpux.printer.delete, *): uri=http://foo.bar.com/printerauths.htm 
(hpux.fs.backup, /dev/rdsk/c0t1d0): Backup physical disk 1 

Note: The operations specified in /etc/rbac/auths file must be fully-qualified and cannot use wildcards; however, the objects can be be specified with a wildcard using the asterisk character (*). Authorizations that contain wildcard operations are validated using a match operation. At least one operation must match the wildcard to assign the authorization to the role.

/etc/rbac/user_role

The /etc/rbac/user_role database defines the roles allowed for each specified user or UNIX group.

The user to role definitions are added and removed in the /etc/rbac/user_role file by authorized users using the roleadm command (see roleadm(1M)).

The /etc/rbac/user_role database contains any number of entries, where each entry is defined on a single line in the following format:

user-name | &group-name: role[,role...]

These fields are used as follows:

Field: Description
user-name | &group-name: A valid user name or UNIX group name. Group names must begin with the ampersand (&).
role: A valid role name defined in /etc/rbac/roles. More than one role may be specified for a user or group, if they separated by commas.

The example below shows that user Michael has roles of an administrator and a programmer. Also, it shows user Jenny has the SecurityOfficer role assigned. Lastly, it shows that the UNIX group users has the RegularUser role assigned:

# roleadm list 
Michael: Administrator, Programmer 
Jenny: SecurityOfficer 
&users: RegularUser 

/etc/rbac/role_auth

The /etc/rbac/role_auth file defines the authorizations and/or subroles for each specified role. Each authorization is specified in the form of (operation, object) pairs. The authorization pairs are defined in the /etc/rbac/auths database file.

A subrole is just another role with authorizations. When a subrole is assigned to a role, the role inherits all the authorizations of the subrole. The subrole name must be defined in the /etc/rbac/roles database file. No recursive role definition is permitted. For example, if "role1" has a subrole of "role2", and if users roleassign "role1" to "role2", this will cause a recursive definition of both "role1" and "role2", and the roleassign command will fail.

Authorized users can use the authadm command to specify the authorizations and/or subroles for each role in /etc/rbac/role_auth (Refer to authadm(1M) for more information).

All authorizations and/or subroles associated with a role must be specified in a single entry. This entry can be more than one line; however, each individual authorization pair must not exceed one line. Lines that begin with alphanumeric characters followed by semicolons (:) are considered new entries. The entries are in the following format:

role: (operation, object) subrole...

role: (operation, object)...

role: subrole (operation, object)...

role: subrole subrole...

These fields are defined as follows:

Field

Description

role

A valid role, as defined in /etc/rbac/roles.

operation

A specific operation that can be performed on an object. For example, hpux.printer.add is the operation of adding a printer. Or, hpux.printer.* is the operation of either adding or deleting a printer.

object

The object the user can access. If * is specified, all objects can be accessed by the operation.

More than one (operation, object) pair may be specified for a role.

subrole

A valid role, as defined in /etc/rbac/roles. It is assigned to another role.

The following line states that the role of SecurityOfficer has authorization of (hpux.passwd, /etc/passwd) which means that the operation, hpux.passwd, can access the object, /etc/passwd. SecurityOfficer also has the ability to add and delete system users.

SecurityOfficer:    (hpux.passwd, /etc/passwd)
                    (hpux.user.add, *)
                    (hpux.user.del, *)

The PrinterAdm has authorization to perform hpux.printer.add on all objects.

PrinterAdm:         (hpux.printer.add, *)

The Administrator has subroles SecurityOfficer and PrinterAdm, and therefore, has all the authorizations of both subroles as shown in the preceding examples.

Administrator:      SecurityOfficer PrinterAdm

/etc/rbac/aud_filter

The /etc/rbac/aud_filter file defines role and authorization audit filtering. Audit records will be generated for users whose role and associated authorization is found in this file. If a user's role and associated authorization is not found in the file, then no audit records specific to role and authorization will be generated. Each authorization is specified in the form of operation, object pairs.

Authorized users (as specified in /etc/rbac/cmd_priv database file) can edit /etc/rbac/aud_filter to specify the role and authorization to be audited.

All authorizations associated with a role must be specified in a single entry. Only one authorization may be specified per role. The entries are of the following format:

role, operation, object

These fields are defined as follows:

Field: Description
role: A valid role, as defined in /etc/rbac/roles.
operation: A specific operation that can be performed on an object. For example, hpux.printer.add is the operation of adding a printer. Or, hpux.printer.* is the operation of either adding or deleting a printer.
object: The object the user can access. If * is specified, all objects can be accessed by the operation.

The following line specifies auditing the role of SecurityOfficer with authorization of (hpux.passwd, /etc/passwd). The PrinterAdm role with authorization to perform hpux.printer.add on all objects is also specified for auditing.

SecurityOfficer, hpux.passwd, /etc/passwd
PrinterAdm, hpux.printer.add, *

EXAMPLES

The following example shows how a root user uses the RBAC administrative commands to allow non-root user John to execute the /usr/sbin/useradd command.

1.

Add a role named UserAdmin to the roles database:

# /usr/sbin/roleadm add UserAdmin

The above command adds the UserAdmin role to the /etc/rbac/roles database.

2.

List defined authorizations in the system to determine what authorizations are available.

# /usr/sbin/authadm list sys

3.

Add an authorization named (hpux.admin.useradd,*) to the auths database. The operation is hpux.admin.useradd and the object is *.

# /usr/sbin/authadm add hpux.admin.useradd

In the above example, the object is not specified and therefore defaults to *, which means that the operation applies to ALL objects. The (hpux,admin.useradd,*) is added to the /etc/rbac/auths database.

4.

Assign the authorization, (hpux.admin.useradd,*), to the UserAdmin role.

# /usr/sbin/authadm assign UserAdmin hpux.admin.useradd

The above command adds the following entry to the /etc/rbac/role_auth database: UserAdmin:(hpux.admin.useradd,*)

5.

Assign the role UserAdmin to user John:

# /usr/sbin/roleadm assign John UserAdmin

The above command adds the following entry in the /etc/rbac/user_role database: "John: UserAdmin"

6.

Add the command /usr/sbin/useradd to the cmd_priv database:

# /usr/sbin/cmdprivadm add cmd=/usr/sbin/useradd

op=hpux.admin.useradd ruid=0 euid=0

The above command adds the following entry to the /etc/rbac/cmd_priv database:

/usr/sbin/useradd:dflt:(hpux.admin.useradd,*):0/0//:dflt:dflt:dflt:

7.

Check to see if syntax and entries in the RBAC database are valid:

# /usr/sbin/rbacdbchk

8.

Now non-root user John has been associated with the UserAdmin role. The UserAdmin role has been assigned an authorization named (hpux.admin.useradd, *) which is the needed authorization for executing /usr/sbin/useradd as per the entry added in the cmd_priv database. Non-root user John can now run /usr/sbin/useradd using privrun to add regular users to the system as follows:

# /usr/bin/privrun /usr/bin/useradd new_user

AUDITING

These commands, privrun(1M), roleadm(1M), authadm(1M) and cmdprivadm(1M) all generate audit records. The audit records include a caller's username, UID, role, authorizations, object, time of the event, success or failure of the event, etc.

You can provide an audit filter database file (/etc/rbac/aud_filter) which allows a user to specify the role and the authorization (operation, object) to be audited. Role-to-authorization audit records will be generated only if the caller's role and authorization matches one of the entries in the /etc/rbac/aud_filter database.

If the audit filter database file does not exist, or is not accessible, then the audit records will still be generated. However, if the audit filter database file exists, but is empty, then no audit records will be generated.

The following is an example of how to generate and display the audit records for roleadm:

# audevent -Pfe admin 
# audsys -f 
# audsys -n -c /tmp/aud.out -s 2048 
# roleadm add new_role_1 
# audsys -f 
# audisp /tmp/aud.out 

See audit(5), audevent(1M), audsys(1M), and audisp(1M) to learn more about generating and displaying audit records.

FILES

/etc/rbac/auths: Database containing definitions of all valid authorizations.
/etc/rbac/cmd_priv: Database containing the authorization to execute specified commands or edit specific files, and the privileges to alter UID and GID for command execution.
/etc/rbac/roles: Database containing all valid definitions of all roles.
/etc/rbac/role_auth: Database defining the authorizations and/or subroles for each role.
/etc/rbac/user_role: Database specifying the roles for each specified user or UNIX group.
/etc/rbac/aud_filter: Database containing a list of roles and associated authorizations to be audited.

rbac(5)

Technical documentation

» Table of Contents

» Index

NAME

DESCRIPTION

DATABASES

/etc/rbac/cmd_priv

/etc/rbac/roles

/etc/rbac/auths

/etc/rbac/user_role

/etc/rbac/role_auth

/etc/rbac/aud_filter

EXAMPLES

AUDITING

FILES

SEE ALSO