From mboxrd@z Thu Jan 1 00:00:00 1970 From: 4javier <4javiereg4@gmail.com> Subject: Possible regression Date: Thu, 2 Jun 2011 14:48:30 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7088863083628577191==" Return-path: Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p52CmWpm020505 for ; Thu, 2 Jun 2011 08:48:32 -0400 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52CmVWe007553 for ; Thu, 2 Jun 2011 08:48:31 -0400 Received: by vxi39 with SMTP id 39so895745vxi.33 for ; Thu, 02 Jun 2011 05:48:31 -0700 (PDT) In-Reply-To: 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 --===============7088863083628577191== Content-Type: multipart/alternative; boundary=90e6ba539fc0e2efac04a4ba0ddf --90e6ba539fc0e2efac04a4ba0ddf Content-Type: text/plain; charset=ISO-8859-1 I'm noticing exactly the same problem mentioned into this old message http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html Workaround consisting into watching the whole directory containing the file works too. I've found that into 2006 a patch was submitted to solve the issue http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html Is this a recent regression, or is there something I don't know? Arch Linux audit 2.1.1 kernel 2.6.38.7 i686 architecture Thanks in advance --90e6ba539fc0e2efac04a4ba0ddf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'm noticing exactly the same proble= m mentioned into this old message
http://osdir= .com/ml/linux.redhat.security.audit/2006-07/msg00036.html
Workaround consisting into watching the whole directory containing the file= works too. I've found that into 2006 a patch was submitted to solve th= e issue
http://www.mail-archive.com/linux-audit@red= hat.com/msg00476.html

Is this a recent regression, or is there something I don't know?
Arch Linux
audit 2.1.1
kernel 2.6.38.7
i686 architecture
<= br>Thanks in advance

