When do audit log calls fail?

[Kenan Avdic]

On 2013-09-18 19:50, Steve Grubb wrote:
> 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
>
Thanks very much for the excellent answer. That explains everything.

It's been suggested to me that audit had certain features that I'm 
discovering it does not - my apologies if I seemed to be demanding features.

/Kenan

-- 
Kenan Avdic
link22 AB
Brigadgatan 1
587 58 Linköping, Sweden

kenan.avdic at link22.se
tel: +46 707 75 77 61

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2266 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20130919/ff2b4ffb/attachment.p7s>