[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]