From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tilden Doran D Subject: Excluding few executable from audit.rules in redhat6.5 Date: Mon, 17 Nov 2014 15:02:12 +0000 Message-ID: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4568566789953355633==" Return-path: Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAHF2HbS004713 for ; Mon, 17 Nov 2014 10:02:18 -0500 Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHF2DxH001934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Nov 2014 10:02:14 -0500 Content-Language: en-US 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 --===============4568566789953355633== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1A523eusaamb103erics_" --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1A523eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I am new to Redhat Audit logging. Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and SELinux is = enabled. We are getting lots of logs messages in /var/log/messages. type=3DSYSCALL msg=3Daudit(1416235337.083:2109222): arch=3Dc000003e syscall= =3D90 success=3Dyes exit=3D0 a0=3D7f52ae9f1a20 a1=3D3ff a2=3Dffffffffffffff= 88 a3=3Dfffffffffffffff0 items=3D1 ppid=3D1 pid=3D46859 auid=3D500 uid=3D34= 5 gid=3D345 euid=3D345 suid=3D345 fsuid=3D345 egid=3D345 sgid=3D345 fsgid= =3D345 tty=3D(none) ses=3D28 comm=3D"ohasd.bin" exe=3D"/opt/oracle_homes/or= acle/grid/11.2.0/bin/ohasd.bin" subj=3Dunconfined_u:unconfined_r:unconfined= _t:s0-s0:c0.c1023 key=3D"perm_mod" type=3DPATH msg=3Daudit(1416235337.083:2109222): item=3D0 name=3D"/opt/orac= le_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703" inode=3D4718596= dev=3Dfd:00 mode=3D041755 ouid=3D345 ogid=3D345 rdev=3D00:00 obj=3Dunconfi= ned_u:object_r:usr_t:s0 nametype=3DNORMAL Later we found and removed message type "CWD", but still we are getting lo= t of logs. And also found that the below mentioned executable are creating the problem= . 13351. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.b= in (none) ? 500 1599360 13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle= (none) ? 500 1599354 13353. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/grid/11.2.0/bin/oraagen= t.bin (none) ? 500 1599361 Can you please help me in excluding the above mentioned Executable `s in t= he audit. rules files . Thanks in advance. --Tilden Ericsson AB --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1A523eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I am new to Redhat Audit logging.

Our Server Configurations:  Redhat 6.5 OS and O= racle 11g ,  and SELinux is enabled.

 

We are getting lots of logs messages  in /var/l= og/messages.

 

type=3DSYSCALL msg=3Daudit(1416235337.083:2109222): = arch=3Dc000003e syscall=3D90 success=3Dyes exit=3D0 a0=3D7f52ae9f1a20 a1=3D= 3ff a2=3Dffffffffffffff88 a3=3Dfffffffffffffff0 items=3D1 ppid=3D1 pid=3D46= 859 auid=3D500 uid=3D345 gid=3D345 euid=3D345 suid=3D345 fsuid=3D345 egid= =3D345 sgid=3D345 fsgid=3D345 tty=3D(none) ses=3D28 comm=3D"ohasd.bin" = exe=3D"/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin" subj= =3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3D"perm_m= od"

type=3DPATH msg=3Daudit(1416235337.083:2109222): ite= m=3D0 name=3D"/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x33= 64/A7679703" inode=3D4718596 dev=3Dfd:00 mode=3D041755 ouid=3D345 ogid= =3D345 rdev=3D00:00 obj=3Dunconfined_u:object_r:usr_t:s0 nametype=3DNORMAL<= o:p>

 

 

Later we found and removed message type “CWD&#= 8221;, but still we are  getting lot of logs.

 

And also found that the below mentioned executable a= re creating the problem.

 

13351. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/= grid/11.2.0/bin/ohasd.bin (none) ? 500 1599360

13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/= rdbms/11.2.0/bin/oracle (none) ? 500 1599354

13353. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/= grid/11.2.0/bin/oraagent.bin (none) ? 500 1599361

 

Can you  please help me in excluding the above = mentioned Executable `s in the audit. rules files .

 

Thanks in advance. 

 

 

--Tilden

Ericsson AB

 

 

 

