Este contenido no está disponible en el idioma seleccionado.
Appendix D. ACL Reference
This section describes what each resource controls, lists the possible operations describing the outcome of those operations, and provides the default ACIs for each ACL resource defined. Each subsystem contains only those ACLs that are relevant to that subsystem.
D.1. About ACL Configuration Files
Access control is the method to set rules on who can access part of a server and the operations that user can perform. The four subsystems which depend on the LDAP directory service and use a Java console — the CA, KRA, OCSP, and TKS — all implement LDAP-style access control to access their resources. These access control lists (ACL) are located in the
/var/lib/pki/instance_name/conf/subsystem/acl.ldif file.
Note
This section provides only a very brief overview of access control concepts. Access control is described in much more detail in the Managing Access Control chapter in the Red Hat Directory Server Administration Guide.
The Certificate System ACL files are LDIF files that are loaded by the internal database. The individual ACLs are defined as
resourceACLS attributes which identify the area of the subsystem being protected and then a list of all of the specific access controls being set.
resourceACLS: class_name:all rights: allow|deny (rights) type=target description
Each rule which allows or denies access to a resource is called an access control instruction (ACI). (The sum of all of the ACIs for a resource is an access control list.) Before defining the actual ACI, the ACL attribute is first applied to a specific plug-in class used by the Certificate System subsystem. This focuses each ACL to a specific function performed by the subsystem, providing both more security for the instance and better control over applying ACLs.
Example D.1. Default ACL to List Certificate Profiles
resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles
Because each subsystem (CA, KRA, OCSP, and TKS) has different resources for its operations, each subsystem instance has its own
acl.ldif file and its own defined ACLs.
Each ACI defines what access or behavior can be done (the right) and who the ACI applies to (the target). The basic format of an ACI is, then:
allow|deny (rights) user|group
Rights are types of operations that the ACI allows a user to perform. For LDAP ACIs, there is a relatively limited list of rights to directory entries, like search, read, write, and delete. The Certificate System uses additional rights that cover common PKI tasks, like revoke, submit, and assign.
If an operation is not explicitly allowed in an ACI, then it is implicitly denied. If an operation is explicitly denied in one ACI, then it trumps any ACI which explicitly allows it. Deny rules are always superior to allow rules to provide additional security.
Each ACI has to apply to specific users or groups. This is set using a couple of common conditions, usually
user= or group=, though there are other options, like ipaddress= which defines client-based access rather than entry-based access. If there is more than one condition, the conditions can be composed using the double pipe (||) operator, signifying logical disjunction ("or"), and the double ampersand (&&) operator, signifying logical conjunction ("and"). For example, group="group1" || "group2".
Each area of the
resourceACLS attribute value is defined in Table D.1, “Sections of the ACL Attribute Value”.
| Value | Description |
|---|---|
| class_name | The plug-in class to which the ACI is applied. |
| all operations | The list of every operation covered in the ACI definition. There can be multiple operations in a single ACI and multiple ACIs in a single resourceACLS attribute. |
| allow|deny | Whether the action is being allowed for the target user or group or denied to the target user or group. |
| (operations) | The operations being allowed or denied. |
| type=target | The target to identify who this applies to. This is commonly a user (such as user="name") or a group (group="group"). If there is more than one condition, the conditions can be composed using the double pipe (||) operator (logical "or") and the double ampersand (&&) operator (logical "and"). For example, group="group1" || "group2". |
| description | A description of what the ACL is doing. |
