Whenever a process uses an object or modifies
its security profile (see “Modifying a Security Profile”), the system can send an alarm to
an operator terminal or write a message to the audit log file. By
reading the log file, a security administrator can review system activity
to see how protected objects are being used, when they are being used,
and who is using them.
Exactly which type of information is reported
through the auditing system depends on how the security administrator
defines the site's requirements. If system administrators choose
to have object use audited, they can enable auditing for the appropriate
categories of events.
The operating system can filter security-related
events and send system administrators messages only when objects are
accessed in certain ways. Sites are often more interested in the privileged
use of a file or the failure to access a file than in every file access.
Such a site can request auditing messages whenever a process fails
in accessing a file, but not when it is successful. The system can
report how the process exercised, or failed to exercise, the right
to access the object in the first place: through a protection code,
an ACE, or a privilege.
Kinds of Events the System Audits |
 |
Each object class has its own auditing profile,
described in “Descriptions of Object Classes”, and so it is possible to receive
more information on some classes of objects than on others. For any
object, the system can send an auditing message whenever a user or
application accesses the object or modifies its security elements.
In some instances, the system can send a notification when a process
creates an object, stops using it or deletes it.
Enabling Auditing for a Class of Objects |
|
When you are auditing object access events, keep
in mind that the operating system may check a user's right to
an object several times during a single operation. A file operation,
for example, can involve checks for both directory and file access.
Before a user deletes a file, the system checks for delete access
to the file and write access to the directory.
For this reason, it is best for a security administrator
to enable auditing for all types of object access events. For example,
to track all instances where a user tries to access a file but fails,
a security administrator would use the /ENABLE=ACCESS=FAILURE=ALL
qualifier to the SET AUDIT command.
For object classes that support deaccess auditing
(for example, the file class), once a process gains access to an object,
the system does not audit subsequent access attempts to the object
unless the process attempts an operation that is incompatible with
the access modes previously granted. When this occurs, the system
performs an additional protection check that is audited. This access
window continues until the object is deaccessed (for example, the
file is closed).
Adding Security-Auditing ACEs |
|
Rather than audit an entire class of objects,
security administrators and users with control access to an object
can single out a specific object for auditing by attaching an Alarm
or Audit ACE to it (see “Adding Access Control Entries to Sensitive Files”). Although you can add an auditing
ACE to any file that you own or have control access to, it is best
to consult your security administrator before doing so. As with object
classes, the security administrator has to enable the ACL auditing
category before any auditing messages are generated.