--_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1A523eusaamb103erics_-- --===============4568566789953355633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4568566789953355633==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Mon, 17 Nov 2014 10:30:38 -0500 Message-ID: <2049003.dURlEamkhM@x2> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> 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 On Monday, November 17, 2014 03:02:12 PM Tilden Doran D wrote: > I am new to Redhat Audit logging. > Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and SELinux is > enabled. > > We are getting lots of logs messages in /var/log/messages. > > type=SYSCALL msg=audit(1416235337.083:2109222): arch=c000003e syscall=90 > success=yes exit=0 a0=7f52ae9f1a20 a1=3ff a2=ffffffffffffff88 > a3=fffffffffffffff0 items=1 ppid=1 pid=46859 auid=500 uid=345 gid=345 > euid=345 suid=345 fsuid=345 egid=345 sgid=345 fsgid=345 tty=(none) ses=28 > comm="ohasd.bin" exe="/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="perm_mod" > type=PATH msg=audit(1416235337.083:2109222): item=0 > name="/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A7679703" > inode=4718596 dev=fd:00 mode=041755 ouid=345 ogid=345 rdev=00:00 > obj=unconfined_u:object_r:usr_t:s0 nametype=NORMAL > > > Later we found and removed message type "CWD", but still we are getting lot > of logs. > > And also found that the below mentioned executable are creating the problem. > > 13351. 11/16/2014 18:11:34 > /opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500 1599360 > 13352. 11/16/2014 18:11:34 /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle > (none) ? 500 1599354 13353. 11/16/2014 18:11:34 > /opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500 1599361 > > Can you please help me in excluding the above mentioned Executable `s in > the audit. rules files . Well, what do you really want to do? In general, I'd look at the original auditing rule to see if its scope can be narrowed. In this case, it appears that you are wanting all calls to chmod. Why? Are you more concerned with failed calls to chmod, meaning a user is trying to change system files? Are system daemons calling chmod OK? Or do you really want everything? Or do you want no events at all for that daemon no matter what the syscall? The event you are showing is that app successfully making a directory world writable/readable. Its setting the sticky bit, so its "safe." -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Mon, 17 Nov 2014 10:14:59 -0600 Message-ID: <546A1F03.3030805@magitekltd.com> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <2049003.dURlEamkhM@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4897049509049351945==" Return-path: Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAHGEt6K016821 for ; Mon, 17 Nov 2014 11:14:55 -0500 Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAHGEqlX014295 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 17 Nov 2014 11:14:53 -0500 Received: by mail-oi0-f46.google.com with SMTP id h136so2290199oig.33 for ; Mon, 17 Nov 2014 08:14:52 -0800 (PST) Received: from [192.168.31.226] (65-36-126-38.dyn.grandenetworks.net. [65.36.126.38]) by mx.google.com with ESMTPSA id e5sm6606702oic.16.2014.11.17.08.14.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 08:14:51 -0800 (PST) In-Reply-To: <2049003.dURlEamkhM@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: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a cryptographically signed message in MIME format. --===============4897049509049351945== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070309040002010207000207" This is a cryptographically signed message in MIME format. --------------ms070309040002010207000207 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/17/2014 09:30 AM, Steve Grubb wrote: > Well, what do you really want to do? In general, I'd look at the origin= al=20 > auditing rule to see if its scope can be narrowed. In this case, it app= ears=20 > that you are wanting all calls to chmod. Why? Are you more concerned wi= th=20 > failed calls to chmod, meaning a user is trying to change system files?= Are=20 > system daemons calling chmod OK? Or do you really want everything? Or d= o you=20 > want no events at all for that daemon no matter what the syscall? > > The event you are showing is that app successfully making a directory w= orld=20 > writable/readable. Its setting the sticky bit, so its "safe." I think this is auditing because the supplied STIG rules specify it. The "perm_mod" key is the hint. You probably do not want to remove this rule for all chmod syscalls. You cannot exclude an executable itself from the rule set by name. The "exclude" option only applies to event types. =20 You could exclude it by type, except it is running as a generic unconfined_t. Perhaps it can be mitigated by "-F path !=3D" or something similar.= Check the auditctl man page for options. LCB --=20 LC (Lenny) Bruzenak lenny@magitekltd.com --------------ms070309040002010207000207 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 MTExNzE2MTQ1OVowIwYJKoZIhvcNAQkEMRYEFMqlTXEFvPgIfB1J/k9rClBhAAfQMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgasG CSsGAQQBgjcQBDGBnTCBmjCBgjELMAkGA1UEBhMCVVMxHjAcBgNVBAsTFXd3dy54cmFtcHNl Y3VyaXR5LmNvbTEkMCIGA1UEChMbWFJhbXAgU2VjdXJpdHkgU2VydmljZXMgSW5jMS0wKwYD VQQDEyRYUmFtcCBHbG9iYWwgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEwZQV0xKmXg6VpNO YV4AVY8RbPYwga0GCyqGSIb3DQEJEAILMYGdoIGaMIGCMQswCQYDVQQGEwJVUzEeMBwGA1UE CxMVd3d3LnhyYW1wc2VjdXJpdHkuY29tMSQwIgYDVQQKExtYUmFtcCBTZWN1cml0eSBTZXJ2 aWNlcyBJbmMxLTArBgNVBAMTJFhSYW1wIEdsb2JhbCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eQITBlBXTEqZeDpWk05hXgBVjxFs9jANBgkqhkiG9w0BAQEFAASCAQBXzGAMpraqHp5gActY IakQ/MLs9nywRZFDxgy9c369IGbWH3vXIRUEHYj4Hzk6tdIo2Q0YPpOTzTk6W4cPGAZILDul TFPPx0a2oiA6+2E2v1avwcyCb8RlxsdwiA4kksqBmP5GOOfc19cN7ndVb+rj4HKDuFWVFTYg bw0B3eSpaybojrCVVy8pOSf5asRV0vBFS0b6Efo6ntzqSw1bDSLi6X99xblkFElQ9DIHee+l 1wgxGnB2zXuD0VpXSGi9cztEZx1R7LhE8Mqe5wOpDTQ69SU4KK7RWmzgziqOvhFU9KtMcMYO aMjBeTkt7F6lpda5bvm/AShj/GzXQEj8DWoSAAAAAAAA --------------ms070309040002010207000207-- --===============4897049509049351945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4897049509049351945==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Mon, 17 Nov 2014 11:42:17 -0500 Message-ID: <2779362.U37ZQvvdpt@x2> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <2049003.dURlEamkhM@x2> <546A1F03.3030805@magitekltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <546A1F03.3030805@magitekltd.com> 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 On Monday, November 17, 2014 10:14:59 AM LC Bruzenak wrote: > On 11/17/2014 09:30 AM, Steve Grubb wrote: > > Well, what do you really want to do? In general, I'd look at the original > > auditing rule to see if its scope can be narrowed. In this case, it > > appears > > that you are wanting all calls to chmod. Why? Are you more concerned with > > failed calls to chmod, meaning a user is trying to change system files? > > Are > > system daemons calling chmod OK? Or do you really want everything? Or do > > you want no events at all for that daemon no matter what the syscall? > > > > The event you are showing is that app successfully making a directory > > world > > writable/readable. Its setting the sticky bit, so its "safe." > > I think this is auditing because the supplied STIG rules specify it. > The "perm_mod" key is the hint. You probably do not want to remove this > rule for all chmod syscalls. OK. Missed that. Then looking at the rule, it has an exclusion for daemons because its only concerned with auid>=500. So, that means that someone restarted the daemon by hand rather than rebooting the system If a temporary fix is needed until the systems is rebooted, then one could do this: auditctl -A exit,never -S chmod -F uid=345 That will get rid of all chmod calls by user account 345. Notice the capital A, this places the rule at the beginning because the rule that matches first wins. I would not make that a permanent rule, just a workaround until it can be rebooted. But also note that it could trigger other rules because it has a user's auid. > You cannot exclude an executable itself from the rule set by name. > The "exclude" option only applies to event types. > > You could exclude it by type, except it is running as a generic > unconfined_t. Yeah, as a daemon it should be something else. Unconfined is only from a user session. Daemons get initrc_t when they are unknown. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Mon, 17 Nov 2014 12:09:10 -0500 Message-ID: <10981052.36n0eHvUFY@x2> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <546A1F03.3030805@magitekltd.com> <2779362.U37ZQvvdpt@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from x2.localnet (vpn-238-30.phx2.redhat.com [10.3.238.30]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAHH99aR022359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Nov 2014 12:09:09 -0500 In-Reply-To: <2779362.U37ZQvvdpt@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: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Monday, November 17, 2014 11:42:17 AM Steve Grubb wrote: > On Monday, November 17, 2014 10:14:59 AM LC Bruzenak wrote: > > On 11/17/2014 09:30 AM, Steve Grubb wrote: > > > Well, what do you really want to do? In general, I'd look at the > > > original > > > auditing rule to see if its scope can be narrowed. In this case, it > > > appears > > > that you are wanting all calls to chmod. Why? Are you more concerned > > > with > > > failed calls to chmod, meaning a user is trying to change system files? > > > Are > > > system daemons calling chmod OK? Or do you really want everything? Or do > > > you want no events at all for that daemon no matter what the syscall? > > > > > > The event you are showing is that app successfully making a directory > > > world > > > writable/readable. Its setting the sticky bit, so its "safe." > > > > I think this is auditing because the supplied STIG rules specify it. > > The "perm_mod" key is the hint. You probably do not want to remove this > > rule for all chmod syscalls. > > OK. Missed that. Then looking at the rule, it has an exclusion for daemons > because its only concerned with auid>=500. So, that means that someone > restarted the daemon by hand rather than rebooting the system > > If a temporary fix is needed until the systems is rebooted, then one could > do this: > > auditctl -A exit,never -S chmod -F uid=345 A correction is in order, this likely needs arch fields to be added. It should have been: auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345 -Steve > That will get rid of all chmod calls by user account 345. Notice the capital > A, this places the rule at the beginning because the rule that matches > first wins. I would not make that a permanent rule, just a workaround until > it can be rebooted. But also note that it could trigger other rules because > it has a user's auid. > > > You cannot exclude an executable itself from the rule set by name. > > The "exclude" option only applies to event types. > > > > You could exclude it by type, except it is running as a generic > > unconfined_t. > > Yeah, as a daemon it should be something else. Unconfined is only from a > user session. Daemons get initrc_t when they are unknown. > > -Steve > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tilden Doran D Subject: RE: Excluding few executable from audit.rules in redhat6.5 Date: Tue, 18 Nov 2014 10:10:25 +0000 Message-ID: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C66D@eusaamb103.ericsson.se> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <2049003.dURlEamkhM@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7283316726404452369==" Return-path: In-Reply-To: <2049003.dURlEamkhM@x2> Content-Language: en-US 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 , "linux-audit@redhat.com" List-Id: linux-audit@redhat.com --===============7283316726404452369== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C66Deusaamb103erics_" --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C66Deusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find my response. Sorry for the delay, I am in different Time zone. Well, what do you really want to do? [Tilden] we want to implement audit Logging in Rhel 6.5. for the followin= g events/actions. Login, logout, switch user (su): Rebooting the system, adding and deleting users, changing auditing and logg= ing parameters, changing system clock:(all administrative actions), Process start and stop User executes a command In general, I'd look at the original auditing rule to see if its scope can= be narrowed. In this case, it appears that you are wanting all calls to ch= mod. Why? [Tilden] My Audit.rules file for your reference. If possible please sugge= st me to narrowed down the audit rules for my requirement. ## First rule - delete all -D ## Increase the buffers to survive stress events. ## Make this bigger for busy systems -b 8192 ## Set failure mode to panic -f 2 ## Things that could affect time -a always,exit -F arch=3Db64 -S adjtimex -S settimeofday -k time-change -a always,exit -F arch=3Db64 -S clock_settime -F a0=3D0 -k time-change -w /etc/localtime -p wa -k time-change ## Things that affect identity -w /etc/group -p wa -k identity -w /etc/passwd -p wa -k identity -w /etc/gshadow -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/security/opasswd -p wa -k identity ## Things that could affect system locale -a always,exit -F arch=3Db64 -S sethostname -S setdomainname -k system-loca= le -w /etc/issue -p wa -k system-locale -w /etc/issue.net -p wa -k system-locale -w /etc/hosts -p wa -k system-locale -w /etc/sysconfig/network -p wa -k system-locale ## Things that could affect MAC policy -w /etc/selinux/ -p wa -k MAC-policy ## - Logon (unsuccessful and successful) and logout (successful) -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k logins ##- Discretionary access control permission modification (unsuccessful ## and successful use of chown/chmod) -a always,exit -F arch=3Db64 -S chmod -S fchmod -S fchmodat -F auid>=3D500 = -F auid!=3D4294967295 -k perm_mod -a always,exit -F arch=3Db64 -S chown -S fchown -S fchownat -S lchown -F au= id>=3D500 -F auid!=3D4294967295 -k perm_mod -a always,exit -F arch=3Db64 -S setxattr -S lsetxattr -S fsetxattr -S remov= exattr -S lremovexattr -S fremovexattr -F auid>=3D500 -F auid!=3D4294967295= -k perm_mod ##- Unauthorized access attempts to files (unsuccessful) -a always,exit -F arch=3Db64 -S creat -S open -S openat -S open_by_handle_a= t -S truncate -F exit=3D-EACCES -F auid>=3D500 -F auid!=3D4294967295 -k acc= ess -a always,exit -F arch=3Db64 -S creat -S open -S openat -S open_by_handle_a= t -S truncate -F exit=3D-EPERM -F auid>=3D500 -F auid!=3D4294967295 -k acce= ss ##- Use of privileged commands (unsuccessful and successful) ## use find /bin -type f -perm -04000 2>/dev/null and put all those files i= n a rule like this -a always,exit -F path=3D/bin/ping -F perm=3Dx -F auid>=3D500 -F auid!=3D42= 94967295 -k privileged ##- Export to media (successful) -a always,exit -F arch=3Db64 -S mount -F auid>=3D500 -F auid!=3D4294967295 = -k export ## sudo cannot record the action. -w /etc/sudoers -p wa -k actions ## Optional - could be an attempt to bypass audit or simply legacy program -a always,exit -F arch=3Db64 -S personality -F a0!=3D4294967295 -k bypass Are you more concerned with failed calls to chmod, meaning a user is trying= to change system files? [Tilden] Yes, I am more concern with User level auditing. i.e. what and = all actions performed by the user should be logged. we don't want the Syste= m process or any executable to generate logs. Are system daemons calling chmod OK? Or do you really want everything? [Tilden] We don't want the System process / daemons logs Or do you want no events at all for that daemon no matter what the syscall= ? [Tilden] Yes, we found 3 daemons which is causing the issue of generati= ng lot of logs message, so we want to restrict those daemons from generatin= g log messages, as we want only User level audit logs. Thanks Tilden -----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Monday, November 17, 2014 9:01 PM To: linux-audit@redhat.com Cc: Tilden Doran D Subject: Re: Excluding few executable from audit.rules in redhat6.5 On Monday, November 17, 2014 03:02:12 PM Tilden Doran D wrote: > I am new to Redhat Audit logging. > Our Server Configurations: Redhat 6.5 OS and Oracle 11g , and > SELinux is enabled. > > We are getting lots of logs messages in /var/log/messages. > > type=3DSYSCALL msg=3Daudit(1416235337.083:2109222): arch=3Dc000003e > syscall=3D90 success=3Dyes exit=3D0 a0=3D7f52ae9f1a20 a1=3D3ff > a2=3Dffffffffffffff88 > a3=3Dfffffffffffffff0 items=3D1 ppid=3D1 pid=3D46859 auid=3D500 uid=3D345= gid=3D345 > euid=3D345 suid=3D345 fsuid=3D345 egid=3D345 sgid=3D345 fsgid=3D345 tty= =3D(none) > ses=3D28 comm=3D"ohasd.bin" exe=3D"/opt/oracle_homes/oracle/grid/11.2.0/b= in/ohasd.bin" > subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3D"perm_= mod" > type=3DPATH msg=3Daudit(1416235337.083:2109222): item=3D0 > name=3D"/opt/oracle_homes/oracle/grid/11.2.0/auth/ohasd/dl360x3364/A76797= 03" > inode=3D4718596 dev=3Dfd:00 mode=3D041755 ouid=3D345 ogid=3D345 rdev=3D00= :00 > obj=3Dunconfined_u:object_r:usr_t:s0 nametype=3DNORMAL > > > Later we found and removed message type "CWD", but still we are > getting lot of logs. > > And also found that the below mentioned executable are creating the probl= em. > > 13351. 11/16/2014 18:11:34 > /opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin (none) ? 500 > 1599360 13352. 11/16/2014 18:11:34 > /opt/oracle_homes/oracle/rdbms/11.2.0/bin/oracle > (none) ? 500 1599354 13353. 11/16/2014 18:11:34 > /opt/oracle_homes/oracle/grid/11.2.0/bin/oraagent.bin (none) ? 500 > 1599361 > > Can you please help me in excluding the above mentioned Executable `s > in the audit. rules files . Well, what do you really want to do? In general, I'd look at the original a= uditing rule to see if its scope can be narrowed. In this case, it appears = that you are wanting all calls to chmod. Why? Are you more concerned with f= ailed calls to chmod, meaning a user is trying to change system files? Are = system daemons calling chmod OK? Or do you really want everything? Or do yo= u want no events at all for that daemon no matter what the syscall? The event you are showing is that app successfully making a directory world= writable/readable. Its setting the sticky bit, so its "safe." -Steve --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C66Deusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

