32bit and 64bit syscall issues

[Debora Velarde]

> > ---------------
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050314/a4c76a9a/attachment.htm>