Each policy is a selang script that includes comments that explain the policy's purpose and the rules it contains:
Sample policies are annotated to help you understand what each section of the sample policy is set to achieve.
Compliance and best practices policies are operating system independent. However, resources groups vary from system to system. To overcome this problem, resource lists use variables and the ACLs use the variables in the policies. When an endpoint connects to the Enterprise Management Server, it is automatically added to the matching host group according to the operating system and a policy is deployed to the endpoint.
To simplify user management, sample policies apply ACLs to roles. Each role uses a CA ControlMinder group of users that you can add real users to.
Policy roles use the following convention: ROL_role_name. For example, sample policies use the ROL_SYSTEM group for built-in system users like adm and lp. Many policies assign these users with wide-ranging permissions (for proper system operation) but also expire them so that users cannot use them to log in.
Example: compliance and best practices policies comments
The following snippet from the PCI_DSS_7.1.1 compliance policy illustrates how compliance and best practices policies are annotated. Using selang syntax rules, the lines that begin with a hash symbol (#) are comments.
#
# * 2. Protect <!USER_OS_ADMIN> Logon and Access Control Administration *
# ***********************************************************************
#
# This section uses the TERMINAL class to restrict administrator users from
# logging in directly (read access). Access Control administration is blocked as
# well (write access).
#
# To separate security administration from system administration, the policy
# sets READ access only to these special terminals.
#
editres TERMINAL ("<!HOSTNAME>") audit(ALL) warning
authorize TERMINAL ("<!HOSTNAME>") uid("<!USER_OS_ADMIN>") deniedaccess(READ)
# The following line is commented because the warning mode in UNIX is not
# applicable for write access to class TERMINAL.
#authorize TERMINAL ("<!HOSTNAME>") uid("<!USER_OS_ADMIN>") deniedaccess(WRITE)
Example: compliance and best practices policies roles
The following snippet from the PCI_DSS_7.1.1 compliance policy illustrates how the policy applies ACLs to roles.
#
# * 1. Role Definitions *
# ***********************
#
# The rules in this section define the roles that the policy uses.
#
# * Define built-in OS users with the logical property. This prevents users
# from logging in to the system.
# * Create the user +nobody in CA Access Control only. CA Access Control
# sets this user as the owner of many resources (to disable ownership
# bypass). You cannot create this user in the native OS.
# * Create at least one user in ROL_AC_ADMIN. Without this user you cannot
# login into CA Access Control.
# Note: By default, the rules add the superuser account to ROL_AC_ADMIN.
# We recommend that you remove this user and add security
# administrators to this group.
# Roles:
# ROL_SYSTEM : built-in OS users
# ROL_SYSADMIN : system administrators
# ROL_RESTRICTED : restricted users with permissions for specific tasks
# ROL_AC_ADMIN : CA Access Control administrators
# ROL_AC_AUDITOR : CA Access Control auditors
# ROL_AC_OPERATOR : CA Access Control operators
# ROL_AC_SERVICE : CA Access Control service managers
# ROL_AC_PWMANAGER : CA Access Control password managers
#
editgrp (ROL_SYSTEM ROL_SYSADMIN ROL_RESTRICTED ROL_AC_ADMIN ROL_AC_AUDITOR ROL_AC_OPERATOR ROL_AC_SERVICE ROL_AC_PWMANAGER)
chgrp (ROL_SYSADMIN ROL_AC_ADMIN) audit(LOGINSUCCESS LOGINFAILURE FAILURE)
editusr (+nobody) comment("AC OOTB - Resource owner used for disabling ownership bypass")
chusr (+nobody) owner(+nobody)
join ("<!USER_OS_ADMIN>") group(ROL_SYSTEM)
join ("<!USER_OS_ADMIN>") group(ROL_AC_ADMIN)
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|