lpacl Information

Purpose

Provides general information about protecting the least-privilege (LP) commands resource class and its resources using access controls that are provided by the resource monitoring and control (RMC) subsystem.

Description

RMC controls access to all of its resources and resource classes through access control lists (ACLs), using two different ACL implementations. The implementation that RMC uses depends on which class is involved. The two major differences between the implementations are in: 1) the mechanisms with which ACLs are viewed and modified and 2) whether ACLs are associated with individual resources.

RMC implements access controls for its resources and resource classes in the following ways:
  1. Through ACLs that are defined by resource class stanzas in the ctrmc.acls file.

    You can view and modify these ACLs by editing the ctrmc.acls file. Use a stanza to define an ACL that applies to a class or to define an ACL that applies to all of the resources in a class.

    RMC uses this method for all of its resources and resource classes, except for the IBM.LPCommands resource class and its resources.

    For more information about the ctrmc.acls file and the ACLs it defines, see the RSCT: Administration Guide.

  2. Through ACLs that are associated with resources and a resource class within the RMC subsystem.

    You can view and modify these ACLs using LP commands. You can define an ACL that applies to a class or an ACL that applies to an individual resource of a class.

    RMC uses this method for the IBM.LPCommands resource class and its resources.

    This file provides information about ACLs that are specific to the IBM.LPCommands resource class and its resources.

The LP resource manager uses the IBM.LPCommands resource class to define LP resources. These resources represent commands or scripts that require root authority to run, but typically the users who need to run these commands do not have root authority. By using the LP resource manager commands, users can run commands that require root authority. The LP resource manager commands are:
chlpcmd
Changes the read/write attribute values of an LP resource
lphistory
Lists or clears a certain number of LP commands that were previously issued during the current RMC session
lslpcmd
Lists information about the LP resources on one or more nodes in a domain
mklpcmd
Defines a new LP resource to RMC and specifies user permissions
rmlpcmd
Removes one or more LP resources from the RMC subsystem
runlpcmd
Runs an LP resource
For descriptions of these commands, see RSCT for AIX 5L™: Technical Reference. For information about how to use these commands, see the RSCT: Administration Guide.
Because each LP resource can define a unique command, RMC implements ACLs for the IBM.LPCommands class that allow access to be controlled at the individual resource level and at the class level. RSCT provides a set of commands that you can use to list and modify the ACLs for the IBM.LPCommands class and its resources. The LP ACL commands are:
chlpclacl
Changes the Class ACL
chlpracl
Changes the Resource ACL
chlpriacl
Changes the Resource Initial ACL
chlprsacl
Changes the Resource Shared ACL
lslpclacl
Lists the Class ACL
lslpracl
Lists the Resource ACL
lslpriacl
Lists the Resource Initial ACL
lslprsacl
Lists the Resource Shared ACL
mklpcmd
Defines a new LP resource to RMC and specifies user permissions
For descriptions of these commands, see RSCT for AIX 5L: Technical Reference. For information about how to use these commands, see the RSCT: Administration Guide.

Basic ACL Structure

Typically, an ACL is composed of a list of ACL entries. Each ACL entry specifies an identity and a set of permissions granted to that identity. The complete list of ACL entries determines how the ACL controls access to the associated class or resource.

A resource-associated ACL can refer to another ACL instead of containing a list of ACL entries itself. When a resource-associated ACL refers to another ACL, the set of ACL entries in the referenced ACL controls access to the resource.

Types of ACLs

Four types of ACLs control access to the IBM.LPCommands class and its resources, as follows:
Class ACL
A Class ACL controls access to class operations on one node. You need to have been granted specific permissions to perform class operations, such as listing class attributes, creating class resources, and deleting class resources.

A Class ACL is composed of a list of ACL entries. The list of ACL entries controls access to class operations on the node. If the list is empty, no identity is permitted to perform class operations on the node.

When you try to perform a class operation on the IBM.LPCommands class on a node — creating a new resource, for example — RMC checks the Class ACL on that node to verify that you have the required permission to perform the operation. If you do not have the required permission, the operation is rejected.

One Class ACL exists on each node for the IBM.LPCommands class. Each node's Class ACL controls access to all IBM.LPCommands class operations on that node.

Resource ACL
A Resource ACL controls access to resource operations for one LP resource. You need to have been granted specific permissions to perform resource operations, such as listing resource attributes, modifying resource attributes, and running resource commands.

A Resource ACL can be composed of a list of ACL entries. In this case, the list of ACL entries controls access to resource operations for that resource. If the list is empty, no identity is permitted to perform resource operations for the resource.

