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 (deaccesses 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.
HP OpenVMS Guide to System Security
Security for the User
