Re: 32bit and 64bit syscall issues
On Monday 14 March 2005 13:04, Debora Velarde wrote:
When I brought up this issue it was thought that this could be solved
by
filtering on personality.
I think it sets the personality to 0 - which means LINUX.
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?
I'll ask around and see if I can find something to help you out. If ld can
figure out what to do, so can we.
But we need to be able to distinguish if it was compiled in 32bit or
64bit
mode.
True, but I still need to do some research on this topic. The whole
personality 64 bit / 32 bit issue is not something I was planning to work on
until after I have the search utility written.
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.
The code that generates the table is syscallgen.c. It includes <sys/syscall.h>
which includes <asm/unistd.h>.
So once auditctl checks both of the unistd.h files, it shouldn't
have a
problem translating any of the syscall numbers.
The table is built at compile time. auditctl does not query the files.
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
But if you look in the kernel's include file, it is __NR_chown. So where did
the 16 come from? Which name is really valid? The tables have to be
automatically generated or there is way to much room for human error.
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'.
Right. I still wonder about the name. I wonder if strace adds the 16 to it?
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.
The 32 refers to the sizeof uid_t. You can have a 32 bit app with a 16 bit
uid_t. What's of interest is what RHEL4 is compiled with for uid_t.
-Steve