When do audit log calls fail?

When do audit log calls fail?

[Kenan Avdic]

[-- Attachment #1.1: Type: text/plain, Size: 1158 bytes --]

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), even e.g. if the audit daemon is down. 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. Is there any other way to check what happens with a log 
message once its sent using e.g. audit_log_user_message?


Thanks,
/Kenan

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

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


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2266 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 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

Re: When do audit log calls fail?

[Kenan Avdic]

[-- Attachment #1.1: Type: text/plain, Size: 4305 bytes --]

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@link22.se
tel: +46 707 75 77 61


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2266 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: When do audit log calls fail?

[Steve Grubb]

On Thursday, September 19, 2013 11:43:22 AM Kenan Avdic wrote:
> 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.

Don't apologize...that is how the audit system gets better. New people bring 
new requirements and if its a good idea, we generally implement it or move 
towards that capability over time. If you want to talk more about your 
requirements, please do. There are others here that might also need some of 
the capabilities you want.

Thanks,
-Steve