From mboxrd@z Thu Jan 1 00:00:00 1970 From: ramsdell@mitre.org (John D. Ramsdell) Subject: open record looks like openat Date: 27 Jul 2007 10:10:17 -0400 Message-ID: References: <200707251621.38095.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6REAJux023978 for ; Fri, 27 Jul 2007 10:10:19 -0400 Received: from smtp-mclean.mitre.org (smtp-mclean.mitre.org [192.80.55.71]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6REAHkB028035 for ; Fri, 27 Jul 2007 10:10:17 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l6REAH55027901 for ; Fri, 27 Jul 2007 10:10:17 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 758FC4F8D7 for ; Fri, 27 Jul 2007 10:10:17 -0400 (EDT) Received: from linus.mitre.org (rcf-smtp.mitre.org [129.83.10.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l6REAHdb027867 for ; Fri, 27 Jul 2007 10:10:17 -0400 Received: from oolong.mitre.org (oolong.mitre.org [129.83.162.84]) by linus.mitre.org (8.12.11/8.12.10) with ESMTP id l6REAHsr023035 for ; Fri, 27 Jul 2007 10:10:17 -0400 (EDT) In-Reply-To: <200707251621.38095.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: Linux Audit List-Id: linux-audit@redhat.com Steve Grubb writes: > I've just released a new version of the audit daemon. Thank you Steve. With this update, and bug fixes to my code, my analysis program completes without reporting internal inconsistencies. This usually means most of the bugs have been removed. I carefully studied the output of my analysis program, and found one particularly odd line of output. I traced it back to an interesting audit event in the raw log (syscall 5 is the open system call): type=SYSCALL msg=audit(1185450758.059:1699): arch=40000003 syscall=5 success=yes exit=0 a0=bfb9ec10 a1=241 a2=1b6 a3=4284b560 items=2 ppid=1 pid=22079 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="broadcast" exe="/home/ramsdell/scm/polgen/src/daemon-example/broadcast" subj=user_u:system_r:unconfined_t:s0 key=(null) type=CWD msg=audit(1185450758.059:1699): cwd="/" type=PATH msg=audit(1185450758.059:1699): item=0 name="/tmp/" inode=4128769 dev=fd:00 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 type=PATH msg=audit(1185450758.059:1699): item=1 name="/tmp/polgen_daemon.txt" inode=4128817 dev=fd:00 mode=0100640 ouid=500 ogid=500 rdev=00:00 obj=user_u:object_r:tmp_t:s0 Notice this event has two PATH records, whereas all of the many other open events I studied in my logs have one PATH record. It's as if the open system call can behave as the openat system call. I changed my analysis program to use the last PATH record to find the file name, so that the same code can be used to analyze open and openat system calls. John