Endpoint Administration Guide for UNIX › Auditing Events › Warning Mode › How to Perform System Maintenance

How to Perform System Maintenance

At certain times you may need to perform system maintenance to upgrade the system, install a new application, and so on. During system maintenance you should set CA ControlMinder rules in Warning mode. Once you are comfortable that the maintenance did not affect user access to resources that they require, you should turn off Warning mode and CA ControlMinder will start enforcing the associated rules.

To use Warning mode when you perform system maintenance, do the following:

1. Set the appropriate classes to Warning mode before you start the maintenance, using the following selang rule:

   setoptions class(NAME) flags(W)
   

2. Perform the maintenance.
3. Run the seretrust utility after you perform the maintenance.

   The seretrust utility generates the selang commands required to retrust programs and secure files defined in the database.

4. Run the selang command to retrust the programs defined in the database.
5. Remove the Warning mode from the classes to enable policy enforcement, using the following selang rule:

   setoptions class(NAME) flags-(W)
   

6. Review CA ControlMinder audit log files.

   The audit log contains warnings for the resources that were affected by the maintenance.

Note: For more information about the seretrust utility, see the Reference Guide.

More information:

seretrust Utility—Generate Commands to Retrust Programs and Secure Files

Audit Logs

The audit records are stored in a file called the audit log. The location for the audit log is specified in the seos.ini file. The seaudit utility or CA ControlMinder Endpoint Management can be used to list recorded events in the audit log, filter events by time restrictions or event type, and so on.

Note: For more information about seaudit, see the Reference Guide.

The audit logs are stored locally, but you can use CA ControlMinder to distribute the auditing information by using the log routing facility. Consider archiving old audit logs to tape, to allow you to scan the events later.

By default, the authorization daemon seosd creates the audit logs with root ownership, since the seosd program is executed by the user root. For the same reason, the audit logs are created with read/write permissions granted only to root.

To enable other users to read the audit logs without having to su (substitute user) to root, CA ControlMinder includes two entries in the seos.ini file that specify which group ownership is assigned to the log files.

• One entry is for the audit log.

  Suppose the auditors at your site are all members of a group named auditforce. You want these users to be able to browse through the local audit log files. Edit the seos.ini file so that the audit_group token in the [logmgr] section is set to auditforce. CA ControlMinder then gives the auditforce group read permission to your local audit logs. From this point, any local audit logs created at your station have the auditforce group as their owner.

  The log routing daemons consult the same token to see who should have access rights to the audit logs that the daemons produce and collect. Note that the audit logs are subject to access control like any other files, and CA ControlMinder rules can keep users from accessing them.

• The other entry is for the error log, and it is used in the same way to specify group ownership for that file.