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

[Casey Schaufler]

--- Klaus Weidner <klaus at atsec.com> 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.

To the best of my knowledge no one has ever
tried an approach other than "halt the system"
under the full audit files scenario. You can't
know if some operations will require audit in
advance, and auditable operations typically
cannot be undone. Having auditable operations
fail because there's no space would cause more
damage than a tornado in a trailer park if you
could make it work. Making them hang until
space is available has been tried, and it
introduces all sorts of races, retries,
communication failures, and frustrations.

It makes no sense to have cups (or any
individual component) undo operations if
audit fails unless all components do so.
I am skeptical that sufficient coverage
is possible to meet the LSPP requirement
using any technique short of "halt".

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



Casey Schaufler
casey at schaufler-ca.com