<html><body> <tt>> > --------------- > > Problem 2: > > "auditctl -a" rule also always translates numbers to the syscall name found > > in /usr/include/asm-x86_64/unistd.h </tt> <tt>> Even with pers flag?</tt> <tt>Yes. The current version of auditctl does. </tt> <tt>> > --------------- > > 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. </tt> <tt>> What does this mean? It's the ELF headers that will describe how the > program is treated. What am I missing?</tt> <tt> When I brought up this issue it was thought that this could be solved by filtering on personality.</tt> <tt>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).</tt> <tt>Is personality only useful in determining what OS it was compiled on, and not the mode the program itself was compiled in?</tt> <tt>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?</tt> <tt>> > Possible Solution 2: > > Fix personality so that it determines from the binary whether it was 32bit > > or 64bit. </tt> <tt>> What does this mean? Perhaps it's not personality that needs to be fixed. </tt> <tt>Maybe we need a new 'mode' flag to indicate if the executable compiled was in 32bit or 64bit mode?</tt> <tt>> > --------------- > > 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 > > </tt> <tt>> > 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. </tt> <tt>> Is it not legit to assume native binary unless otherwise indicated?</tt> <tt>Yes. It is safe to assume that the syscall was compiled on the native OS, Linux.</tt> <tt>But we need to be able to distinguish if it was compiled in 32bit or 64bit mode. </tt> <tt>> > --------------- > > 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. </tt> <tt>> Do you have examples? OK, looking into this further I found what I wrote here isn't correct. </tt> <tt>All of the syscall numbers that auditctl isn't able to translate are found in /usr/include/asm-i386/unistd.h.</tt> <tt>So once auditctl checks both of the unistd.h files, it shouldn't have a problem translating any of the syscall numbers. </tt> <tt>What isn't found in either of the unistd.h files are some of the syscall names.</tt> <tt>Some of the syscalls in Klaus' list are found in the header files with a different syscall name.</tt> <tt>Here are the ones I found:</tt> <tt>Syscall # Klaus /usr/include/asm-i386/unistd.h</tt> <tt>182 __NR_chown16 __NR_chown</tt> <tt>95 __NR_fchown16 __NR_fchown</tt> <tt>16 __NR_lchown16 __NR_lchown</tt> <tt>139 __NR_setfsgid16 __NR_setfsgid</tt> <tt>138 __NR_setfsuid16 __NR_setfsuid</tt> <tt>46 __NR_setgid16 __NR_setgid</tt> <tt>81 __NR_setgroups16 __NR_setgroups</tt> <tt>71 __NR_setregid16 __NR_setregid</tt> <tt>170 __NR_setresgid16 __NR_setresgid</tt> <tt>164 __NR_setresuid16 __NR_setresuid</tt> <tt>70 __NR_setreuid16 __NR_setreuid</tt> <tt>23 __NR_setuid16 __NR_setuid</tt> <tt>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'.</tt> <tt>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.</tt> <tt>-debbie</tt> </body></html>