A Resource ACL can refer to the Resource Shared ACL instead of containing a list of ACL entries itself. In this case, the list of ACL entries in the Resource Shared ACL controls access to resource operations for the resource. If the list is empty, no identity is permitted to perform resource operations for the resource.

When you try to perform a resource operation on an LP resource — running an LP command, for example — RMC first checks the Resource ACL for the selected resource to determine whether the Resource ACL contains a list of ACL entries or whether it refers to the Resource Shared ACL. If the Resource ACL has a list of ACL entries, RMC checks that list to verify that you have the required permission to perform the operation. If you do not have the required permission, the operation is rejected.

If the Resource ACL refers to the Resource Shared ACL, RMC checks the Resource Shared ACL to verify that you have the required permission to perform the operation. If you do not have the required permission, the operation is rejected.

One Resource ACL exists for each LP resource. When a Resource ACL refers to the Resource Shared ACL, the Resource Shared ACL that is being referenced is the one on the same node as the resource.

Resource Initial ACL
A Resource Initial ACL defines the initial contents of a Resource ACL created on a node.

Because a Resource Initial ACL is used to initialize Resource ACLs, a Resource Initial ACL can contain a list of ACL entries or a reference to the Resource Shared ACL.

When a new LP resource is created, its Resource ACL is initialized as specified by the Resource Initial ACL on the node.

One Resource Initial ACL exists on each node for the IBM.LPCommands class.

Resource Shared ACL
A Resource Shared ACL can control access to resource operations for multiple resources on one node.

A Resource Shared ACL is composed of a list of ACL entries. The list of ACL entries controls access to resource operations for all of the resources on the node that refer to the Resource Shared ACL. As with the other ACL types, the list of ACL entries can be empty.

To use this ACL, place ACL entries in it as you would in a Resource ACL. Then, modify the Resource ACLs on the same node to refer to the Resource Shared ACL. Using the Resource Shared ACL, you can use one list of ACL entries to control access to multiple resources on the same node.

One Resource Shared ACL exists on each node for the IBM.LPCommands class.

ACL Entries

An RMC ACL for LP commands specifies a list of ACL entries. Each ACL entry defines a user identity and that identity's user permissions. A user identity is an authenticated network identity. The user permissions specify the access that a user has to the class or to the resources.

User Identities

In an RMC ACL entry, the user identity can be in one of the following three forms:
  1. [host:]host_user_identifier
    Specifies a host user identifier. The optional host: keyword specifies that the user identifier can be matched against a network identifier that is provided by the host-based authentication (HBA) security mechanism. If the host: keyword is omitted and the entry does not take one of the other forms described, the entry is assumed to be a host user identifier. The host user identifier can be in one of the following three forms:
    1. user_name@host_identifier

      Specifies a particular authenticated user. You can specify host_identifier in several different formats. These formats, which are the same as when the host user identifier format is specified as a host identifier alone, are described as follows.

    2. host_identifier
      Specifies any authenticated user on the host identified. The host identifier can be:
      • a fully-qualified host name.
      • a short host name.
      • an IP address.
      • the RSCT node ID. This is the 16-digit hexadecimal number, for example: 0xaf58d41372c47686.
      • the keyword LOCALHOST. This keyword is a convenient shorthand notation for the RSCT node ID of the node where the ACL exists. The LOCALHOST keyword is stored in the ACL.
      • the keyword NODEID. This keyword is a convenient shorthand notation for the RSCT node ID of the node where an ACL editing command is running. The NODEID keyword is not stored in the ACL; the node ID that the keyword represents is actually stored in the ACL..
    3. "*"

      Specifies any authenticated user on any host. The asterisk (*) must be enclosed in double quotation marks when it is specified as command input.

  2. none:mapped_user_identifier

    Specifies a mapped name, as defined in the ctsec_map.global file or the ctsec_map.local file. For information about mapped user identifiers, see the RSCT: Administration Guide.

  3. UNAUTHENT

    Specifies any unauthenticated user.

Some typical forms of a user identity are:

user@full_host_name
user@short_host_name
user@ip_address
user@node_ID
user@LOCALHOST
full_host_name
short_host_name
IP_address
node_ID
LOCALHOST
*

When you are running LP commands, the host_identifier parameter is often expected to be the RSCT node ID. You can use the NODEID keyword to represent the node ID of the node on which the command runs. To determine the node ID otherwise, enter: 
lsrsrc IBM.Host NodeIDs
To determine all of the node IDs in a management domain or a peer domain, enter: 
lsrsrc -ta IBM.Host NodeIDs NodeNameList
The node ID is displayed in decimal format. Use the hexadecimal equivalent for the host_identifier, preceded by 0x. If the nodes are in a peer domain, enter: 
lsrpnode -i

