Партнёры:
Хостинг:
audit_user - events to be audited for given users
Each line maps a user name to a list of classes that should be audited and a list of classes that should not be audited. Entries are of the form:
In the format above, alwaysaudit is a set of event classes that are always audited, and neveraudit is a set of event classes that should not be audited. These sets can indicate the inclusion or exclusion of multiple classes, and whether to audit successful or failed events. See audit_control5 for more information about audit flags.
Example entries in this file are:
root:lo,ad:no jdoe:-fc,ad:+fw
These settings would cause login/logout and administrative events that succeed on behalf of user ``root '' to be audited. No failure events are audited. For the user ``jdoe '' failed file creation events are audited, administrative events are audited, and successful file write events are never audited.
Audit record preselection occurs with respect to the audit identifier associated with a process, rather than with respect to the UNIX user or group ID. The audit identifier is set as part of the user credential context as part of login, and typically does not change as a result of running setuid or setgid applications, such as su(1). This has the advantage that events that occur after running su(1) can be audited to the original authenticated user, as required by CAPP, but may be surprising if not expected.
The Basic Security Module (BSM) interface to audit records and audit event stream format were defined by Sun Microsystems.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |