On Tuesday 10 May 2005 10:07, Debora Velarde wrote:
Does this mean that on X86_64 a record for semget shows up as a
record of
type AUDIT_SYSCALL, but on all platforms, it comes out as AUDIT_IPC record?
Also true for other syscalls including: msgctl, msgget, msgrecv, msgsend,
semctl, semop, semtimedop, shmat, shmctl, shmdt, shmget.
No. They will be the same as they are now - 2 records with same serial number.
One piece will be labelled SYSCALL and include all the normal info for
syscalls. The other piece will have an IPC label. Currently, they both have
KERNEL label.
Incidentally here's a sample from my logs for ipc:
auditctl -a entry,always -S ipc
type=SYSCALL msg=audit(1115734892.933:11104482): syscall=117 arch=40000003
success=yes exit=0 a0=18 a1=9000e a2=100 a3=0 items=0 pid=22636 loginuid=525
uid=525 gid=525 euid=525 suid=525 fsuid=525 egid=525 sgid=525 fsgid=525
comm="firefox-bin" exe=/usr/lib/firefox-1.0.3/firefox-bin
There doesn't seem to be any supplemental records. I'll investigate.
+define AUDIT_SOCKET 1304 /* Socket record */
Would this make the bind syscall generate records of type AUDIT_SOCKET?
That is the plan. bind and connect. Before anyone says connect is not a
security related function...we know. We want to provide extra information for
that call.
Incidentally, I've found one bug in the patch. Wherever AUDIT_USER is, I
needed to add the new user types.
-Steve Grubb