Please find my response. Sorry for the delay, I a= m in different Time zone.

 

 

Well, what do you really want to do?

 

[Tilden]  we w= ant to  implement audit Logging in Rhel 6.5. for the following events/= actions.

Login, logout, swit= ch user (su):

Rebooting the syste= m, adding and deleting users, changing auditing and logging parameters, cha= nging system clock:(all administrative actions),  

Process start and s= top

User executes a com= mand

 

 

 In general, I'd look at the original auditi= ng rule to see if its scope can be narrowed. In this case, it appears that = you are wanting all calls to chmod. Why?

[Tilden]  &nbs= p;My Audit.rules file for your reference. If possible please suggest me to = narrowed down the audit rules for my requirement.

 

 

 

## First rule - delete all

-D

 

## Increase the buffers to survive stress events.=

## Make this bigger for busy systems

-b 8192

 

## Set failure mode to panic

-f 2

 

## Things that could affect time

-a always,exit -F arch=3Db64 -S adjtimex -S setti= meofday -k time-change

-a always,exit -F arch=3Db64 -S clock_settime -F = a0=3D0 -k time-change

-w /etc/localtime -p wa -k time-change=

 

## Things that affect identity

-w /etc/group -p wa -k identity

-w /etc/passwd -p wa -k identity

-w /etc/gshadow -p wa -k identity

