Re: When do audit log calls fail?

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