rbac man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

rbac(5)								       rbac(5)

NAME
       rbac: RBAC - role-based access control

DESCRIPTION
       RBAC  (Role-Based Access Control) is an alternative to the all-or-noth‐
       ing 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 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 authoriza‐
       tions are:

       1. Create roles using the command.  The roles are added	to  the	 data‐
	  base.

       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 data‐
	  base.

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

       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 (\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  pro‐
       vided:

       ·
       ·
       ·
       ·
       ·

       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 privileges
       (real and effective UID and GID, Fine grained privileges, and  compart‐
       ment)  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 differ‐
       ent 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 autho‐
       rization.

       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 (opera‐
       tion, 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 operation of deleting a printer.

	      object	  The object the user can access with a	 given	opera‐
			  tion.	  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 wild‐
       card 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 data‐
       base 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 infor‐
       mation).

       All authorizations and/or subroles associated with a role must be spec‐
       ified  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  for‐
       mat:

	      (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 speci‐
			  fied 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 specified
       for auditing.

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

EXAMPLES
       The  following  example shows how a root user uses the RBAC administra‐
       tive 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  cmdpri‐
       vadm(1M) all generate audit records.  The audit records include a call‐
       er'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)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net