From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenan Avdic Subject: Re: When do audit log calls fail? Date: Thu, 19 Sep 2013 11:43:22 +0200 Message-ID: <523AC73A.5040305@link22.se> References: <52394CD1.5070006@link22.se> <2297720.rjEcLE15AB@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2911488378396499776==" Return-path: Received: from mx1.redhat.com (ext-mx15.extmail.prod.ext.phx2.redhat.com [10.5.110.20]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8J9hUi1006579 for ; Thu, 19 Sep 2013 05:43:30 -0400 Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8J9hPkR007216 for ; Thu, 19 Sep 2013 05:43:27 -0400 Received: by mail-lb0-f175.google.com with SMTP id y6so7619159lbh.34 for ; Thu, 19 Sep 2013 02:43:25 -0700 (PDT) In-Reply-To: <2297720.rjEcLE15AB@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a cryptographically signed message in MIME format. --===============2911488378396499776== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000900000801060409010600" This is a cryptographically signed message in MIME format. --------------ms000900000801060409010600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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_mes= sage. >> >> 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= =2E >> We're using audit_log_user_message but this function never fails (i.e.= >> returns <=3D0, 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 possi= ble > 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 scre= ensaver > and you need to enter a password to unlock. This is done without privil= eges > and uses pam.Libpam is designed to disallow access if auditing fails (t= his is > required by CC). However, the desktop is never certified and has too ma= ny > 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 t= o 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_AUDI= T 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 do= esn't > support auditing. For the harder to actually see but theoretically exis= t, 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 fo= rget. > The kernel takes them and serializes it with other current events colle= cts > 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 ma= de >> 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 an= d 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=20 discovering it does not - my apologies if I seemed to be demanding featur= es. /Kenan --=20 Kenan Avdic link22 AB Brigadgatan 1 587 58 Link=F6ping, Sweden kenan.avdic@link22.se tel: +46 707 75 77 61 --------------ms000900000801060409010600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFBDCC BQAwggPooAMCAQICAQkwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCU0UxCzAJBgNVBAgT AlNFMRIwEAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsyMiBSb290IENBIDAxMS0w KwYJKoZIhvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5rMjIuc2UwHhcNMTExMDE4 MTgyMzM0WhcNMjExMDE1MTgyMzM0WjBqMQswCQYDVQQGEwJTRTELMAkGA1UECBMCU0UxEjAQ BgNVBAoTCWxpbmsyMiBBQjEUMBIGA1UEAxMLS2VuYW4gQXZkaWMxJDAiBgkqhkiG9w0BCQEW FWtlbmFuLmF2ZGljQGxpbmsyMi5zZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AK/1hyDI/aRna0LlO8NNn6WQGrmPrLns838pFykXezPbXZJ4zq17ru3ephke53hrgDorXv/w UqkK81tRng/2hjYL/TAdLq/mpRmcu80JthDkUO2oMHbionP7BgLqtoH9dTrRY2dBKQ63fD9f 21huhebRSREcLYuPKmd0lgtOBOLh08vl5vpkitMCX5WbyM91ETjTrBnzHytIzvv5P0aGzeRh sv/Klzitku6tzN4kNQC/GBqPSk22270PLj7JfZkKw975R8vPwZYJNvrcA8eydJ+qBnJE25hL l4oJfb4aY/6vDqVEjpw1nghE2PlrbthKc8vHjUbRon6Bad63tU3QZhcCAwEAAaOCAaAwggGc MAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgSwMB0GA1UdDgQWBBQ5Rv6y7edoG/bIhpHbLBsK KM1sgDCBqwYDVR0jBIGjMIGggBTfqaK8DAxQZSHx5w0OgAVLU3uSlqF9pHsweTELMAkGA1UE BhMCU0UxCzAJBgNVBAgTAlNFMRIwEAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsy MiBSb290IENBIDAxMS0wKwYJKoZIhvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5r MjIuc2WCCQCbNJyWTn+XVDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwIAYDVR0R BBkwF4EVa2VuYW4uYXZkaWNAbGluazIyLnNlMAkGA1UdEgQCMAAwMQYJYIZIAYb4QgEEBCQW Imh0dHA6Ly9jcmwubGluazIyLnNlL2xpbmsyMi1jYS5jcmwwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC5saW5rMjIuc2UvbGluazIyLWNhLmNybDANBgkqhkiG9w0BAQsFAAOCAQEA OCDx8G6Os9o+NIWsNIYoOhiroFcvsTi9YaTBGchf0KQo4azCGtb0MqBInTLeHKKoI1Zude4W 1NQdbiFMwMPsZN1GoF69cTVGU03Q3qnNf/ybI8j3dlVoUcvLhfcoYrj1Vf6e1Qw67cVUaoWQ XmfUdEboB01toL3+1sTrP1QA2YK2EOx+HnwbQMuxK47L26A2i3IBsyCKrwc4xWOCEOhPW9wf 8Q/hjTteAZQxNocUoCe1rPKmNpZCRzb2QpJgGXSR2oVhbIKRUW1/lAtg6iiAPT6wlH7hVl/h 0znaFGo6NwpD6aCb/Hv5c1kWFQ2gfnCfQbmlQBCj6g77nL/U3ejYYjGCA5gwggOUAgEBMH4w eTELMAkGA1UEBhMCU0UxCzAJBgNVBAgTAlNFMRIwEAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNV BAMTEWxpbmsyMiBSb290IENBIDAxMS0wKwYJKoZIhvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhv cml0eUBsaW5rMjIuc2UCAQkwCQYFKw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE5MDk0MzIyWjAjBgkqhkiG9w0BCQQxFgQUsTMy Jvtx9u5VZ/gsSKtDkY7wdq0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBjgYJKwYBBAGCNxAEMYGAMH4weTELMAkGA1UEBhMCU0Ux CzAJBgNVBAgTAlNFMRIwEAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsyMiBSb290 IENBIDAxMS0wKwYJKoZIhvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5rMjIuc2UC AQkwgZAGCyqGSIb3DQEJEAILMYGAoH4weTELMAkGA1UEBhMCU0UxCzAJBgNVBAgTAlNFMRIw EAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsyMiBSb290IENBIDAxMS0wKwYJKoZI hvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5rMjIuc2UCAQkwDQYJKoZIhvcNAQEB BQAEggEARADOR6yGc1ktLr1dElwQP0lXnSUWUGTBa+NpWwJWtwJIobsYYKLem/gm9AVlCNek aNkkYu6PQTrP3J7hESRWunFEVdH2TC8dLrx1rKk9sSPQpP+Wq3U6db3+0AXia9EEiSQmMSEN TDSkgPYPdiJkAPPXcOb0NLgnw11vHUP/BFJt/QxO/mwe8SUdxUol0HlbZW/NqPkhCQIcK6jI W4FyPYfZ+FkzDRlz3yVu1op8IoLYmds3cQvKatq3bnzWZ9fZEjmOLUcDVm5+D5aHpd9gwdlq IglF/mBrBIyCL/5py61VX9N0i/NVRZ1Tu1zUWXFO0TCdLRsFV3sVfUkMcBBqsAAAAAAAAA== --------------ms000900000801060409010600-- --===============2911488378396499776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2911488378396499776==--