8:24 a.m.
I've been carefully comparing output I obtain with autrace with what I
get from strace. It appears they differ when the clone system call is
invoked from the C library via fork. In particular, strace reports
flags of CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, while
autrace says the flags are 0. The flags are in field a2.
John
[ramsdell@goo fork]$ uname -r
2.6.21-1.3228.fc7
[ramsdell@goo fork]$ make fork
cc fork.c -o fork
[ramsdell@goo fork]$ strace -o strace.txt ./fork
[ramsdell@goo fork]$ su -
Password:
[root@goo ~]# cd /home/ramsdell/proj/fork
[root@goo fork]# autrace ./fork
Waiting to execute: ./fork
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 1160'
[root@goo fork]# ausearch -i -p 1160 > autrace.txt
[root@goo fork]# grep clone strace.txt
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7efb708) = 1122
[root@goo fork]# grep clone autrace.txt
type=SYSCALL msg=audit(07/19/2007 09:16:02.350:848) : arch=i386 syscall=clone success=yes
exit=1161 a0=1200011 a1=0 a2=0 a3=0 items=0 ppid=1158 pid=1160 auid=ramsdell uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 comm=fork
exe=/home/ramsdell/proj/fork/fork subj=user_u:system_r:unconfined_t:s0 key=(null)
[root@goo fork]# cat fork.c
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(int argc, char **argv)
{
int status;
pid_t pid;
switch (fork()) {
case -1:
perror("clone");
return 1;
case 0:
return 0;
default:
do {
pid = wait(&status);
} while (pid < 0 && errno == EINTR);
if (WIFEXITED(status))
return WEXITSTATUS(status);
else
return 1;
}
}
[root@goo fork]#
12:59 p.m.
On Thu, 2007-07-19 at 09:24 -0400, John D. Ramsdell wrote:
[root@goo fork]# ausearch -i -p 1160 > autrace.txt
[root@goo fork]# grep clone strace.txt
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7efb708) = 1122
[root@goo fork]# grep clone autrace.txt
type=SYSCALL msg=audit(07/19/2007 09:16:02.350:848) : arch=i386 syscall=clone success=yes
exit=1161 a0=1200011 a1=0 a2=0 a3=0 items=0 ppid=1158 pid=1160 auid=ramsdell uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts2 comm=fork
exe=/home/ramsdell/proj/fork/fork subj=user_u:system_r:unconfined_t:s0 key=(null)
Actually it's a problem with mapping things. The flags are in a0. If
you look at the clone man page they talk about sys_clone at the bottom
(which is the actual call, whereas cone is just a library function on
top of the call) and they state the the ordering for sys_clone is
different. The kernel function is actually
asmlinkage long
sys_clone(unsigned long clone_flags, unsigned long newsp,
void __user *parent_tid, void __user *child_tid, struct
pt_regs *regs)
So the flags are actually coming in the first argument. To verify check
#define CLONE_CHILD_SETTID 0x01000000
#define CLONE_CHILD_CLEARTID 0x00200000
#define SIGCHLD 0x00000011
Which just so happens to be 0x01200011
and a0 just so happen to be 1200011
But it's just a difference between the library call 'clone' that the
application makes and the actual syscall glibc translates that to
sys_clone and the ordering of the flags.
-Eric
1:45 p.m.
Eric Paris <eparis(a)redhat.com> 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
2:37 p.m.
On Thu, 2007-07-19 at 14:45 -0400, John D. Ramsdell wrote:
Eric Paris <eparis(a)redhat.com> writes:
> Actually it's a problem with mapping things. The flags are in a0.
Eric, you seem to have nailed this issue.
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.
Actually, not quite. Its still the same mapping problem. auparse is
busted and the flags are always in a0 for the audit log. auparse is
actually giving you total and complete crap output. Notice in auparse
you got a long list of flags.
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
And the strace output below only showed a short list of flags. Also
note that one is NOT a sub/super set of the other. CLONE_DETACHED above
and CLONE_FILES below?
CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|
CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID
Anyway I took the strace flags and worked it out:
#define CLONE_VM 0x00000100
#define CLONE_FS 0x00000200
#define CLONE_FILES 0x00000400
#define CLONE_SIGHAND 0x00000800
#define CLONE_THREAD 0x00010000
#define CLONE_SYSVSEM 0x00040000
#define CLONE_SETTLS 0x00080000
#define CLONE_PARENT_SETTID 0x00100000
#define CLONE_CHILD_CLEARTID 0x00200000
0x003D0F00
Low and behold the audit a0 is 3d0f00
Looks like auparse was wrongly trying to convert the pointer for
parent_tidptr=0xb7f7fbd8 (notice we had CLONE_PARENT_SETTID set) into
clone flags and that list of flags was the best it could do.
So I'd say change all your stuff to look only at a0 for clone and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.
-Eric
2:42 p.m.
Eric Paris <eparis(a)redhat.com> writes:
So I'd say change all your stuff to look only at a0 for clone
and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.
This is very good news. I guess I was too trusting of the correctness
of Steve's code. Thank you.
John
6:07 a.m.
Eric Paris <eparis(a)redhat.com> writes:
So I'd say change all your stuff to look only at a0 for clone
and
someone (sgrubb already knows) needs to fix auparse to look for the
flags in a0 not in a2.
I notice the name of the getdents64 system call is printed as
getdents. I'll carefully study the output of strace and autrace on
all the system calls I monitor, and supply a patch that fixes
discrepancies. The code in auparse/interpret.c seems straightforward.
John
6:44 a.m.
New subject: Clone and fcntl64 flags patch
Enclosed is a patch for auparse/interpret.c that makes it so that
a0 is interpreted for clone flags, not a2. It also fixes two problems
with interpreting the fcntl system call. The name of the system call
is fcntl64, but the original code looked for the name fcntl. I have
also added a case so that a2 is printed as FD_CLOEXEC whenever a1 is
F_SETFD and a2 is 1.
I still haven't figured out why the auparse library prints getdents
when strace print getdents64. I'll keep on looking. You'd think that
either both getdents and fcntl would be printed with or without the
64 tacked on, but the current situation seem very odd to me.
John
8:40 a.m.
New subject: Clone and fcntl64 flags patch
ramsdell(a)mitre.org (John D. Ramsdell) writes:
I still haven't figured out why the auparse library prints
getdents
when strace print getdents64.
There is no bug in auparse when it comes to printing getdents. I
misread the strace output. It is printing getdents, not getdents64,
just as is auparse. My strace analysis programs looked for
getdents64, not getdents. I guess there was a time when the 64 bit
version of the system call was in use, but it doesn't seem to be used
now.
John
4:36 p.m.
New subject: Clone and fcntl64 flags patch
On Monday 23 July 2007 07:44:42 am John D. Ramsdell wrote:
Enclosed is a patch for auparse/interpret.c that makes it so that
a0 is interpreted for clone flags, not a2.
Thanks...will appy.
It also fixes two problems with interpreting the fcntl system call.
The
name of the system call is fcntl64, but the original code looked for the
name fcntl.
It was doing: strncmp(sys, "fcntl", 5) == 0), which is not a full string
compare. I think this is correct.
I have also added a case so that a2 is printed as FD_CLOEXEC
whenever a1 is
F_SETFD and a2 is 1.
Thanks...merging this piece.
-Steve
6359
days inactive
6365
days old
linux-audit@lists.linux-audit.osci.io
9 comments
3 participants
participants (3)
-
Eric Paris -
John D. Ramsdell -
Steve Grubb