--90e6ba539fc0e2efac04a4ba0ddf-- --===============7088863083628577191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7088863083628577191==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Possible regression Date: Thu, 2 Jun 2011 09:21:17 -0400 Message-ID: <201106020921.17388.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 Thursday, June 02, 2011 08:48:30 AM 4javier wrote: > I'm noticing exactly the same problem mentioned into this old message > http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html > Workaround consisting into watching the whole directory containing the file > works too. I've found that into 2006 a patch was submitted to solve the > issue > http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html > > Is this a recent regression, or is there something I don't know? I just ran the test from that email and got the following: [root@localhost ~]# touch /tmp/test [root@localhost ~]# auditctl -a always,exit -F path=/tmp/test -F perm=rwa -k watch [root@localhost ~]# echo "" > /tmp/test [root@localhost ~]# cat /tmp/test [root@localhost ~]# ausearch --start recent --key watch -i ---- type=CONFIG_CHANGE msg=audit(06/02/2011 09:15:49.790:124) : auid=sgrubb ses=2 subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add rule" key=watch list=exit res=1 ---- type=PATH msg=audit(06/02/2011 09:15:56.970:125) : item=0 name=/tmp/test inode=164740 dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 type=CWD msg=audit(06/02/2011 09:15:56.970:125) : cwd=/root type=SYSCALL msg=audit(06/02/2011 09:15:56.970:125) : arch=x86_64 syscall=open success=yes exit=3 a0=28cadd0 a1=241 a2=1b6 a3=0 items=1 ppid=1634 pid=1640 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=bash exe=/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch ---- type=PATH msg=audit(06/02/2011 09:16:08.850:126) : item=0 name=/tmp/test inode=164740 dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 type=CWD msg=audit(06/02/2011 09:16:08.850:126) : cwd=/root type=SYSCALL msg=audit(06/02/2011 09:16:08.850:126) : arch=x86_64 syscall=open success=yes exit=3 a0=7fffd7a8f943 a1=0 a2=0 a3=32d80819d0 items=1 ppid=1640 pid=1659 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=2 comm=cat exe=/bin/cat subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch [root@localhost ~]# uname -r 2.6.38.6-26.rc1.fc15.x86_64 We have 2 events. Are you getting this? Is something missing? -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: 4javier <4javiereg4@gmail.com> Subject: Fwd: Possible regression Date: Thu, 2 Jun 2011 15:46:23 +0200 Message-ID: References: <201106020921.17388.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2081707252749810444==" Return-path: Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p52DkPnW003685 for ; Thu, 2 Jun 2011 09:46:25 -0400 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52DkOPT024521 for ; Thu, 2 Jun 2011 09:46:24 -0400 Received: by vxi39 with SMTP id 39so958935vxi.33 for ; Thu, 02 Jun 2011 06:46:23 -0700 (PDT) In-Reply-To: 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 --===============2081707252749810444== Content-Type: multipart/alternative; boundary=20cf3054aad1e3c1e104a4badc55 --20cf3054aad1e3c1e104a4badc55 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: 4javier <4javiereg4@gmail.com> Date: 2011/6/2 Subject: Re: Possible regression To: Steve Grubb you're right...sorry for my fault... I didn't use the -a switch. I read the man, but I cannot understand how this settings is able to fix the problem with O_CREAT. Could you explain that to me, please? 2011/6/2 Steve Grubb > On Thursday, June 02, 2011 08:48:30 AM 4javier wrote: > > I'm noticing exactly the same problem mentioned into this old message > > http://osdir.com/ml/linux.redhat.security.audit/2006-07/msg00036.html > > Workaround consisting into watching the whole directory containing the > file > > works too. I've found that into 2006 a patch was submitted to solve the > > issue > > http://www.mail-archive.com/linux-audit@redhat.com/msg00476.html > > > > Is this a recent regression, or is there something I don't know? > > I just ran the test from that email and got the following: > > [root@localhost ~]# touch /tmp/test > [root@localhost ~]# auditctl -a always,exit -F path=/tmp/test -F perm=rwa > -k watch > [root@localhost ~]# echo "" > /tmp/test > [root@localhost ~]# cat /tmp/test > > [root@localhost ~]# ausearch --start recent --key watch -i > ---- > type=CONFIG_CHANGE msg=audit(06/02/2011 09:15:49.790:124) : auid=sgrubb > ses=2 > subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op="add rule" > key=watch > list=exit res=1 > ---- > type=PATH msg=audit(06/02/2011 09:15:56.970:125) : item=0 name=/tmp/test > inode=164740 > dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:object_r:user_tmp_t:s0 > type=CWD msg=audit(06/02/2011 09:15:56.970:125) : cwd=/root > type=SYSCALL msg=audit(06/02/2011 09:15:56.970:125) : arch=x86_64 > syscall=open > success=yes exit=3 a0=28cadd0 a1=241 a2=1b6 a3=0 items=1 ppid=1634 pid=1640 > auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root > fsgid=root tty=pts1 ses=2 comm=bash exe=/bin/bash > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch > ---- > type=PATH msg=audit(06/02/2011 09:16:08.850:126) : item=0 name=/tmp/test > inode=164740 > dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:object_r:user_tmp_t:s0 > type=CWD msg=audit(06/02/2011 09:16:08.850:126) : cwd=/root > type=SYSCALL msg=audit(06/02/2011 09:16:08.850:126) : arch=x86_64 > syscall=open > success=yes exit=3 a0=7fffd7a8f943 a1=0 a2=0 a3=32d80819d0 items=1 > ppid=1640 pid=1659 > auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root > fsgid=root tty=pts1 ses=2 comm=cat exe=/bin/cat > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch > [root@localhost ~]# uname -r > 2.6.38.6-26.rc1.fc15.x86_64 > > We have 2 events. Are you getting this? Is something missing? > > -Steve > --20cf3054aad1e3c1e104a4badc55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: 4javier <4javiereg4@gmail.com>Date: 2011/6/2
Subject: Re: Possible regression
To: Steve Grubb <sgrubb@redhat.com>


you're right...s= orry for my fault...
I didn't use the -a switch. I read the man, but= I cannot understand how this settings is able to fix the problem with O_CR= EAT.
Could you explain that to me, please?

=
2011/6/2 Steve Grubb <sgrubb@redhat.com>=
On Thursday, June 02, 2011 08:48:30 AM 4javier wrote:
> I'm noticing exactly the same problem mentioned into this old mess= age
> http://osdir.com/ml/linux.redhat.security.aud= it/2006-07/msg00036.html
> Workaround consisting into watching the whole directory containing the= file
> works too. I've found that into 2006 a patch was submitted to solv= e the
> issue
> http://www.mail-archive.com/linux-audit@redhat.com= /msg00476.html
>
> Is this a recent regression, or is there something I don't know?
I just ran the test from that email and got the following:

