From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smith Subject: file watch: separating file reads and writes Date: Wed, 9 Jul 2014 04:00:18 +0000 Message-ID: <94943543FF1E4246B0C4B827E39988190176403A@PDXMB01.tripwire.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1061377486894851267==" Return-path: Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6940xlj020163 for ; Wed, 9 Jul 2014 00:00:59 -0400 Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6940udw030754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Jul 2014 00:00:56 -0400 Received: from mail214-co9 (localhost [127.0.0.1]) by mail214-co9-R.bigfish.com (Postfix) with ESMTP id 81E1812047F for ; Wed, 9 Jul 2014 04:00:55 +0000 (UTC) Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.236]) by mail214-co9.bigfish.com (Postfix) with ESMTP id C180920047 for ; Wed, 9 Jul 2014 04:00:53 +0000 (UTC) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 1323D2321248 for ; Tue, 8 Jul 2014 21:00:53 -0700 (PDT) Received: from rint.tripwire.com (unknown [192.168.192.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 9182323211E0 for ; Tue, 8 Jul 2014 21:00:52 -0700 (PDT) Received: from PDXED01.tripwire.com ([192.168.192.5]) by rint.tripwire.com (RSA Interceptor) for ; Tue, 8 Jul 2014 23:47:36 -0400 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 --===============1061377486894851267== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_94943543FF1E4246B0C4B827E39988190176403APDXMB01tripwire_" --_000_94943543FF1E4246B0C4B827E39988190176403APDXMB01tripwire_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm running CentOS-6.5-i386-minimal. I recently used auditd to setup a watch on a specific file (-w /path/to/my/= file -p warx), but found it difficult to distinguish system calls that were= modifying the file vs. reading from the file when using ausearch/aureport. In response to that, I separated out the watches by keys: -w /patch/to/my/file -p wa thisisawrite -w /path/to/my/file -p r thisisaread And then ran both aureport -k and aureport -f to join the keys to the syste= m calls by event number. Am I wholly approaching this the wrong way, or is there an easier way to di= stinguish between a syscall that reads from a file vs. writes to a file? Assuming this is the correct approach, would there then be a benefit to add= ing the key to the aureport -f output? I find it awkward to have to combine= the two commands to get the necessary information. Regards, Jon Smith --_000_94943543FF1E4246B0C4B827E39988190176403APDXMB01tripwire_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m running CentOS-6.5-i386-minimal.

 

I recently used auditd to setup a watch on a specifi= c file (-w /path/to/my/file -p warx), but found it difficult to distinguish= system calls that were modifying the file vs. reading from the file when u= sing ausearch/aureport.

 

In response to that, I separated out the watches by = keys:

 

-w /patch/to/my/file -p wa thisisawrite

-w /path/to/my/file -p r thisisaread

 

And then ran both aureport -k and aureport -f to joi= n the keys to the system calls by event number.

 

Am I wholly approaching this the wrong way, or is th= ere an easier way to distinguish between a syscall that reads from a file v= s. writes to a file?

 

Assuming this is the correct approach, would there t= hen be a benefit to adding the key to the aureport -f output? I find it awk= ward to have to combine the two commands to get the necessary information.<= o:p>

 

Regards,

Jon Smith

