From mboxrd@z Thu Jan 1 00:00:00 1970 From: ramsdell@mitre.org (John D. Ramsdell) Subject: Re: clone flags Date: 19 Jul 2007 14:45:02 -0400 Message-ID: References: <1184867993.3544.26.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <1184867993.3544.26.camel@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Eric Paris Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Eric Paris writes: > Actually it's a problem with mapping things. The flags are in a0. Eric, you seem to have nailed this issue. Let me explain why I thought the flags are in a2. I read print_a2 which starts on line 1019 of auparse/interpret.c. It contains a call to print_clone_flags on line 1034, and there are no other calls to this function in that file. That code clearly assumes clone flags only occur in a2. I played around with tracing the clone system call, and found something else since my last message. I traced a program that creates threads within a single address space with clone, and that call puts the clone flags into a2. The auparse library interprets these flags as one would expect. It is interesting to note that strace shows the clone flags for both usages of clone in the same position. Strace tries to make its output more human readable by making system calls records look more uniform then they actually are. The lack of uniformity in the output for interpreted audit system call will increase the difficulty of analyzing traces for people like me. In this case, I'll have to figure out when clone flags are in a0 and when they are in a2. The auparse library will have to do the same. My processing pipeline allows me to print out traces records as tab separated values so that I can probe data with quick awk scripts. Off the top of my head, it's not clear to me how to distinguish two case. I have enclosed the output with which I am working. I suppose I should simply read the strace sources, as its authors clearly have already figured out how to resolve this issue. John autrace of pthread_create: event time 1183463049.249:3627 type SYSCALL arch i386 syscall clone success yes exit 14871 a0 3d0f00 a1 b7efb4b4 a2 CLONE_VM|CLONE_FS|CLONE_SIGHAND|CLONE_PTRACE|CLONE_PARENT|CLONE_THREAD|CLONE_NEWNS|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_CHILD_CLEARTID|CLONE_DETACHED|CLONE_UNTRACED|CLONE_CHILD_SETTID|CLONE_STOPPED|CLONE_NEWUTS a3 bf9823ac items 0 ppid 14857 pid 14858 auid ramsdell uid ramsdell gid ramsdell euid ramsdell suid ramsdell fsuid ramsdell egid ramsdell sgid ramsdell fsgid ramsdell tty pts0 comm sockpair exe /home/ramsdell/scm/polgen/src/daemon-example/sockpair subj system_u:system_r:unconfined_t:s0 key (null) autrace of fork: event time 1183463044.249:414 type SYSCALL arch i386 syscall clone success yes exit 14860 a0 1200011 a1 0 a2 0 a3 0 items 0 ppid 14858 pid 14859 auid ramsdell uid ramsdell gid ramsdell euid ramsdell suid ramsdell fsuid ramsdell egid ramsdell sgid ramsdell fsgid ramsdell tty pts0 comm broadcast exe /home/ramsdell/scm/polgen/src/daemon-example/broadcast subj system_u:system_r:unconfined_t:s0 key (null) strace of ptrace_create: 31999 clone child_stack=0xb7f7f4b4 flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID parent_tidptr=0xb7f7fbd8 {entry_number:6, base_addr:0xb7f7fb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1} child_tidptr=0xb7f7fbd8 32013 user_u:system_r:unconfined_t strace of fork: 31999 clone child_stack=0 flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD child_tidptr=0xb7f9e708 32000 user_u:system_r:unconfined_t John