[root@localhost ~]# touch /tmp/test
[root@localhost ~]# auditctl -a always,exit -F path=3D/tmp/test -F perm=3Dr= wa -k watch
[root@localhost ~]# =A0echo "" > /tmp/test
[root@localhost ~]# cat /tmp/test

[root@localhost ~]# ausearch --start recent --key watch -i
----
type=3DCONFIG_CHANGE msg=3Daudit(06/02/2011 09:15:49.790:124) : auid=3Dsgru= bb ses=3D2
subj=3Dunconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 op=3D"add r= ule" key=3Dwatch
list=3Dexit res=3D1
----
type=3DPATH msg=3Daudit(06/02/2011 09:15:56.970:125) : item=3D0 name=3D/tmp= /test inode=3D164740
dev=3Dfd:01 mode=3Dfile,644 ouid=3Droot ogid=3Droot rdev=3D00:00
obj=3Dunconfined_u:object_r:user_tmp_t:s0
type=3DCWD msg=3Daudit(06/02/2011 09:15:56.970:125) : =A0cwd=3D/root
type=3DSYSCALL msg=3Daudit(06/02/2011 09:15:56.970:125) : arch=3Dx86_64 sys= call=3Dopen
success=3Dyes exit=3D3 a0=3D28cadd0 a1=3D241 a2=3D1b6 a3=3D0 items=3D1 ppid= =3D1634 pid=3D1640
auid=3Dsgrubb uid=3Droot gid=3Droot euid=3Droot suid=3Droot fsuid=3Droot eg= id=3Droot sgid=3Droot
fsgid=3Droot tty=3Dpts1 ses=3D2 comm=3Dbash exe=3D/bin/bash
subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3Dwatch ----
type=3DPATH msg=3Daudit(06/02/2011 09:16:08.850:126) : item=3D0 name=3D/tmp= /test inode=3D164740
dev=3Dfd:01 mode=3Dfile,644 ouid=3Droot ogid=3Droot rdev=3D00:00
obj=3Dunconfined_u:object_r:user_tmp_t:s0
type=3DCWD msg=3Daudit(06/02/2011 09:16:08.850:126) : =A0cwd=3D/root
type=3DSYSCALL msg=3Daudit(06/02/2011 09:16:08.850:126) : arch=3Dx86_64 sys= call=3Dopen
success=3Dyes exit=3D3 a0=3D7fffd7a8f943 a1=3D0 a2=3D0 a3=3D32d80819d0 item= s=3D1 ppid=3D1640 pid=3D1659
auid=3Dsgrubb uid=3Droot gid=3Droot euid=3Droot suid=3Droot fsuid=3Droot eg= id=3Droot sgid=3Droot
fsgid=3Droot tty=3Dpts1 ses=3D2 comm=3Dcat exe=3D/bin/cat
subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=3Dwatch [root@localhost ~]# uname -r
2.6.38.6-26.rc1.fc15.x86_64

We have 2 events. Are you getting this? Is something missing?

-Steve