The node ID is displayed in hexadecimal. To use this value in the commands, you need to precede this value with 0x. If the CT_CONTACT environment variable is used to specify where the RMC session occurs, the host_identifier is expected to be a fully-qualified host name, a short host name, or an IP address.

User Permissions

The user permissions are expressed as a string of one or more characters, each representing a particular permission.

To compensate for the fine granularity of the permission set, RSCT provides two composite permissions. The r permission consists of individual permissions that allow "read" types of operations. The w permission consists of individual permissions that allow "write" types of operations. Most ACL entries will probably use these convenient composite permissions.

The Permission Set

The next two sections show two different views of the defined permission set. The first section describes the permission set using the composite permissions. The second section describes the permission set using the individual permissions.

Using Composite Permissions

r
Read permission.
  • To view the resource attribute values for an LP resource, you need this permission for the LP resource.
  • To view the IBM.LPCommands class attribute values, you need this permission for the IBM.LPCommands class.
  • You need this permission to list the LP ACLs.
Therefore, this permission is meaningful for any LP ACL. Read permission consists of the q, l, e, and v permissions.
w
Write permission.
  • To change the resource attribute values for an LP resource, you need this permission for the LP resource.
  • To change the class attribute values for the IBM.LPCommands class, you need this permission for the IBM.LPCommands class.
  • To create or delete LP resources, you need this permission for the IBM.LPCommands class.
Therefore, this permission is meaningful for any LP ACL. Write permission consists of the d, s, c, and o permissions.
a
Administrator permission.
  • To change the Resource ACL for an LP resource, you need this permission for the LP resource.
  • To change the Class ACL, the Resource Initial ACL, or the Resource Shared ACL, you need this permission for the IBM.LPCommands class.
Therefore, this permission is meaningful for any LP ACL.
x
Execute permission. To run an LP command that is defined in an LP resource, you need this permission for the LP resource. Therefore, this permission is meaningful for the LP Resource ACL, the Resource Initial ACL, and the Resource Shared ACL.
0
No permission. This permission denies you access to an LP resource or to the IBM.LPCommands class. Therefore, this permission is meaningful for any LP ACL.

Using Individual Permissions

q
Query permission.
  • To query the resource attribute values for an LP resource, you need this permission for the LP resource.
  • To query the class attribute values, you need this permission for the IBM.LPCommands class.
  • You need this permission to list the LP ACLs.
Therefore, this permission is meaningful for any LP ACL.
l
Enumerate permission. To list the LP resources, you need this permission for the IBM.LPCommands class. Therefore, this permission is meaningful for the Class ACL.
e
Event permission. To register, unregister, or query events, you need this permission for an LP resource or for the IBM.LPCommands class. Therefore, this permission is meaningful for any LP ACL.
v
Validate permission. You need this permission to validate that an LP resource handle still exists. Therefore, this permission is meaningful for the Resource ACL, the Resource Initial ACL, and the Resource Shared ACL.
d
Define and undefine permission. To create or delete LP resources, you need this permission for the IBM.LPCommands class. Therefore, this permission is meaningful for the Class ACL.
c
Refresh permission. To refresh the IBM.LPCommands class configuration, you need this permission for the IBM.LPCommands class. Therefore, this permission is meaningful for the Class ACL.
s
Set permission.
  • To set resource attribute values for an LP resource, you need this permission for the LP resource.
  • To set class attribute values, you need this permission for the IBM.LPCommands class.
Therefore, this permission is meaningful for any LP ACL.
o
Online, offline, and reset permission. Because LP resources do not support the online, offline, and reset operations, this permission has no meaning in LP ACLs.
a
Administrator permission.
  • To change the Resource ACL for an LP resource, you need this permission for the LP resource.
  • To change the Class ACL, the Resource Initial ACL, or the Resource Shared ACL, you need this permission for the IBM.LPCommands class.
Therefore, this permission is meaningful for any LP ACL.
x
Execute permission. To run an LP command that is defined in an LP resource, you need this permission for the LP resource. Therefore, this permission is meaningful for the LP Resource ACL, the Resource Initial ACL, and the Resource Shared ACL.
0
No permission. This permission denies you access to an LP resource or to the IBM.LPCommands class. Therefore, this permission is meaningful for any LP ACL.

Some permission characters have no meaning in certain types of ACLs. For example, the l permission has no meaning in a Resource ACL. A permission character that has no meaning in a certain type of ACL can be present in the ACL with no ill effect. For example, the l permission can be specified in an ACL entry of a Resource ACL. The presence of meaningless permissions in ACL entries is inevitable when the composite permissions are used.

