When do audit log calls fail?
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
Signature · 7 lines
Kenan Avdic link22 AB Brigadgatan 1 587 58 Linköping, Sweden [email protected] tel: +46 707 75 77 61
Quoted 10 lines · Kenan Avdic
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_messagebut 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.
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 2 lines
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
Quoted 72 lines · Steve Grubb
Quoted 10 lines · Kenan Avdic
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_messagebut 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_AUDITconfig 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.Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 2 lines
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_unixplugin 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.
Quoted 2 lines
-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
Signature · 7 lines
Kenan Avdic link22 AB Brigadgatan 1 587 58 Linköping, Sweden [email protected] tel: +46 707 75 77 61
Quoted 4 lines · Kenan Avdic
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