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

[Linda Knippers]

Klaus Weidner wrote:
> 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. 

Ok, so same requirement as for CAPP.

> 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.

And in the log or disk full case, we take the action before the
disk is actually full so we shouldn't be losing anything.

I think we can close this bz as not a bug.  Thanks.

> 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.

-- ljk