OSF DCE Administration Guide--Core Components

OSF DCE Administration Guide—Core Components
no filtering and all audit events are recorded.
• DCEAUDITTRAILSIZE—Sets the maximum size of the audit trail.
43.2 Starting the Audit Daemon
The DCE Audit Service is not a distributed application. The audit daemon (auditd) does
not need to run on all DCE hosts even if a client application is making use of the audit
service. The audit daemon only needs to run on a host if the audit logs are to go to the
central trail file or if filters are to be installed on the host. This is because the audit
daemon controls access to the central trail file and also manages the audit filters.
However, since the DTS daemon and the security server daemon are audit clients, you
may want to consider running the audit daemon on all hosts in the cell.
You must be root to be able to start the audit daemon.
Use the following command to start the audit daemon:
auditd
This command uses flags that influence the behavior of the daemon. For more details on
these flags, see the auditd(8sec) reference page.
43.3 Controlling Access to the Audit Daemon
You must control access to the audit daemon to prevent unauthorized application servers
(the audit clients) from using it. If an unauthorized server is able to log its audit records,
the audit storage space would be exhausted.
You control access to the audit daemon by editing the ACL of the audit daemon object,
/.:/hosts/hostname/audit-server, using dcecp.
43.3.1 DCE Permissions Supported by the DCE Audit Service
The DCE Audit Service supports the following DCE permissions that can be used to
define the ACL of the audit daemon:
r Read permission. Allows a principal to read the filters.
w Write permission. Allows a principal to modify the filters.
c Control permission. Allows a principal to control the audit daemon. This
includes the ability to enable or disable the logging service, and to
modify the ACL of the audit daemon.
43 − 2 Tandem Computers Incorporated 124243