> > --------------- > > Problem 2: > > "auditctl -a" rule also always translates numbers to the syscall name found > > in /usr/include/asm-x86_64/unistd.h
> Even with pers flag?
Yes. The current version of auditctl does.

> > --------------- > > Problem 3: > > Personality is currently always 0 by default. We can NOT assume that an > > application will manually set personality to another number. Therefore we > > cannot currently use the "pers" flag to determine if a syscall was executed > > from a 32bit or a 64bit compiled program.
> What does this mean? It's the ELF headers that will describe how the > program is treated. What am I missing?
When I brought up this issue it was thought that this could be solved by filtering on personality.
But personality is always 0 whether my program was compiled in 32bit or 64 bit (unless I set personality to something else inside my program).
Is personality only useful in determining what OS it was compiled on, and not the mode the program itself was compiled in?
Is it possible to query the ELF headers when the audit record is being created and add the binary mode (32 or 64) in the audit record?

> > Possible Solution 2: > > Fix personality so that it determines from the binary whether it was 32bit > > or 64bit.
> What does this mean? Perhaps it's not personality that needs to be fixed.
Maybe we need a new 'mode' flag to indicate if the executable compiled was in 32bit or 64bit mode?

> > --------------- > > Problem 4: > > Audit record does not indicate if a 32bit or a 64bit syscall was executed. > > Because of this, you are unable to determine which syscall resulted in an > > audit record. > > For example, we cannot currently determine if a record with "syscall=2" > > resulted from an __NR_open call (compiled 64bit) or a __NR_fork call > > (compiled 32bit) because > > From /usr/include/asm-i386/unistd.h: > > #define __NR_fork 2 > > From /usr/include/asm-x86_64/unistd.h: > > #define __NR_open 2 > >
> > Possible Solution 2: > > Fix 'pers' flag so that it can determine if it was a 32bit or 64bit > > syscall. Currently 'pers' flag is included in the audit record if > > 'pers'!=0.
> Is it not legit to assume native binary unless otherwise indicated?
Yes. It is safe to assume that the syscall was compiled on the native OS, Linux.
But we need to be able to distinguish if it was compiled in 32bit or 64bit mode.
> > --------------- > > Problem 5: > > Some syscalls are not defined in either unistd.h file. Therefore, auditctl > > -t is not able to translate the syscall number to a syscall name. This is > > a usability problem for administrators.
> Do you have examples? OK, looking into this further I found what I wrote here isn't correct.
All of the syscall numbers that auditctl isn't able to translate are found in /usr/include/asm-i386/unistd.h.
So once auditctl checks both of the unistd.h files, it shouldn't have a problem translating any of the syscall numbers.

What isn't found in either of the unistd.h files are some of the syscall names.
Some of the syscalls in Klaus' list are found in the header files with a different syscall name.
Here are the ones I found:
Syscall # Klaus /usr/include/asm-i386/unistd.h
182 __NR_chown16 __NR_chown
95 __NR_fchown16 __NR_fchown
16 __NR_lchown16 __NR_lchown
139 __NR_setfsgid16 __NR_setfsgid
138 __NR_setfsuid16 __NR_setfsuid
46 __NR_setgid16 __NR_setgid
81 __NR_setgroups16 __NR_setgroups
71 __NR_setregid16 __NR_setregid
170 __NR_setresgid16 __NR_setresgid
164 __NR_setresuid16 __NR_setresuid
70 __NR_setreuid16 __NR_setreuid
23 __NR_setuid16 __NR_setuid

A user still wouldn't be able to add a filtering rule such as "auditctl -a entry,always -S chown16", but they could add it by the syscall number or the name 'chown'.
It is a little strange that in 32bit mode __NR_chown16 = __NR_chown = 182. But __NR_chown32 = 212. If I added -S chown (running in 32bit mode), I would of thought that it would be auditing __NR_chown32, not __NR_chown16.

-debbie