In addition to the permissions that are granted explicitly by ACL entries, the root mapped identity always has query and administrator permission for ACL operations. If an ACL is set so that all access is denied, the root mapped identity can still be used to change the ACL, due to its implicit authority.

The system administrator needs to determine how ACLs should be defined for the IBM.LPCommands class and its resources. This depends on which operations users are required to perform.

Security

  • To use the LP commands that change the Class ACL, the Resource Initial ACL, and the Resource Shared ACL, you must have query and administrator permission for the IBM.LPCommands class.
  • To use the LP command that changes a Resource ACL for an LP resource, you must have query and administrator permission for the LP resource.
  • To use the LP commands that list the Class ACL, the Resource Initial ACL, and the Resource Shared ACL, you must have query permission for the IBM.LPCommands class.
  • To use the LP command that lists a Resource ACL for an LP resource, you must have query permission for the LP resource.
The Security section of each LP command description indicates which permissions are required for the command to run properly.

Examples

Some examples of how to modify the LP ACLs follow. In these examples, the commands are run on a management server for a group of nodes in a management domain. The management server is named ms_node and the managed nodes are called mc_node1, mc_node2, and so forth. In a management domain, it is most likely that the LP resources will be defined on the management server and the LP commands themselves will be targeted to the managed nodes. In these examples, the Resource Shared ACL is not used because separate permissions are desired for the individual LP resources. These examples assume that the LP resources have not yet been defined using the mklpcmd command.
  1. You want to define the lpadmin ID to be the administrator for the LP commands. This ID will have the authority to modify the LP ACLs. You also want to give this ID read and write permission to be able to create, delete, and modify the LP resources. To set this up, use the root mapped identity to run these commands on the management server: 
    chlpclacl lpadmin@LOCALHOST rwa
chlpriacl lpadmin@LOCALHOST rwa
    These commands define the lpadmin ID on the management server as having administrator, read, and write permission for the IBM.LPCommands class and for the Resource Initial ACL. The Resource Initial ACL is used to initialize a Resource ACL when an LP resource is created. Therefore, when an LP resource is created, the lpadmin ID will have administrator, read, and write permission to it.
  2. The lpadmin ID can now create LP resources that define the LP commands that are needed. See the mklpcmd command for a description on how to create the LP resources. Access to the LP resources can be defined using the mklpcmd command or the chlpracl command. When the resource is created, the Resource Initial ACL is copied to the Resource ACL. To modify the Resource ACL using the chlpracl command so that joe will be able to use the runlpcmd command for the resource named SysCmd1, the lpadmin ID runs this command on the management server: 
    chlpracl SysCmd1 joe@LOCALHOST x
    This gives joe on the management server execute permission to the SysCmd1 resource so he can use the runlpcmd command.
  3. In this example, only the lpadmin ID has permission to create, delete, and modify LP resources. Use the chlpclacl command to let other users create and delete LP resources. In this case, they need to have write access to the class. To be able to list the resources in the IBM.LPCommands class, read permission is required. Read permission on a Resource ACL allows a user to view that LP resource. Write permission on a Resource ACL allows a user to modify that LP resource. To allow joe to view the LP resource named SysCmd1, the lpadmin ID runs this command on the management server: 
    chlpracl SysCmd1 joe@LOCALHOST r
  4. There are several nodes in a peer domain. There is an LP resource called SysCmdB1 on nodeB for which joe needs execute permission. In addition, joe needs to have execute permission from nodes nodeA, nodeB, and nodeD. If you run the chlpracl command on nodeB, you can use joe@LOCALHOST for nodeB, but you need to determine the node IDs for nodeA and nodeD. To obtain the node IDs, enter: 
    lsrpnode -i
    The output will look like this: 
    Name    OpState RSCTVersion NodeNum NodeID
nodeA   Online  2.4.2.0     2       48ce221932ae0062
nodeB   Online  2.4.2.0     1       7283cb8de374d123
nodeC   Online  2.4.2.0     4       b3eda8374bc839de
nodeD   Online  2.4.2.0     5       374bdcbe384ed38a
nodeE   Online  2.4.2.0     2       ba74503cea374110
nodeF   Online  2.4.2.0     1       4859dfbd44023e13
nodeG   Online  2.4.2.0     4       68463748bcc7e773
    Then, to give joe the permissions as stated above, run on nodeB: 
    chlpracl SysCmd1 -l joe@LOCALHOST joe@0x48ce221932ae0062 \
joe@0x374bdcbe384ed38a x