rbac(5) 							File Formats Manual							   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 opera-
       tion.  HP-UX RBAC database files are installed in the directory.

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

       Creates and manages role-related information in the
		      and databases.

       Creates and manages authorization information in the
		      and databases.

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

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

       Executes privileged commands for users with proper authorizations.

       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 command.  The roles are added to the database.

       2. Add authorizations using the command.  The authorizations are added to the database.

       3. Assign authorizations or subroles to the roles using the command.  The roles, subroles and authorizations are added to the database.

       4. Associate users or UNIX groups to roles using the command.  The users or groups and their corresponding roles are added to the database.

       5. Define the commands or files to edit that will be associated with authorizations using the command.  The commands are added to the data-
	  base.

       6. Check the databases using the command.

       7. The  authorized  user  can then either run privileged commands using the wrapper command or edit restricted files using the wrapper com-
	  mand.

       The wrapper command determines what authorization is required for a given command.  This authorization-command information  is  defined	in
       the database file.  consults the and 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 command, and refer to the section in privrun(1M) for information about the database file.

       The wrapper command works similarly to the command by determining the required authorization needed to edit a given file.  This	authoriza-
       tion-file  information  is defined in the database file.  consults the and 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 command, and refer to the section in privedit(1M) for information about the database file.

DATABASES

       In each of the HP-UX RBAC databases, white space is ignored within an entry.  (This excludes the newline (
) 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:

       o
       o
       o
       o
       o

       There  are  two	HP-UX RBAC database files which define valid roles and authorizations.	The database defines valid roles, and the 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.   maps	users  or  UNIX  groups  to  their
       assigned role(s).  defines a set of authorizations or subroles for each role.

       The database associates commands or files with authorizations.

       The database associates commands or files with authorizations.

   /etc/rbac/cmd_priv
       The  file  contains the required authorizations needed to execute certain commands or edit certain files.  It also has the resulting privi-
       leges (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 or 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) : 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.)   and  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 or 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 database.

   /etc/rbac/roles
       The  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 file by authorized users using the command (see roleadm(1M)).

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

       These fields are defined as follows:

	      Field	  Description

	      rolename	  The name of a role.  For example, administrator, accountant, engineer, manager, etc.

	      (Optional)  Either an optional simple comment or an optional uri to a
			  detailed description of the role.

       For example:

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

   /etc/rbac/auths
       The 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 file by authorized users using the command (see authadm(1M)).

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

       These fields are defined as follows:

	      Field	  Description

	      operation   Denotes an action that can be performed on an object.  For example, is the operation of adding a printer.  is the opera-
			  tion 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.

	      (Optional)  Either an optional simple comment or an optional uri to a detailed
			  description of the role.

       For example:

       Note:  The operations specified in 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 database defines the roles allowed for each specified user or UNIX group.

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

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

       These fields are used as follows:

	      Field	  Description

	      A valid user name or UNIX group name.
			  Group names must begin with the ampersand

	      role	  A valid role name defined in More than one role may be specified for a user or group, if they separated by commas.

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

   /etc/rbac/role_auth
       The  file  defines  the	authorizations	and/or	subroles  for each specified role.  Each authorization is specified in the form of (opera-
       tion, object) pairs.  The authorization pairs are defined in the 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 database file.  No recursive role definition is permitted.  For example, if "role1" has a
       subrole of "role2", and if users "role1" to "role2", this will cause a recursive definition of both "role1" and "role2",  and  the  command
       will fail.

       Authorized users can use the command to specify the authorizations and/or subroles for each role in (Refer to authadm(1M) for more informa-
       tion).

       All authorizations and/or subroles associated with a role must be specified in a single entry.  This entry can be more than one line;  how-
       ever,  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:

	      (operation, object) subrole...

	      (operation, object)...

	      (operation, object)...

	      subrole...

       These fields are defined as follows:

	      Field	  Description

	      role	  A valid role, as defined in

	      operation   A specific operation that can be performed on an object.  For example, is the operation of adding a printer.	Or, 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 It is assigned to another role.

       The following line states that the role of has authorization of which means that the operation, can access the object, also has the ability
       to add and delete system users.

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

       The has authorization to perform 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 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 database file) can edit 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:

	      object

       These fields are defined as follows:

	      Field	  Description

	      role	  A valid role, as defined in

	      operation   A specific operation that can be performed on an object.  For example, is the operation of adding a printer.	Or, 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 with authorization of The role with authorization to perform on all objects is also spec-
       ified 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 command.

       1.     Add a role named UserAdmin to the roles database:

	      The above command adds the UserAdmin role to the database.

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

       3.     Add an authorization named to the auths database.  The operation is and the object is

	      In the above example, the object is not specified and therefore defaults to which means that the operation applies to  ALL  objects.
	      The is added to the database.

       4.     Assign the authorization, to the role.

	      The above command adds the following entry to the database:

       5.     Assign the role to user

	      The above command adds the following entry in the database: "John: UserAdmin"

       6.     Add the command to the database:

	      The above command adds the following entry to the database:

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

       8.     Now  non-root  user  John  has been associated with the UserAdmin role.  The UserAdmin role has been assigned an authorization named
	      which is the needed authorization for executing as per the entry added in the database.  Non-root user John can now run using to add
	      regular users to the system as follows:

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

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

FILES

       Database containing definitions of all valid authorizations.

       Database containing the authorization to execute specified commands or
	      edit specific files, and the privileges to alter UID and GID for command execution.

       Database containing all valid definitions of all roles.

       Database defining the authorizations and/or subroles for each role.

       Database specifying the roles for each specified user or UNIX group.

       Database containing a list of roles and associated authorizations to be audited.

SEE ALSO

       authadm(1M), cmdprivadm(1M), privrun(1M), privedit(1M), rbacdbchk(1M), roleadm(1M), privileges(5), compartments(5).

																	   rbac(5)