[redhat-lspp] what happens when something can't be audited?

[Klaus Weidner]

On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda Knippers wrote:
> In this bugzilla, Eduardo has accurately described the behavior of cups if
> auditd is running when cupsd starts up but auditd is stopped afterwards.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889
> 
> He was expecting cupsd to stop printing (not an unreasonable expectation)
> but it does not.
> 
> I updated the bugzilla to explain why and to point out that lots of
> trusted programs issue audit records at the completion of some operation
> (they include the results in the audit record) and don't undo the operation
> if issuing the audit record fails.  We could certainly change cupsd to
> fail to queue a job or to cancel a job if it can't be audited but what
> about the other programs?
> 
> I know we talked about this alot when the audit failure action
> routine was added the libaudit but the requirements were never
> very clear.

The only directly relevant requirement from LSPP is that any actions
which would normally be audited must be prevented when the audit trail is
full. There is no requirement for preventing actions when the admin has
intentionally disabled audit, or if audit is not working for some reason
other than a full audit trail.

There is a special case for the secure failure mode in pam_loginuid,
where login is prevented if auditd is not running. This is done to ensure
that the association between user actions and their identity is reliable.

-Klaus