--20cf3054aad1e3c1e104a4badc55-- --===============2081707252749810444== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2081707252749810444==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Possible regression Date: Thu, 2 Jun 2011 09:59:02 -0400 Message-ID: <201106020959.02434.sgrubb@redhat.com> References: <201106020921.17388.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: 4javier <4javiereg4@gmail.com>, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday, June 02, 2011 09:45:38 AM you wrote: > you're right...sorry for my fault... > I didn't use the -a switch. I read the man, but I cannot understand how > this settings is able to fix the problem with O_CREAT. > Could you explain that to me, please? As far as I know, the problem was fixed in 2006 and there has been no regression. The - w command is translated into -a always,exit -F path= under the hood. Its been this way since watches were deprecated around 2005/2006. How were you testing? You might have found a bug and I just don't know how to reproduce it. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: 4javier <4javiereg4@gmail.com> Subject: Fwd: Possible regression Date: Thu, 2 Jun 2011 20:14:40 +0200 Message-ID: References: <201106020921.17388.sgrubb@redhat.com> <201106020959.02434.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7373773980286273082==" Return-path: Received: from mx1.redhat.com (ext-mx12.extmail.prod.ext.phx2.redhat.com [10.5.110.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p52IEgpw022053 for ; Thu, 2 Jun 2011 14:14:42 -0400 Received: from mail-vx0-f174.google.com (mail-vx0-f174.google.com [209.85.220.174]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p52IEfJo003727 for ; Thu, 2 Jun 2011 14:14:41 -0400 Received: by vxi39 with SMTP id 39so1295433vxi.33 for ; Thu, 02 Jun 2011 11:14:41 -0700 (PDT) In-Reply-To: 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 --===============7373773980286273082== Content-Type: multipart/alternative; boundary=485b395e70455bdd4a04a4be9ca8 --485b395e70455bdd4a04a4be9ca8 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: 4javier <4javiereg4@gmail.com> Date: 2011/6/2 Subject: Re: Possible regression To: Steve Grubb root@Archbox /home/javier $ touch /tmp/test root@Archbox /home/javier $ cat /tmp/test root@Archbox /home/javier $ auditctl -w /tmp/test -p wa root@Archbox /home/javier $ echo ppp >> /tmp/test root@Archbox /home/javier $ cat /tmp/test ppp root@Archbox /home/javier $ ausearch -i -f /tmp/test root@Archbox /home/javier $ auditctl -l LIST_RULES: exit,always watch=/tmp/test perm=wa root@Archbox /home/javier $ echo ppp > /tmp/test root@Archbox /home/javier $ ausearch -i -f /tmp/test root@Archbox /home/javier $ ausearch -f /tmp/test As you can see from auditcrl -l output, rule seems to be correctly set, but ausearch doesn't show anything. 2011/6/2 Steve Grubb > On Thursday, June 02, 2011 09:45:38 AM you wrote: > > you're right...sorry for my fault... > > I didn't use the -a switch. I read the man, but I cannot understand how > > this settings is able to fix the problem with O_CREAT. > > Could you explain that to me, please? > > As far as I know, the problem was fixed in 2006 and there has been no > regression. The - > w command is translated into -a always,exit -F path= under the hood. Its > been this way > since watches were deprecated around 2005/2006. > > How were you testing? You might have found a bug and I just don't know how > to > reproduce it. > > -Steve > --485b395e70455bdd4a04a4be9ca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: 4javier <4javiereg4@gmail.com>Date: 2011/6/2
Subject: Re: Possible regression
To: Steve Grubb <sgrubb@redhat.com>


root@Archbox /home/j= avier $ touch /tmp/test
root@Archbox /home/javier $ cat /tmp/test
roo= t@Archbox /home/javier $ auditctl -w /tmp/test -p wa
root@Archbox /home/javier $ echo ppp >> /tmp/test
root@Archbox /ho= me/javier $ cat /tmp/test
ppp
root@Archbox /home/javier $ ausearch -i -f /tmp/test
<no match= es>
root@Archbox /home/javier $ auditctl -l
LIST_RULES: exit,alway= s watch=3D/tmp/test perm=3Dwa
root@Archbox /home/javier $ echo ppp > = /tmp/test
root@Archbox /home/javier $ ausearch -i -f /tmp/test
<no matches><= br>root@Archbox /home/javier $ ausearch -f /tmp/test
<no matches><= br>
As you can see from auditcrl -l output, rule seems to be correctly s= et, but ausearch doesn't show anything.
2011/6/2 Steve Grubb <sgrubb@= redhat.com>
On Thursday, June 02, 2011 09:45:38 AM you wrote:
> you're right...sorry for my fault...
> I didn't use the -a switch. I read the man, but I cannot understan= d how
> this settings is able to fix the problem with O_CREAT.
> Could you explain that to me, please?

As far as I know, the problem was fixed in 2006 and there has been no= regression. The -
w command is translated into -a always,exit -F path=3D under the hood. Its = been this way
since watches were deprecated around 2005/2006.

How were you testing? You might have found a bug and I just don't know = how to
reproduce it.

-Steve