-w /etc/shadow -p wa -k identity

-w /etc/security/opasswd -p wa -k identity

 

## Things that could affect system locale

-a always,exit -F arch=3Db64 -S sethostname -S se= tdomainname -k system-locale

-w /etc/issue -p wa -k system-locale

-w /etc/issue.net -p wa -k system-locale

-w /etc/hosts -p wa -k system-locale

-w /etc/sysconfig/network -p wa -k system-locale<= o:p>

 

## Things that could affect MAC policy=

-w /etc/selinux/ -p wa -k MAC-policy

 

## - Logon (unsuccessful and successful) and logo= ut (successful)

-w /var/log/tallylog -p wa -k logins

-w /var/run/faillock/ -p wa -k logins<= /p>

-w /var/log/lastlog -p wa -k logins

 

##- Discretionary access control permission modif= ication (unsuccessful

## and successful use of chown/chmod)<= /p>

-a always,exit -F arch=3Db64 -S chmod -S fchmod -= S fchmodat -F auid>=3D500 -F auid!=3D4294967295 -k perm_mod

-a always,exit -F arch=3Db64 -S chown -S fchown -= S fchownat -S lchown -F auid>=3D500 -F auid!=3D4294967295 -k perm_mod

-a always,exit -F arch=3Db64 -S setxattr -S lsetx= attr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>= ;=3D500 -F auid!=3D4294967295 -k perm_mod

 

