From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Date: Wed, 22 Oct 2014 14:36:43 -0500 Message-ID: <5448074B.8080706@magitekltd.com> References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com> <2131923.Byl8GhZuQt@x2> <1645943.LlOpH1gJUB@sifl> <1978142.LNMGsIevqD@x2> <1413990725.30946.84.camel@localhost> <5447D295.2010504@magitekltd.com> <1414001880.30946.94.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7699632088265485738==" Return-path: Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MJal5Z032048 for ; Wed, 22 Oct 2014 15:36:47 -0400 Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MJajj9032311 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 22 Oct 2014 15:36:45 -0400 Received: by mail-ob0-f182.google.com with SMTP id uy5so3510806obc.13 for ; Wed, 22 Oct 2014 12:36:45 -0700 (PDT) In-Reply-To: <1414001880.30946.94.camel@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a cryptographically signed message in MIME format. --===============7699632088265485738== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040804090704050809080207" This is a cryptographically signed message in MIME format. --------------ms040804090704050809080207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/22/2014 01:18 PM, Eric Paris wrote: > On Wed, 2014-10-22 at 10:51 -0500, LC Bruzenak wrote: >> On 10/22/2014 10:12 AM, Eric Paris wrote: >>> On Wed, 2014-10-22 at 10:25 -0400, Steve Grubb wrote: >>> >>>> 1) For the *at syscalls, can we get the path from the FD being passe= d to be >>>> able to reconstruct what is being accessed? >>> You might sometimes be able to get A path. But every time anyone eve= r >>> says THE path they've already lost. There is no THE path. There mig= ht >>> be NO path. Every single request with THE path is always doomed to >>> fail. >> IIUC we've got to have some assurance that the path is legit for foren= sics. >> Technically I believe I understand and concur with what you are saying= >> Eric, but as a guy on the far end of the process I know I need to be >> able to reference a complete path to a FD. >> One which we believe did exist at the time the mod occurred. To me, >> sometimes isn't really good enough. But A path probably is. >> ... > >From the PoV of the process in question there was, at some point, A > path. That I agree with. But imagine I clone a new mount namespace > and don't share my changes with the parent namespace. Now I mount > something new in that child namespace. What is A path for a file in th= e > new mount? From the parent namespace there is NO path, ABSOLUTELY NO > PATH. (guess which mount namespace auditd lives in, by the way). From= > the PoV of the processes in the child mount namespace there is A path, > but it's possibly/probably completely meaningless to the > admin. /etc/shadow !=3D /etc/shadow the admin cares about... readlink= () > doesn't work in this case either. Sometimes there just plain is no > path. So yeah, I'm betting MOST of the time we can come up with A path= , > but that's not exactly what you want either :-( OK; interesting case. Now I hate namespaces. :-) Perhaps we'll have to get smarter in order to be able to work backwards through namespaces. Or if not solvable, maybe some of us will have to decide to not allow ad-hoc mounted namespaces. Just saying. This stuff matters. I'm assuming we get the namespace info in userland audit events? My RHEL6 versions are behind where you guys are... > >>>> 9) Can we get events for a watched file even when a user's permissio= ns do not >>>> allow full path resolution? >>> No. >> No? > Say I set a watch for failure to open /path/to/my/file. > If someone comes along and says open(/path/to/my/file) but they do not > have execute permissions on /path/to/ their request will be denied. No= t > because they didn't have permission to open /path/to/my/file, but > because they didn't have permission to open /path/to. Watches do not, > and can not, emit a rule for that. The rule you requested (failure to > open /path/to/my/file) was not violated. The kernel did not try to > open /path/to/my/file. It tried to open /path/to/ and died right there= =2E > If you care about things being unable to open /path/to/, put a watch > on /path/to (although I'm not 100% such watches actually work, but at > least the theory is right and maybe that could be fixed) I didn't match the "no" answer to what I read to be a more general questi= on. Per the STIG (& added) rules there are exit watches for EACCES and EPERM, which IIUC would be caught in your example. Not all the way down to the end of the path but to the point of failure. Good enough. So I probably misinterpreted the question. Your answer cleared it up nicely; thanks. Thx, LCB --=20 LC (Lenny) Bruzenak lenny@magitekltd.com --------------ms040804090704050809080207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEZDCC BGAwggNIoAMCAQICEwZQV0xKmXg6VpNOYV4AVY8RbPYwDQYJKoZIhvcNAQEFBQAwgYIxCzAJ BgNVBAYTAlVTMR4wHAYDVQQLExV3d3cueHJhbXBzZWN1cml0eS5jb20xJDAiBgNVBAoTG1hS YW1wIFNlY3VyaXR5IFNlcnZpY2VzIEluYzEtMCsGA1UEAxMkWFJhbXAgR2xvYmFsIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTE0MDgxNDA5NTMyMFoXDTE1MDgxNDE1NTMyMFowcTEd MBsGA1UEAwwUbGVubnlAbWFnaXRla2x0ZC5jb20xDjAMBgNVBAoMBXNtaW1lMQ4wDAYDVQQI DAVzbWltZTELMAkGA1UEBhMCVVMxIzAhBgkqhkiG9w0BCQEWFGxlbm55QG1hZ2l0ZWtsdGQu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyk/YzpnShgUImRJTL/rtYoP4 rP3rR9A45kty5KcQ+xaq7B2M/irmosxQ96hg1LcJrh9LEG9gmAjiQK32QT9hAND47Frag3+6 4txUSuiW4Wh1Q96avqg30hC0oZvylAyaqx1DRGw1jv3UVMyBOMWG7boxWOOPqIvBK6NaQGDD j74tfb+MyjRGLpUq6IUzVhMiHX1pRXSlprS0jH0rSQQrGZIGnqRT2+LlhbU6jYcBLS7dsS38 gHaKhs5hgSsFIT0hmHvF7EqKLIpeqA4sRCdtHUrjCjRXTo4G0SYcPSHJegR9UADWWsyXaK2l VMQG/yvczd/EcrJFaeTZTxQGzBInmwIDAQABo4HeMIHbMAsGA1UdDwQEAwIFoDATBgNVHSUE DDAKBggrBgEFBQcDBDAdBgNVHQ4EFgQUbdNQFOkqZZpvYP3Og5yjTF5MKi4wHwYDVR0jBBgw FoAUxk+iPQZjhAmczmLkBKyNXLXpthswQwYDVR0gBDwwOjA4BgpghkgBhv1kAgIBMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vc3NsLnRydXN0d2F2ZS5jb20vQ0EwMgYDVR0fBCswKTAnoCWg I4YhaHR0cDovL2NybC50cnVzdHdhdmUuY29tL1hHQ0EuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQA4p5zP1UtMZrLRslU6wXrprLWT3Rw4yeYYnayveaKb/MN9iKI95gQeAlObmSk00GU3EngH Y3EscFOYfQY9rkZCqSFSx+gc04FFBxFDrjs28McrD6MIcuFcRYLxri0QXMZ5yrkCw1sHwZHp 6R0/CvVcz7RvHREM108BAs/0SccZoTh2z9Py6IZcr+Ye3KsYpyET3Zu8Lw2VV7z24DntjMN6 3GC3pnbrLxadzxdAk5AkWo23FsNQElSJaG9PqoKV8blk1XI8dVQAtD7YBGI40sCW7VaYPZ0G tYdyGROQWMAN6gj1pUt9oeIlLbaobvq8u5Gahhc+cwMWNycKSyOQWf8eMYID7zCCA+sCAQEw gZowgYIxCzAJBgNVBAYTAlVTMR4wHAYDVQQLExV3d3cueHJhbXBzZWN1cml0eS5jb20xJDAi BgNVBAoTG1hSYW1wIFNlY3VyaXR5IFNlcnZpY2VzIEluYzEtMCsGA1UEAxMkWFJhbXAgR2xv YmFsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AhMGUFdMSpl4OlaTTmFeAFWPEWz2MAkGBSsO AwIaBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0 MTAyMjE5MzY0M1owIwYJKoZIhvcNAQkEMRYEFGXFUdxgTFIyKmk7wY8JkmcQL9/ZMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgasG CSsGAQQBgjcQBDGBnTCBmjCBgjELMAkGA1UEBhMCVVMxHjAcBgNVBAsTFXd3dy54cmFtcHNl Y3VyaXR5LmNvbTEkMCIGA1UEChMbWFJhbXAgU2VjdXJpdHkgU2VydmljZXMgSW5jMS0wKwYD VQQDEyRYUmFtcCBHbG9iYWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEwZQV0xKmXg6VpNO YV4AVY8RbPYwga0GCyqGSIb3DQEJEAILMYGdoIGaMIGCMQswCQYDVQQGEwJVUzEeMBwGA1UE CxMVd3d3LnhyYW1wc2VjdXJpdHkuY29tMSQwIgYDVQQKExtYUmFtcCBTZWN1cml0eSBTZXJ2 aWNlcyBJbmMxLTArBgNVBAMTJFhSYW1wIEdsb2JhbCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eQITBlBXTEqZeDpWk05hXgBVjxFs9jANBgkqhkiG9w0BAQEFAASCAQAgDE3GLMMD4WJZ9J+s mBXU3Z+1+ynr3oHmzw/YI3AnHXYGbfuiBZAQs206mlXRSVO8GGE9vWxO9CpAbglcjoyLzFbi Nvuzya70sSV2/6i+mUu1yDMtuyKLY2c+1aTYkUk2KcsXGo8GpHir11QuHdW0uRRx7irmbTYT UXsCWr+4yNMENK06ua4ScvR+gkZ+xgIsN90y9DrQ25dNlrvCs0qtyjUEnMgXSusZAYooKv9J 6HsFGQ8jMUNfRXL9Is1/Z4z2zmXvx+HERN9GpTKTxw6tOo+rdDW0NqU6OzyydEz68sutanmX 9d2Um8pHpXEyWhOo1usoi/UF5TJhqc7y6kOfAAAAAAAA --------------ms040804090704050809080207-- --===============7699632088265485738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7699632088265485738==--