From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alan TaN" Subject: confusing with open system call in Linux kernel Date: Wed, 4 Feb 2015 15:59:36 +1300 Message-ID: <21a101d04026$9f45c8b0$ddd15a10$@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5180675252080833828==" Return-path: Received: from mx1.redhat.com (ext-mx15.extmail.prod.ext.phx2.redhat.com [10.5.110.20]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t142xk90006573 for ; Tue, 3 Feb 2015 21:59:46 -0500 Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t142xh71026859 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 3 Feb 2015 21:59:43 -0500 Received: by mail-pa0-f47.google.com with SMTP id lj1so104259397pab.6 for ; Tue, 03 Feb 2015 18:59:43 -0800 (PST) Received: from CasterlyRock (ryan-csl2.cms.waikato.ac.nz. [130.217.79.243]) by mx.google.com with ESMTPSA id n10sm300062pdp.18.2015.02.03.18.59.40 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Feb 2015 18:59:42 -0800 (PST) Content-Language: en-nz 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 multipart message in MIME format. --===============5180675252080833828== Content-Type: multipart/alternative; boundary="----=_NextPart_000_21A2_01D04093.963FACF0" Content-Language: en-nz This is a multipart message in MIME format. ------=_NextPart_000_21A2_01D04093.963FACF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, I am new here, so I am not exactly sure if this is the right place to ask this. I apologise in advance if this is not the right place. I would like to ask if anyone has encountered the issue below. I am trying to track a set of file accesses system calls in a Linux system (for experimental purposes) and used the following subset of rules with the audit.rules file. -a exit,always -F arch=b64 -S creat -S read -S write -S rename -S open -S close What I noticed was that for the open system call, when opening an existing file for writing purpose, the file name would result in a 'null' value like shown: type=SYSCALL msg=audit(1423018198.026:20826531): arch=c000003e syscall=2 success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9169 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3805 comm="readfile" exe="/root/prov_project/script/readfile" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1423018198.026:20826531): cwd="/root/prov_project/script" type=PATH msg=audit(1423018198.026:20826531): item=0 name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT type=PATH msg=audit(1423018198.026:20826531): item=1 name=(null) inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=NORMAL However, opening the same file with read only mode or opening a non-existing file (which in that case the open system call would create the file) would result in the file name being captured as shown: type=SYSCALL msg=audit(1423018196.556:20826486): arch=c000003e syscall=2 success=yes exit=4 a0=400865 a1=241 a2=1b6 a3=0 items=2 ppid=9093 pid=9168 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3805 comm="readfile" exe="/root/prov_project/script/readfile" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1423018196.556:20826486): cwd="/root/prov_project/script" type=PATH msg=audit(1423018196.556:20826486): item=0 name="/root/prov_project/script" inode=311564 dev=fd:01 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=PARENT type=PATH msg=audit(1423018196.556:20826486): item=1 name="sample_text.txt" inode=269089 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 nametype=CREATE Hence the question: Is this an intended feature or a bug? Appreciate if anyone can shed some light on this. To reproduce: write to a non-existing file first, close it and then open and write to the same file again. I am running version 2.3.7-5 of the audit framework and on CentOS 6.4 (kernel version 2.6.32-431) Thank you. Cheers, Alan ------=_NextPart_000_21A2_01D04093.963FACF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

I am new = here, so I am not exactly sure if this is the right place to ask this. I = apologise in advance if this is not the right place.

I would like to ask if anyone has encountered the = issue below.

 

I am trying to track a set of file accesses system = calls in a Linux system (for experimental purposes) and used the = following subset of rules with the audit.rules file.

 

-a = exit,always -F arch=3Db64 -S creat -S read -S write -S rename -S open -S = close

 

What I noticed was that for the open system call, when = opening an existing file for writing purpose, the file name would = result in a ‘null’ value like shown:

 

type=3DSYSCALL msg=3Daudit(1423018198.026:20826531): = arch=3Dc000003e syscall=3D2 success=3Dyes exit=3D4 a0=3D400865 = a1=3D241 a2=3D1b6 a3=3D0 items=3D2 ppid=3D9093 pid=3D9169 auid=3D0 = uid=3D0 gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 = tty=3Dpts1 ses=3D3805 comm=3D"readfile" = exe=3D"/root/prov_project/script/readfile" = subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 = key=3D(null)

type=3DCWD = msg=3Daudit(1423018198.026:20826531):  = cwd=3D"/root/prov_project/script"

type=3DPATH msg=3Daudit(1423018198.026:20826531): = item=3D0 name=3D"/root/prov_project/script" inode=3D311564 = dev=3Dfd:01 mode=3D040755 ouid=3D0 ogid=3D0 rdev=3D00:00 = obj=3Dunconfined_u:object_r:admin_home_t:s0 = nametype=3DPARENT

type=3DPATH = msg=3Daudit(1423018198.026:20826531): item=3D1 name=3D(null) = inode=3D269089 dev=3Dfd:01 mode=3D0100644 ouid=3D0 ogid=3D0 = rdev=3D00:00 obj=3Dunconfined_u:object_r:admin_home_t:s0 = nametype=3DNORMAL

 

 

However, = opening the same file with read only mode or opening a non-existing file = (which in that case the open system call would create the file) would = result in the file name being captured as shown:  

 

type=3DSYSCALL msg=3Daudit(1423018196.556:20826486): = arch=3Dc000003e syscall=3D2 success=3Dyes exit=3D4 a0=3D400865 a1=3D241 = a2=3D1b6 a3=3D0 items=3D2 ppid=3D9093 pid=3D9168 auid=3D0 uid=3D0 = gid=3D0 euid=3D0 suid=3D0 fsuid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 = tty=3Dpts1 ses=3D3805 comm=3D"readfile" = exe=3D"/root/prov_project/script/readfile" = subj=3Dunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 = key=3D(null)

type=3DCWD = msg=3Daudit(1423018196.556:20826486):  = cwd=3D"/root/prov_project/script"

type=3DPATH msg=3Daudit(1423018196.556:20826486): = item=3D0 name=3D"/root/prov_project/script" inode=3D311564 = dev=3Dfd:01 mode=3D040755 ouid=3D0 ogid=3D0 rdev=3D00:00 = obj=3Dunconfined_u:object_r:admin_home_t:s0 = nametype=3DPARENT

type=3DPATH = msg=3Daudit(1423018196.556:20826486): item=3D1 = name=3D"sample_text.txt" inode=3D269089 dev=3Dfd:01 = mode=3D0100644 ouid=3D0 ogid=3D0 rdev=3D00:00 = obj=3Dunconfined_u:object_r:admin_home_t:s0 = nametype=3DCREATE

 

Hence the = question: Is this an intended feature or a bug?

 

Appreciate = if anyone can shed some light on this.

 

To = reproduce:  write to a non-existing file first, close it and then = open and write to the same file again.

 

I am running = version 2.3.7-5 of the audit framework and on CentOS 6.4 (kernel version = 2.6.32-431)

 

Thank you.

 

Cheers,

Alan

 

------=_NextPart_000_21A2_01D04093.963FACF0-- --===============5180675252080833828== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5180675252080833828==--