##- Unauthorized access attempts to files (unsucc= essful)

-a always,exit -F arch=3Db64 -S creat -S open -S = openat -S open_by_handle_at -S truncate -F exit=3D-EACCES -F auid>=3D500= -F auid!=3D4294967295 -k access

-a always,exit -F arch=3Db64 -S creat -S open -S = openat -S open_by_handle_at -S truncate -F exit=3D-EPERM -F auid>=3D500 = -F auid!=3D4294967295 -k access

 

##- Use of privileged commands (unsuccessful and = successful)

## use find /bin -type f -perm -04000 2>/dev/n= ull and put all those files in a rule like this

-a always,exit -F path=3D/bin/ping -F perm=3Dx -F= auid>=3D500 -F auid!=3D4294967295 -k privileged

 

##- Export to media (successful)

-a always,exit -F arch=3Db64 -S mount -F auid>= =3D500 -F auid!=3D4294967295 -k export

 

## sudo cannot record the action.

-w /etc/sudoers -p wa -k actions

 

## Optional - could be an attempt to bypass audit= or simply legacy program

-a always,exit -F arch=3Db64 -S personality -F a0= !=3D4294967295 -k bypass

 

Are you more concerned with failed calls to chmod= , meaning a user is trying to change system files?

[Tilden]  &nbs= p; Yes, I am more concern with User level auditing. i.e. what and all = actions performed by the user should be logged. we don’t want the Sys= tem process or any executable to generate logs.

 

 

Are system daemons calling chmod OK? Or do you re= ally want everything?

[Tilden]  &nbs= p; We don’t want the System process / daemons logs

 

 Or do you want no events at all for that da= emon no matter what the syscall?

[Tilden]  &nbs= p;  Yes, we found 3 daemons which is causing the issue of generat= ing lot of logs message, so we want to restrict those daemons from generati= ng log messages, as we want only User level audit logs.

 

 

Thanks

Tilden

 

 

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, November 17, 2014 9:01 PM
To: linux-audit@redhat.com
Cc: Tilden Doran D
Subject: Re: Excluding few executable from audit.rules in redhat6.5

 

On Monday, November 17, 2014 03:02:12 PM Tilden D= oran D wrote:

> I am new to Redhat Audit logging.=

> Our Server Configurations:  Redhat 6.5 = OS and Oracle 11g ,  and

> SELinux is enabled.

>

> We are getting lots of logs messages  i= n /var/log/messages.

>

> type=3DSYSCALL msg=3Daudit(1416235337.083:21= 09222): arch=3Dc000003e

> syscall=3D90 success=3Dyes exit=3D0 a0=3D7f5= 2ae9f1a20 a1=3D3ff

> a2=3Dffffffffffffff88

> a3=3Dfffffffffffffff0 items=3D1 ppid=3D1 pid= =3D46859 auid=3D500 uid=3D345 gid=3D345

