|
|
The auditing subsystem uses event masks to determine which events are currently being audited. Event masks are data structures that contain 8 words, or 256 bits. There is a bit for each possible event on the system; if the bit is set (that is, has a value of 1), the event is audited. See the ``Summary of auditable events and classes'' for a list of all events.
``Audit event mask'' illustrates an event mask structure.
Audit event mask
The auditing subsystem uses several different event masks to determine when to generate an audit record for an event. The auditing subsystem maintains the following event masks:
The system event mask contains the set of events that are audited for every process on the system. The system event mask is stored in global kernel space. Please note that kernel processes marked as SYSTEM, RESIDENT or ZOMBIE are exempt from auditing. In addition, there are trusted user-level processes that bypass the event mask mechanisms. For example, the user-level command auditmap(1M), through its invocation of the audit system call auditevt(2), marks itself exempt from auditing.
A user event mask contains the set of events that are audited for a specific user. This mask is set as part of the login procedure or when cron starts a job for a user; the user mask associated with the specific user is extracted from the /etc/security/ia/master file and is stored in the useremask field of the audit process structure. However, if processes owned by the user already exist on the system, such as might occur when a user is already logged into the system from another terminal, then the useremask field for that user is used, instead. This ensures that all of the processes owned by a user are audited in a consistent manner. Note that the user masks are generally not affected by changes in effective user ID. That is, if a user logs in as user1 and then uses the su(1M) command to change their effective user ID to user2, the user mask applied will be the mask for user user1, not the mask for user2. Therefore, a user cannot evade the set of events that you set to be audited for them by using the su command.
Changes to the user's event mask may be made statically or dynamically. To change the user event mask statically, the data in the /etc/security/ia/audit and /etc/security/ia/master files are updated. Modification to the user event mask will only take effect for future login sessions or cron jobs for that user. Note, however, that the effect will be delayed if the change is made while the affected user owns active processes on the system. In this case, as long as the user owns active processes on the system, any new processes created (such as those created by a second login session or a cron job), will use the useremask for the existing processes as its user event mask. Only when the user subsequently has no active processes on the system will the static change to the user event mask take effect.
To change the user event mask dynamically, for a user who currently owns active processes on the system, the useremask field in the audit process structure is updated, using the auditset(1M) command. Dynamic changes are reflected in the current login session; they are lost, however, once the user no longer has any active processes on the system.
A process event mask contains the set of events audited for all non-exempt processes. The process event mask is the union of the system event and user event mask. The process event mask is stored in the a_emask field of the audit process structure and is used to determine if an event is being audited. The process event mask is updated every time the user event mask or the system event mask is modified.
This mask was used in earlier releases to select events for auditing. It is unused in this release.