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

[James W. Hoeft]

While LSPP is the primary concern (considering this is an LSPP list...), 
from a system perspective there are others. In the case of a system we 
delivered recently (PL4 - C4I system, so DCID 6/3), the accreditors 
allowed ten minutes of operation before it had to automatically shut 
down if audit "failed" (i.e., wasn't running or couldn't write). They 
wanted it shut down immediately, and it took hours of negotiation to get 
ten minutes. This was for a "medium availability" system, may have 
gotten a little more leeway for one at "high", and certainly less for 
one at "low".

This doesn't address the behavior of the individual apps/daemons, but if 
it isn't TOO much trouble to address an audit "failure" at that level, 
in order to tailor the behavior based on the criticality of the system, 
that would be ideal. (in the case of printing, our accreditors would 
want the job canceled - other functions would be on a case-by-case basis)

Jim

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. 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
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp
> 
> 
>