> euid=3D345 suid=3D345 fsuid=3D345 egid=3D345= sgid=3D345 fsgid=3D345 tty=3D(none)

> ses=3D28 comm=3D"ohasd.bin" exe=3D= "/opt/oracle_homes/oracle/grid/11.2.0/bin/ohasd.bin"

> subj=3Dunconfined_u:unconfined_r:unconfined_= t:s0-s0:c0.c1023 key=3D"perm_mod"

> type=3DPATH msg=3Daudit(1416235337.083:21092= 22): item=3D0

> name=3D"/opt/oracle_homes/oracle/grid/1= 1.2.0/auth/ohasd/dl360x3364/A7679703"

> inode=3D4718596 dev=3Dfd:00 mode=3D041755 ou= id=3D345 ogid=3D345 rdev=3D00:00

> obj=3Dunconfined_u:object_r:usr_t:s0 nametyp= e=3DNORMAL

>

>

> Later we found and removed message type &quo= t;CWD", but still we are 

> getting lot of logs.

>

> And also found that the below mentioned exec= utable are creating the problem.

>

> 13351. 11/16/2014 18:11:34

> /opt/oracle_homes/oracle/grid/11.2.0/bin/oha= sd.bin (none) ? 500

> 1599360 13352. 11/16/2014 18:11:34

> /opt/oracle_homes/oracle/rdbms/11.2.0/bin/or= acle

> (none) ? 500 1599354 13353. 11/16/2014 18:11= :34

> /opt/oracle_homes/oracle/grid/11.2.0/bin/ora= agent.bin (none) ? 500

> 1599361

>