--_000_94943543FF1E4246B0C4B827E39988190176403APDXMB01tripwire_-- --===============1061377486894851267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1061377486894851267==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: file watch: separating file reads and writes Date: Thu, 10 Jul 2014 16:24:54 -0400 Message-ID: <8316343.lH8SE5fr7Q@x2> References: <94943543FF1E4246B0C4B827E39988190176403A@PDXMB01.tripwire.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <94943543FF1E4246B0C4B827E39988190176403A@PDXMB01.tripwire.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 Wednesday, July 09, 2014 04:00:18 AM Jon Smith wrote: > I recently used auditd to setup a watch on a specific file (-w > /path/to/my/file -p warx), but found it difficult to distinguish system > calls that were modifying the file vs. reading from the file when using > ausearch/aureport. > > In response to that, I separated out the watches by keys: > > -w /patch/to/my/file -p wa thisisawrite > -w /path/to/my/file -p r thisisaread This sounds like the correct way to do it. > And then ran both aureport -k and aureport -f to join the keys to the system > calls by event number. Why not use ausearch -k? You can also give a partial key name since partial matching is the default. You could use: ausearch --start today -k thisisa > Am I wholly approaching this the wrong way, or is there an easier way to > distinguish between a syscall that reads from a file vs. writes to a file? Well, what you are getting is the requested permissions, rather than actual use of the permissions. I think it can be assumed that if an app opens a file for write, it will eventually get around to that. But not always. > Assuming this is the correct approach, would there then be a benefit to > adding the key to the aureport -f output? I find it awkward to have to > combine the two commands to get the necessary information. No one has asked for that so far. There is one quirk about keys, you can have multiple keys for the same event. So, that could be a bit of text if you have several. The idea of aureport was to have a utility that can extract, total, and sort properties of the event. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smith Subject: RE: file watch: separating file reads and writes Date: Tue, 22 Jul 2014 02:19:46 +0000 Message-ID: <94943543FF1E4246B0C4B827E399881901771C17@PDXMB01.tripwire.com> References: <94943543FF1E4246B0C4B827E39988190176403A@PDXMB01.tripwire.com> <8316343.lH8SE5fr7Q@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 s6M2Kmal000486 for ; Mon, 21 Jul 2014 22:20:48 -0400 Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6M2Klu5028653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 22:20:47 -0400 Received: from mail216-va3 (localhost [127.0.0.1]) by mail216-va3-R.bigfish.com (Postfix) with ESMTP id 54C7A2C031F for ; Tue, 22 Jul 2014 02:20:46 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.250]) by mail216-va3.bigfish.com (Postfix) with ESMTP id 6E7C0C80052 for ; Tue, 22 Jul 2014 02:20:44 +0000 (UTC) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id BB3252321203 for ; Mon, 21 Jul 2014 19:20:42 -0700 (PDT) In-Reply-To: <8316343.lH8SE5fr7Q@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 Steve, I just wanted to thank you for your reply. I totally overlooked the ability to pipe ausearch output to aureport, so the end result looked like this: ausearch -k thisisawrite | aureport -f And that solved my problem. Thank you very much for your time. Regards, Jon Smith -----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Thursday, July 10, 2014 1:25 PM To: linux-audit@redhat.com Cc: Jon Smith Subject: Re: file watch: separating file reads and writes On Wednesday, July 09, 2014 04:00:18 AM Jon Smith wrote: > I recently used auditd to setup a watch on a specific file (-w > /path/to/my/file -p warx), but found it difficult to distinguish > system calls that were modifying the file vs. reading from the file > when using ausearch/aureport. > > In response to that, I separated out the watches by keys: > > -w /patch/to/my/file -p wa thisisawrite -w /path/to/my/file -p r > thisisaread This sounds like the correct way to do it. > And then ran both aureport -k and aureport -f to join the keys to the > system calls by event number. Why not use ausearch -k? You can also give a partial key name since partial matching is the default. You could use: ausearch --start today -k thisisa > Am I wholly approaching this the wrong way, or is there an easier way to > distinguish between a syscall that reads from a file vs. writes to a file? Well, what you are getting is the requested permissions, rather than actual use of the permissions. I think it can be assumed that if an app opens a file for write, it will eventually get around to that. But not always. > Assuming this is the correct approach, would there then be a benefit to > adding the key to the aureport -f output? I find it awkward to have to > combine the two commands to get the necessary information. No one has asked for that so far. There is one quirk about keys, you can have multiple keys for the same event. So, that could be a bit of text if you have several. The idea of aureport was to have a utility that can extract, total, and sort properties of the event. -Steve