2:25 a.m.
Hi,
I'm a newbie, I'm sorry for my question if anyone has already asked.
I use auditctl -a exit,always -S open -F success=0 to audit all
successful open syscalls
But in the audit.log file I found the following audit records:
type=SYSCALL msg=audit(1201421673.445:1508): arch=40000003
syscall=5 success=no exit=-2 a0=bfec1e40 a1=0 a2=b7ee6548 a3=bfec1e40
items=1 ppid=9571 pid=96 95 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="vim" exe="/usr/bin/vim"
key=(null)
The "success" fields of the record is no, what does it mean? Does
it represent the syscall is failed?
And what does "exit" field mean? Does it represent the syscall's exit
code?
I'm also confused with the meaning of the fields of "a0" "a1"
"a2" and "a3".
7:15 a.m.
On Sunday 27 January 2008 03:25:47 Marius.bao wrote:
type=SYSCALL msg=audit(1201421673.445:1508): arch=40000003
syscall=5 success=no exit=-2 a0=bfec1e40 a1=0 a2=b7ee6548 a3=bfec1e40
items=1 ppid=9571 pid=96 95 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="vim" exe="/usr/bin/vim"
key=(null)
The "success" fields of the record is no, what does it mean? Does it
represent the syscall is failed?
Yes
And what does "exit" field mean? Does it represent the
syscall's exit
code?
Yes.
I'm also confused with the meaning of the fields of
"a0" "a1" "a2"
and "a3".
Arg 0, Arg 1, Arg 2, and Arg 3. All are integers. IOW, pointers are not
dereferenced, you would just have the address.
I have something that tells you about the meaning of various fields here:
http://people.redhat.com/sgrubb/audit/audit-parse.txt
Look in the field names section.
-Steve
1:16 a.m.
Thanks a lot :-)
I still have several questions:
1. My audit rule is auditctl -a exit,always -S open -F success=0,
why in the audit record, the success field is no. And if I use the
opposite rule auditctl -a exit,always -S open -F success!=0, the
records' "success" field is yes?
2. In some audit records, the "success" is yes, but with a non-zero
exit code. When does this situation occur(A syscall successes with a
non-zero exit code)?
3.Have anyone ever tested the system performance impact when the
kernel audit functionality is turned on?
I've tested with the following audit rules
auditctl -a exit,always -S read -F success=0
auditctl -a exit,always -S readv -F success=0
auditctl -a exit,always -S write -F success=0
auditctl -a exit,always -S writev -F success=0
auditctl -a exit,always -S fork -F success=0
auditctl -a exit,always -S clone -F success=0
auditctl -a exit,always -S truncate -F success=0
auditctl -a exit,always -S ftruncate -F success=0
auditctl -a exit,always -S link -F success=0
auditctl -a exit,always -S unlink -F success=0
auditctl -a exit,always -S symlink -F success=0
auditctl -a exit,always -S chown -F success=0
auditctl -a exit,always -S chmod -F success=0
auditctl -a exit,always -S fchown -F success=0
auditctl -a exit,always -S fchmod -F success=0
auditctl -a exit,always -S kill -F success=0
auditctl -a exit,always -S mmap -F success=0
auditctl -a exit,always -S signal -F success=0
I've tested the source code compile benchmark with the
kscope1.6.0(a source reading toll). My platform is Fedora 8, 2.6.23
kernel version, and Intel Pentium(R) processor1.7GHZ, 512M main
memory.
Without any audit, the kscope compile time is as follows
0m32s total time
0m14s user space time
0m3s sys space time
With the above audit rule set, the kscope source compile time is as follows
1m4s total time
0m14s user space time
0m15s sys space time
It turned out that with some of the audit rule set, the kscope
source compile process takes double time. I wonder why it has so heavy
impact on the system's performance.
I also read some papers(<<Automatic high-performance
reconstruction and recovery>>) on other audit systems. The system's
impact is relatively low,about 6%~8% with all syscall information
audited.
On Sunday 27 January 2008 03:25:47 Marius.bao wrote:
> type=SYSCALL msg=audit(1201421673.445:1508): arch=40000003
> syscall=5 success=no exit=-2 a0=bfec1e40 a1=0 a2=b7ee6548 a3=bfec1e40
> items=1 ppid=9571 pid=96 95 auid=0 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="vim"
exe="/usr/bin/vim"
> key=(null)
> The "success" fields of the record is no, what does it mean? Does it
> represent the syscall is failed?
Yes
> And what does "exit" field mean? Does it represent the syscall's
exit
> code?
Yes.
> I'm also confused with the meaning of the fields of "a0"
"a1" "a2"
> and "a3".
Arg 0, Arg 1, Arg 2, and Arg 3. All are integers. IOW, pointers are not
dereferenced, you would just have the address.
I have something that tells you about the meaning of various fields here:
http://people.redhat.com/sgrubb/audit/audit-parse.txt
Look in the field names section.
-Steve
12:02 p.m.
On Tuesday 29 January 2008 02:16:44 Marius.bao wrote:
1. My audit rule is auditctl -a exit,always -S open -F success=0,
why in the audit record, the success field is no. And if I use the
opposite rule auditctl -a exit,always -S open -F success!=0, the
records' "success" field is yes?
in the auditctl man page is this: When writing a rule, use a 1 for true/yes
and a 0 for false/no. It looks like its working the way its documented to
work.
2. In some audit records, the "success" is yes, but with
a non-zero
exit code. When does this situation occur(A syscall successes with a
non-zero exit code)?
Many times. You would have to look on a per syscall basis. Each one is
different. For example, open could return a 1 for the descriptor number or
a -1 to indicate an error. In both cases, it is non-zero. If open returned a
0, that is also success since that would be stdin. In general, if the exit
code is < 0, there is an error and >= 0 is success.
3.Have anyone ever tested the system performance impact when the
kernel audit functionality is turned on?
Yes we've done much testing over the years.
I've tested with the following audit rules
auditctl -a exit,always -S read -F success=0
auditctl -a exit,always -S readv -F success=0
auditctl -a exit,always -S write -F success=0
auditctl -a exit,always -S writev -F success=0
auditctl -a exit,always -S fork -F success=0
auditctl -a exit,always -S clone -F success=0
auditctl -a exit,always -S truncate -F success=0
auditctl -a exit,always -S ftruncate -F success=0
auditctl -a exit,always -S link -F success=0
auditctl -a exit,always -S unlink -F success=0
auditctl -a exit,always -S symlink -F success=0
auditctl -a exit,always -S chown -F success=0
auditctl -a exit,always -S chmod -F success=0
auditctl -a exit,always -S fchown -F success=0
auditctl -a exit,always -S fchmod -F success=0
auditctl -a exit,always -S kill -F success=0
auditctl -a exit,always -S mmap -F success=0
auditctl -a exit,always -S signal -F success=0
This is going to suck performance-wise. If you wanted to audit the above, I'd
re-write the rules as:
auditctl -a exit,always -S read -S readv -S write -S writev -S fork -S
clone -S truncate -S ftruncate -S link -S unlink -S symlink -S chown -S
chmod -S fchown -S fchmod -S kill -S mmap -S signal -F success=0
This means that the kernel will evaluate just one rule that does the same
thing. I can do it this way because all syscalls are on the same filter and
with the same action and they check the success field the same way.
When doing syscall auditing always try to combine rules where you can. Each
syscall rule gets evaluated for every syscall every program makes. It adds
up. Try to use file based auditing whenever you can since its not as big of a
performance hit.
It turned out that with some of the audit rule set, the kscope
source compile process takes double time. I wonder why it has so heavy
impact on the system's performance.
See above.
I also read some papers(<<Automatic high-performance
reconstruction and recovery>>) on other audit systems. The system's
impact is relatively low,about 6%~8% with all syscall information
audited.
If you can think of a faster way to do what we are doing, please submit kernel
patches. Any performance improvements would be appreciated.
-Steve
6171
days inactive
6173
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Marius.bao -
Steve Grubb