From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenan Avdic Subject: When do audit log calls fail? Date: Wed, 18 Sep 2013 08:48:49 +0200 Message-ID: <52394CD1.5070006@link22.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6076131744354767058==" Return-path: Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r8I6n5SD030959 for ; Wed, 18 Sep 2013 02:49:06 -0400 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8I6n0TR000697 for ; Wed, 18 Sep 2013 02:49:02 -0400 Received: by mail-la0-f49.google.com with SMTP id ev20so5186851lab.36 for ; Tue, 17 Sep 2013 23:49:00 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a cryptographically signed message in MIME format. --===============6076131744354767058== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703080705080709060405" This is a cryptographically signed message in MIME format. --------------ms010703080705080709060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, We've recently started using audit instead of syslog for reliability=20 purposes (acknowledged logging). I'm trying to establish when the=20 various audit_log_* system calls fail, particularly audit_log_user_messag= e. Basically what we're after is a way of being sure that a message that=20 was sent for logging is "comitted", and react in some way if it is not.=20 We're using audit_log_user_message but this function never fails (i.e.=20 returns <=3D0, 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=20 not provide a way to ascertain that a message is actually logged from=20 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=20 message once its sent using e.g. audit_log_user_message? Thanks, /Kenan --=20 Kenan Avdic link22 AB Brigadgatan 1 587 58 Link=F6ping, Sweden kenan.avdic@link22.se tel: +46 707 75 77 61 --------------ms010703080705080709060405 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE4MDY0ODQ5WjAjBgkqhkiG9w0BCQQxFgQUsp3K YK0Jb6XW5nxiF+WvO2O6T+YwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBjgYJKwYBBAGCNxAEMYGAMH4weTELMAkGA1UEBhMCU0Ux CzAJBgNVBAgTAlNFMRIwEAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsyMiBSb290 IENBIDAxMS0wKwYJKoZIhvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5rMjIuc2UC AQkwgZAGCyqGSIb3DQEJEAILMYGAoH4weTELMAkGA1UEBhMCU0UxCzAJBgNVBAgTAlNFMRIw EAYDVQQKEwlsaW5rMjIgQUIxGjAYBgNVBAMTEWxpbmsyMiBSb290IENBIDAxMS0wKwYJKoZI hvcNAQkBFh5jZXJ0aWZpY2F0ZWF1dGhvcml0eUBsaW5rMjIuc2UCAQkwDQYJKoZIhvcNAQEB BQAEggEAOD4n6g2O/+lYcwBjC8C0YPyg8elSHZ/Ao8KnyI15ixT6y93CjHaQsyIZ5QgbSLUV E9z5mZy2kARrnfYbvs3awz1aY2u7cfza6RQwfILirpcoiUA0iilBndF0ov9/4fzBrvAl2LCf HQjxkdS4Jp1yo0sklOs1jydID9vdHcEZBu4frr7gofgnqQSWE0s8kEdLjZZXHU/qM40lbzQD 42MRjYqqhIr11kDaavHB2ICcW1nkHuvIDfM9Nq1e6zBmQI7+iNfOE3lAUt1MsDv837nUV3Q3 UQfUZT1KfqmG1mbSBJxVAgxabAZHqynoMB7XytKQKdX79OJ2FSJZQP9U0S8JFQAAAAAAAA== --------------ms010703080705080709060405-- --===============6076131744354767058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============6076131744354767058==--