cmdprivadm(1m) [hpux man page]
cmdprivadm(1M) cmdprivadm(1M) NAME
cmdprivadm - noninteractive editing of a command's authorization and privilege information in the privrun database SYNOPSIS
DESCRIPTION
is a noninteractive command that allows user with appropriate permission to add or delete a command and its privileges in the Role-Base Access Control (RBAC) database, See privrun(1M) for more details on this file. When adding a line to the database, sets fields that are not specified a default value. When deleting a line, the lines matching all the given pairs will be deleted. That is, if all fields specified match, the entry will be deleted. Appends a line as specified in pairs in the file. Deletes a line as specified in pairs from file. HP recommends that only the and commands be used to edit and view the RBAC databases; do not edit the RBAC files directly. See rbac(5) for information on the RBAC databases. Options The following options are valid pairs for command should include the full path name of the command. There can be one or more arguments following the command. filename should specify the full path name of a file name. Specifies the operation. Specifies the object. Specifies the real user ID (ruid). Specifies the effective user ID (euid). Specifies the real group ID (rgid). Specifies the effective group ID (egid). Specifies the compartment. Specifies the privileges. Specifies the PAM service name to reauthenticate under. See pam.conf(4) for a list of PAM services. Specifies the flags. Note: You must enclose values that contain the space character, or any characters that may be interpreted by the shell, with single quotes. For example, if the has one or more arguments, enclose them with single quotes: Authorizations: In order to invoke the user must either be root, (running with effective UID of 0), or have the appropriate authorizations. The following is a list of the required authorizations for running with particular options: Allows user to run with options. Allows user to run with options. EXTERNAL INFLUENCES
Environment Variables determines the language in which messages are displayed. International Code Set Support Single-byte character code set is supported. RETURN VALUE
Upon completion, returns one of the following values: Success. Failure. An appropriate error message is printed on standard error. EXAMPLES
The following commands add entries into the file: The following commands delete entries from the file: FILES
Database containing valid definitions of all roles. Database containing definitions of all valid authorizations. Database specifying the roles allowed for each specified user. Database defining the authorizations for each specified role. Database containing the authorization to execute specified commands, and the privileges to alter UID and GID for command execution. SEE ALSO
authadm(1M), privrun(1M), rbacdbchk(1M), roleadm(1M), rbac(5). cmdprivadm(1M)
Check Out this Related Man Page
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)