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

[Linda Knippers]

Steve Grubb wrote:
> On Friday 09 February 2007 11:46, Linda Knippers wrote:
> 
>>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.
> 
> 
> They should all open the audit socket before performing that operation. They 
> could call audit_status and see if the audit daemon is registered. But you 
> would have to have a command line option to tell the program that it should 
> treat the absence of an audit daemon in a way as to deny the requested 
> action. Not all users want this behavior.

Right.  That's why we added the audit library routine to get the user
selectable failure action from /etc/libaudit.conf.  In the cups case, it
checks that when it opens the audit socket, which it does when it starts
up. When we talked about this before we talked about per-application
failure actions but ended up with just a global one.  I don't think we
want to add command-line options.
>
>>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?
> 
> 
> The should all be fixed to do that I suppose. I can add a function to libaudit 
> that does the status check and returns yes or no if the audit daemon is 
> registered. Would this help?

I think we've already got what we need in libaudit. The question was
about which failures to look for when and what to do about it.
According to Klaus we don't have to handle the case where the admin
stops the audit daemon, just the log full case, which I believe is
handled by the action selected in the auditd config file.

-- ljk
> 
> -Steve