--485b395e70455bdd4a04a4be9ca8-- --===============7373773980286273082== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7373773980286273082==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Possible regression Date: Thu, 2 Jun 2011 14:40:05 -0400 Message-ID: <201106021440.06076.sgrubb@redhat.com> References: <201106020959.02434.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: 4javier <4javiereg4@gmail.com>, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thursday, June 02, 2011 12:41:41 PM 4javier wrote: > root@Archbox /home/javier $ touch /tmp/test > root@Archbox /home/javier $ cat /tmp/test > root@Archbox /home/javier $ auditctl -w /tmp/test -p wa > root@Archbox /home/javier $ echo ppp >> /tmp/test > root@Archbox /home/javier $ cat /tmp/test > ppp > root@Archbox /home/javier $ ausearch -i -f /tmp/test > > root@Archbox /home/javier $ auditctl -l > LIST_RULES: exit,always watch=/tmp/test perm=wa > root@Archbox /home/javier $ echo ppp > /tmp/test > root@Archbox /home/javier $ ausearch -i -f /tmp/test > > root@Archbox /home/javier $ ausearch -f /tmp/test > > > As you can see from auditcrl -l output, rule seems to be correctly set, but > ausearch doesn't show anything. I duplicated your tests here: [root@localhost ~]# auditctl -w /tmp/test -p wa -k watch [root@localhost ~]# echo "ppp" >> /tmp/test [root@localhost ~]# cat /tmp/test ppp [root@localhost ~]# ausearch --start recent -i -f /tmp/test ---- type=PATH msg=audit(06/02/2011 14:32:45.146:112) : item=0 name=/tmp/test inode=164740 dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 type=CWD msg=audit(06/02/2011 14:32:45.146:112) : cwd=/root type=SYSCALL msg=audit(06/02/2011 14:32:45.146:112) : arch=x86_64 syscall=open success=yes exit=3 a0=1842830 a1=441 a2=1b6 a3=0 items=1 ppid=1298 pid=1304 auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=bash exe=/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch Admittedly I am on the 2.6.38.6 kernel. But I'm not seeing a regression. When you set the perms to "wa" that is only going to be opens for writing or changes to file attributes. So, the cat command will not trigger an event and that is why I only get 1 event. I am also on a 64 bit system, but I would think that didn't matter...unless we have a signed/unsigned comparison problem...what do you have for an inode on the /tmp/watch file? ls -i /tmp/watch should get it. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: 4javier <4javiereg4@gmail.com> Subject: Re: Possible regression Date: Thu, 2 Jun 2011 22:11:03 +0200 Message-ID: References: <201106020959.02434.sgrubb@redhat.com> <201106021440.06076.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3303110970093103741==" Return-path: In-Reply-To: <201106021440.06076.sgrubb@redhat.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: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============3303110970093103741== Content-Type: multipart/alternative; boundary=bcaec54a37ae8c4f3404a4c03ca2 --bcaec54a37ae8c4f3404a4c03ca2 Content-Type: text/plain; charset=ISO-8859-1 both ls -i both stat return 252 as inode for /tmp/test (I considered your /tmp/watch a typo) I also tried to add read permission to the watch and execute a cat on the file, but not even that get recognized by audit. 2011/6/2 Steve Grubb > On Thursday, June 02, 2011 12:41:41 PM 4javier wrote: > > root@Archbox /home/javier $ touch /tmp/test > > root@Archbox /home/javier $ cat /tmp/test > > root@Archbox /home/javier $ auditctl -w /tmp/test -p wa > > root@Archbox /home/javier $ echo ppp >> /tmp/test > > root@Archbox /home/javier $ cat /tmp/test > > ppp > > root@Archbox /home/javier $ ausearch -i -f /tmp/test > > > > root@Archbox /home/javier $ auditctl -l > > LIST_RULES: exit,always watch=/tmp/test perm=wa > > root@Archbox /home/javier $ echo ppp > /tmp/test > > root@Archbox /home/javier $ ausearch -i -f /tmp/test > > > > root@Archbox /home/javier $ ausearch -f /tmp/test > > > > > > As you can see from auditcrl -l output, rule seems to be correctly set, > but > > ausearch doesn't show anything. > > I duplicated your tests here: > [root@localhost ~]# auditctl -w /tmp/test -p wa -k watch > [root@localhost ~]# echo "ppp" >> /tmp/test > [root@localhost ~]# cat /tmp/test > > ppp > [root@localhost ~]# ausearch --start recent -i -f /tmp/test > ---- > type=PATH msg=audit(06/02/2011 14:32:45.146:112) : item=0 name=/tmp/test > inode=164740 > dev=fd:01 mode=file,644 ouid=root ogid=root rdev=00:00 > obj=unconfined_u:object_r:user_tmp_t:s0 > type=CWD msg=audit(06/02/2011 14:32:45.146:112) : cwd=/root > type=SYSCALL msg=audit(06/02/2011 14:32:45.146:112) : arch=x86_64 > syscall=open > success=yes exit=3 a0=1842830 a1=441 a2=1b6 a3=0 items=1 ppid=1298 pid=1304 > auid=sgrubb uid=root gid=root euid=root suid=root fsuid=root egid=root > sgid=root > fsgid=root tty=pts0 ses=1 comm=bash exe=/bin/bash > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=watch > > Admittedly I am on the 2.6.38.6 kernel. But I'm not seeing a regression. > When you set > the perms to "wa" that is only going to be opens for writing or changes to > file > attributes. So, the cat command will not trigger an event and that is why I > only get 1 > event. I am also on a 64 bit system, but I would think that didn't > matter...unless we > have a signed/unsigned comparison problem...what do you have for an inode > on the > /tmp/watch file? ls -i /tmp/watch should get it. > > -Steve > --bcaec54a37ae8c4f3404a4c03ca2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable both ls -i both stat return 252 as inode for /tmp/test (I considered your /= tmp/watch a typo)
I also tried to add read permission to the watch and = execute a cat on the file, but not even that get recognized by audit.

