When do audit log calls fail?

[Steve Grubb]

On Wednesday, September 18, 2013 08:48:49 AM Kenan Avdic wrote:
> Hello,
> 
> We've recently started using audit instead of syslog for reliability
> purposes (acknowledged logging). I'm trying to establish when the
> various audit_log_* system calls fail, particularly audit_log_user_message.
> 
> Basically what we're after is a way of being sure that a message that
> was sent for logging is "comitted", and react in some way if it is not.
> We're using audit_log_user_message but this function never fails (i.e.
> returns <=0, per manpage), 

The main priority of the audit system is integrity of messages. You can lose 
messages, but only a small quantity and is under admin control. Because its 
open source, any ideas on improvements would be welcome. But to your 
question...the audit system has not been developed to solve every possible 
problem a user might have. Its evolved based on meeting common criteria needs.

The root of the problem you are seeing is because of GDM. It has a screensaver 
and you need to enter a password to unlock. This is done without privileges 
and uses pam.Libpam is designed to disallow access if auditing fails (this is 
required by CC). However, the desktop is never certified and has too many 
problems for any distribution to certify. So, we decided that in order to fix 
the screensaver problem, we can just hide the fact that it failed due to no 
privileges. Also, a number of years ago people found that they were not able 
to login when they built a custom kernel that excluded the SYSCALL_AUDIT config 
option. So, we had to make a loophole for that as well. You can see the 
loopholes here:

https://fedorahosted.org/audit/browser/trunk/lib/deprecated.c#L47
The rationale is documented there.

Generally, sending will fail only when you don't have CAP_AUDIT_WRITE, or SE 
Linux policy prevents a process from sending an event, or the kernel doesn't 
support auditing. For the harder to actually see but theoretically exist, I'd 
look at the sendto system call man page for other return codes.


> even e.g. if the audit daemon is down. 

No one has ever had to determine this from an audit sending app, so its never 
had an API created to do it. Generally the audit events are fire and forget. 
The kernel takes them and serializes it with other current events collects 
some extra information that user space cannot be trusted to collect and mashes 
that into an event. Its placed on a queue for disposition. Some people want to 
have audit events sent to syslog, so if an audit daemon is not running, syslog 
can be the final destination.


> From reading the source code it seems the only way for it to fail is when
> the kernel is lacking support for auditing (or is too old or similar).
> 
> My conclusion, given the above assumption, is that these functions do
> not provide a way to ascertain that a message is actually logged from
> the system call, and that decisions about failed logging have to be made
> by the daemon.

That is correct. No one has ever asked for it to be otherwise.


> Is there any other way to check what happens with a log
> message once its sent using e.g. audit_log_user_message?

Theoretically, you could have audispd's af_unix plugin enabled and then 
receive events in you app looking for the one you just sent. This would let 
you know that the audit daemon is running because you wouldn't be able to 
connect to the socket unless it was up. If the daemon dies, you'll get a 
SIGPIPE signal. And you can use auparse to just watch for your event and throw 
everything else away. Even doing this, you can only tell that the event made 
it to the audit daemon, but not that it made it to disk. But you should see 
other daemon specific events and track its state.

-Steve