> Can you  please help me in excluding th= e above mentioned Executable `s

> in the audit. rules files .

 

Well, what do you really want to do? In general, = I'd look at the original auditing rule to see if its scope can be narrowed.= In this case, it appears that you are wanting all calls to chmod. Why? Are= you more concerned with failed calls to chmod, meaning a user is trying to change system files? Are system daem= ons calling chmod OK? Or do you really want everything? Or do you want no e= vents at all for that daemon no matter what the syscall?

 

The event you are showing is that app successfull= y making a directory world writable/readable. Its setting the sticky bit, s= o its "safe."

 

-Steve

 

--_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C66Deusaamb103erics_-- --===============7283316726404452369== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7283316726404452369==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tilden Doran D Subject: RE: Excluding few executable from audit.rules in redhat6.5 Date: Tue, 18 Nov 2014 10:22:55 +0000 Message-ID: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C686@eusaamb103.ericsson.se> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <546A1F03.3030805@magitekltd.com> <2779362.U37ZQvvdpt@x2> <10981052.36n0eHvUFY@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <10981052.36n0eHvUFY@x2> Content-Language: en-US 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 , "linux-audit@redhat.com" List-Id: linux-audit@redhat.com Hi auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345 we would require a permanent fix. If UID=345 is used, I believe that all auditing functionality will not work for user ID=345, I mean if the userId(345) is logging in manually to the system and does some operation that will also be exclude. We want User inventions logs messages to be captured but exclude the System generated logs. To be more detail. Ohasd.bin process is started by the user( while starting the database process) we want to captured this log. But after that the ohasd.bin process is running in background and it does lot of read write operations, we don't want those logs. Can you please let us know the way forward. thanks Tilden -----Original Message----- From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb Sent: Monday, November 17, 2014 10:39 PM To: linux-audit@redhat.com Subject: Re: Excluding few executable from audit.rules in redhat6.5 On Monday, November 17, 2014 11:42:17 AM Steve Grubb wrote: > On Monday, November 17, 2014 10:14:59 AM LC Bruzenak wrote: > > On 11/17/2014 09:30 AM, Steve Grubb wrote: > > > Well, what do you really want to do? In general, I'd look at the > > > original auditing rule to see if its scope can be narrowed. In > > > this case, it appears that you are wanting all calls to chmod. > > > Why? Are you more concerned with failed calls to chmod, meaning a > > > user is trying to change system files? > > > Are > > > system daemons calling chmod OK? Or do you really want everything? > > > Or do you want no events at all for that daemon no matter what the syscall? > > > > > > The event you are showing is that app successfully making a > > > directory world writable/readable. Its setting the sticky bit, so > > > its "safe." > > > > I think this is auditing because the supplied STIG rules specify it. > > The "perm_mod" key is the hint. You probably do not want to remove > > this rule for all chmod syscalls. > > OK. Missed that. Then looking at the rule, it has an exclusion for > daemons because its only concerned with auid>=500. So, that means that > someone restarted the daemon by hand rather than rebooting the system > > If a temporary fix is needed until the systems is rebooted, then one > could do this: > > auditctl -A exit,never -S chmod -F uid=345 A correction is in order, this likely needs arch fields to be added. It should have been: auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A exit,never -F arch=b64 -S chmod -F uid=345 -Steve > That will get rid of all chmod calls by user account 345. Notice the > capital A, this places the rule at the beginning because the rule that > matches first wins. I would not make that a permanent rule, just a > workaround until it can be rebooted. But also note that it could > trigger other rules because it has a user's auid. > > > You cannot exclude an executable itself from the rule set by name. > > The "exclude" option only applies to event types. > > > > You could exclude it by type, except it is running as a generic > > unconfined_t. > > Yeah, as a daemon it should be something else. Unconfined is only from > a user session. Daemons get initrc_t when they are unknown. > > -Steve > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Tue, 18 Nov 2014 10:25:45 -0500 Message-ID: <1748821.1UEmklyQaj@x2> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <10981052.36n0eHvUFY@x2> <08DF6CD1326DBF4A80321CEA93761E5F1CB1C686@eusaamb103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C686@eusaamb103.ericsson.se> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tilden Doran D Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com On Tuesday, November 18, 2014 10:22:55 AM Tilden Doran D wrote: > Hi > > auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 auditctl -A > exit,never -F arch=b64 -S chmod -F uid=345 > > we would require a permanent fix. If UID=345 is used, I believe that all > auditing functionality will not work for user ID=345, Because the events shown are not translated, I can't tell what account 345 is. I am assuming by its low number that its a system account. The rule above drops all auditing of chmod syscalls for the 345 user account. > I mean if the userId(345) is logging in manually to the system and does some > operation that will also be exclude. Again, I can onlt speculate what that account is. If its a daemon, then it should have auid=-1 and the system works fine. Because the auid is 500, that tells me that user 500 started it. Because uid!=auid, I assume its either setuid or user 500 changed to root and then issued, "service ohasd restart". Its one or the other. If user 500 changed to root and restarted the daemon, then a reboot will fix everything and a permanent solution is not needed. Or you can put the rule in depending on how often this happens. But if this is for more than one system, then I'd use the 345 user's name so that auditctl looks it up in case its different on each machine. reserved accounts are generally under 200. > We want User inventions logs messages to be > captured but exclude the System generated logs. The rules you gave have this in them: -F auid>=500 -F auid!=4294967295 This is to exclude daemons because they have auid of -1 (unless restarted by hand). > To be more detail. > > Ohasd.bin process is started by the user( while starting the database > process) we want to captured this log. The database is not started by the system on boot? Is this a system daemon or a user session daemon? > But after that the ohasd.bin process > is running in background and it does lot of read write operations, we don't > want those logs. > > Can you please let us know the way forward. I am not familiar with that program, so I still need some answers to help you figure out the right way to get rid of the events. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tilden Doran D Subject: RE: Excluding few executable from audit.rules in redhat6.5 Date: Wed, 19 Nov 2014 05:38:24 +0000 Message-ID: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C78A@eusaamb103.ericsson.se> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <10981052.36n0eHvUFY@x2> <08DF6CD1326DBF4A80321CEA93761E5F1CB1C686@eusaamb103.ericsson.se> <1748821.1UEmklyQaj@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5440743320468327507==" Return-path: In-Reply-To: <1748821.1UEmklyQaj@x2> Content-Language: en-US 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 --===============5440743320468327507== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C78Aeusaamb103erics_" --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C78Aeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, Yes, you are correct. We login as User 500 and switch user to oracle and i= ssue the command. The User 345 is oracle user. Which is used for oracle related activities in= the system. The command which we issue is srvctl stop/start database. We always install= oracle and start manually for the first time. As you mentioned, on reboot the system, it not generating too many logs. Bu= t the problem is, we cannot reboot the system every time, which only requi= res DB restart. Because application also be hosted in the same system. The Srvctl command internally starts the ohasd.bin. So can we avoid it, I mean do we have an option to exclude the ohasd.bin by= using something like "-F exe!=3Dohasd.bin " or "-F path!=3D ...." . I trie= d both, it is not working. Because "-F UID!=3D345" will restrict all the logs. Can we restrict the l= og which is generated by that particular process/application. ? Thanks Tilden -----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Tuesday, November 18, 2014 8:56 PM To: Tilden Doran D Cc: linux-audit@redhat.com Subject: Re: Excluding few executable from audit.rules in redhat6.5 On Tuesday, November 18, 2014 10:22:55 AM Tilden Doran D wrote: > Hi > > auditctl -A exit,never -F arch=3Db32 -S chmod -F uid=3D345 auditctl -A > exit,never -F arch=3Db64 -S chmod -F uid=3D345 > > we would require a permanent fix. If UID=3D345 is used, I believe > that all auditing functionality will not work for user ID=3D345, Because the events shown are not translated, I can't tell what account 345 = is. I am assuming by its low number that its a system account. The rule above d= rops all auditing of chmod syscalls for the 345 user account. > I mean if the userId(345) is logging in manually to the system and does s= ome > operation that will also be exclude. Again, I can onlt speculate what that account is. If its a daemon, then it should have auid=3D-1 and the system works fine. Because the auid is 500, t= hat tells me that user 500 started it. Because uid!=3Dauid, I assume its either setuid or user 500 changed to root and then issued, "service ohasd restart"= . Its one or the other. If user 500 changed to root and restarted the daemon, then a reboot will fi= x everything and a permanent solution is not needed. Or you can put the rule = in depending on how often this happens. But if this is for more than one syste= m, then I'd use the 345 user's name so that auditctl looks it up in case its different on each machine. reserved accounts are generally under 200. > We want User inventions logs messages to be > captured but exclude the System generated logs. The rules you gave have this in them: -F auid>=3D500 -F auid!=3D4294967295 This is to exclude daemons because they have auid of -1 (unless restarted b= y hand). > To be more detail. > > Ohasd.bin process is started by the user( while starting the database > process) we want to captured this log. The database is not started by the system on boot? Is this a system daemon = or a user session daemon? > But after that the ohasd.bin process > is running in background and it does lot of read write operations, we don= 't > want those logs. > > Can you please let us know the way forward. I am not familiar with that program, so I still need some answers to help y= ou figure out the right way to get rid of the events. -Steve --_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C78Aeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 

Yes, you are correct. We login as User 500 and sw= itch user to oracle  and issue the command.

 

The User 345 is oracle user. Which is used for oracl= e related activities in the system.

 

The command which we issue is srvctl stop/start d= atabase. We always install oracle and start manually for the first time.

As you mentioned, on reboot the system, it not ge= nerating too many logs. But the problem is,  we cannot reboot the syst= em every time, which only requires DB restart.  Because application al= so be hosted in the same system.

 

The Srvctl command internally starts the ohasd.bi= n.

So can we avoid it, I mean do we have an option t= o exclude the ohasd.bin by using something like "-F exe!=3Dohasd.bin &= quot; or "-F path!=3D ...." . I tried both, it is not working.

 

Because "-F UID!=3D345" will  rest= rict all the logs.  Can we restrict the log which is generated by that= particular process/application.  ?

 

 

Thanks

Tilden

 

 

 

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, November 18, 2014 8:56 PM
To: Tilden Doran D
Cc: linux-audit@redhat.com
Subject: Re: Excluding few executable from audit.rules in redhat6.5

 

On Tuesday, November 18, 2014 10:22:55 AM Tilden = Doran D wrote:

> Hi

>

> auditctl -A exit,never -F arch=3Db32 -S chmo= d -F uid=3D345 auditctl -A

> exit,never -F arch=3Db64 -S chmod -F uid=3D3= 45

>

> we  would  require a permanent fix= .  If UID=3D345 is used, I believe

> that all auditing functionality will not wor= k for user ID=3D345,

 

Because the events shown are not translated, I ca= n't tell what account 345 is.

I am assuming by its low number that its a system= account. The rule above drops all auditing of chmod syscalls for the 345 u= ser account.

 

 

> I mean if the userId(345) is logging in manu= ally to the system and does some

> operation that will also be exclude.

 

Again, I can onlt speculate what that account is.= If its a daemon, then it

should have auid=3D-1 and the system works fine. = Because the auid is 500, that

tells me that user 500 started it. Because uid!= =3Dauid, I assume its either

setuid or user 500 changed to root and then issue= d, "service ohasd restart".

Its one or the other.

 

If user 500 changed to root and restarted the dae= mon, then a reboot will fix

everything and a permanent solution is not needed= . Or you can put the rule in

depending on how often this happens. But if this = is for more than one system,

then I'd use the 345 user's name so that auditctl= looks it up in case its

different on each machine. reserved accounts are = generally under 200.

 

 

> We want User inventions  logs messages = to be

> captured    but exclude the S= ystem generated logs.

 

The rules you gave have this in them:<= /p>

-F auid>=3D500 -F auid!=3D4294967295

 

This is to exclude daemons because they have auid= of -1 (unless restarted by

hand).

 

> To be more detail.

>

> Ohasd.bin process is started by the user( wh= ile starting the database

> process) we want to captured this log. =

 

The database is not started by the system on boot= ? Is this a system daemon or

a user session daemon?

 

> But after that the ohasd.bin process

> is running in background and it does lot of = read write operations, we don't

> want those logs.

>

> Can you please let us know the way forward.<= o:p>

 

I am not familiar with that program, so I still n= eed some answers to help you

figure out the right way to get rid of the events= .

 

-Steve

 

--_000_08DF6CD1326DBF4A80321CEA93761E5F1CB1C78Aeusaamb103erics_-- --===============5440743320468327507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5440743320468327507==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Excluding few executable from audit.rules in redhat6.5 Date: Wed, 19 Nov 2014 10:31:11 -0500 Message-ID: <6688953.p0Ds4QAG8f@x2> References: <08DF6CD1326DBF4A80321CEA93761E5F1CB1A523@eusaamb103.ericsson.se> <1748821.1UEmklyQaj@x2> <08DF6CD1326DBF4A80321CEA93761E5F1CB1C78A@eusaamb103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <08DF6CD1326DBF4A80321CEA93761E5F1CB1C78A@eusaamb103.ericsson.se> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tilden Doran D Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com Hello, On Wednesday, November 19, 2014 05:38:24 AM Tilden Doran D wrote: > The User 345 is oracle user. Which is used for oracle related activities in > the system. > > The command which we issue is srvctl stop/start database. We always install > oracle and start manually for the first time. > > As you mentioned, on reboot the system, it not generating too many logs. But > the problem is, we cannot reboot the system every time, which only > requires DB restart. Because application also be hosted in the same > system. OK. > The Srvctl command internally starts the ohasd.bin. > > So can we avoid it, I mean do we have an option to exclude the ohasd.bin by > using something like "-F exe!=ohasd.bin " or "-F path!= ...." . I tried > both, it is not working. These are not possible. I have lobbied for audit by executable for a couple of years. We are close to having it ready to go into the upstream kernel. But its not ready and can't be used. Normally one could exclude by SE Linux label, but since your original post showed unconfined_t, then that means there is no policy because the daemon did not transition out of unconfined_t. > Because "-F UID!=345" will restrict all the logs. The rule that I gave you would filter only the chmod syscall caused by anything with uid = 345. I think that is about the most reasonable choice you have short of doing some selinux policy work so we have something pid specific to match against. > Can we restrict the log which is generated by that particular > process/application. ? You could add a rule using the pid, but next restart you'll have to change the rule to the new pid. And probably by the time you can type that rule in, the daemon has already done all the chmod that its going to do. Maybe if the event are localized to a specific directory, you can do something like: auditctl -A exit,never -F arch=b32 -S chmod -F uid=345 -F dir=/opt/oracle_homes/oracle/ auditctl -A exit,never -F arch=b64 -S chmod -F uid=345 -F dir=/opt/oracle_homes/oracle/ -Steve