2011/6/2 Steve Grubb <<= a href=3D"mailto:sgrubb@redhat.com">sgrubb@redhat.com>
On Thursday, June 02, 2011 12:41:41 PM 4javier wrote:
> root@Archbox /home/javier $ touch /tmp/test
> root@Archbox /home/javier $ cat /tmp/test
> root@Archbox /home/javier $ auditctl -w /tmp/test -p wa
> root@Archbox /home/javier $ echo ppp >> /tmp/test
> root@Archbox /home/javier $ cat /tmp/test
> ppp
> root@Archbox /home/javier $ ausearch -i -f /tmp/test
> <no matches>
> root@Archbox /home/javier $ auditctl -l
> LIST_RULES: exit,always watch=3D/tmp/test perm=3Dwa
> root@Archbox /home/javier $ echo ppp > /tmp/test
> root@Archbox /home/javier $ ausearch -i -f /tmp/test
> <no matches>
> root@Archbox /home/javier $ ausearch -f /tmp/test
> <no matches>
>
> As you can see from auditcrl -l output, rule seems to be correctly set= , but
> ausearch doesn't show anything.

I duplicated your tests here:
[root@localhost ~]# auditctl -w /tmp/test -p wa -k watch
[root@localhost ~]# echo "ppp" >> /tmp/test
[root@localhost ~]# cat /tmp/test

ppp
[root@localhost ~]# ausearch --start recent -i -f /tmp/test
----
type=3DPATH msg=3Daudit(06/02/2011 14:32:45.146:112) : item=3D0 name=3D/tmp= /test inode=3D164740
dev=3Dfd:01 mode=3Dfile,644 ouid=3Droot ogid=3Droot rdev= =3D00:00
obj=3Dunconfined_u:object_r:user_tmp_t:s0
type=3DCWD msg=3Daudit(06/02/2011 14:32:45.146:112) : =A0cwd=3D/root<= br> type=3DSYSCALL msg=3Daudit(06/02/2011 14:32:45.146:112) : arch=3Dx86_64 sys= call=3Dopen
success=3Dyes exit=3D3 a0=3D1842830 a1=3D441 a2=3D1b6 a3=3D0 items=3D1 ppid= =3D1298 pid=3D1304
auid=3Dsgrubb uid=3Droot gid=3Droot euid=3Droot suid=3Dro= ot fsuid=3Droot egid=3Droot sgid=3Droot
fsgid=3Droot tty=3Dpts0 ses=3D1 comm=3Dbash exe=3D/bin/bash
subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1= 023 key=3Dwatch

Admittedly I am on the 2.6.38.6 kernel. But I'm not seeing a regr= ession. When you set
the perms to "wa" that is only going to be opens for writing or c= hanges to file
attributes. So, the cat command will not trigger an event and that is why I= only get 1
event. I am also on a 64 bit system, but I would think that didn't matt= er...unless we
have a signed/unsigned comparison problem...what do you have for an inode o= n the
/tmp/watch file? ls -i /tmp/watch should get it.

-Steve

--bcaec54a37ae8c4f3404a4c03ca2-- --===============3303110970093103741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3303110970093103741==--