32bit and 64bit syscall issues

[Debora Velarde]

Our current audit solution has some problems when a user tries to audit
32bit syscalls on x86_64 systems.  (This is a CAPP requirement.)
Most of the problems are due to the fact that there are two unistd.h files
on x86_64 systems.
64bit syscalls are defined in /usr/include/asm-x86_64/unistd.h
32bit syscalls are defined in /usr/include/asm-i386/unistd.h
In these two files, the syscall numbers assigned to syscall names are not
the same.
      For example:
      From /usr/include/asm-i386/unistd.h:
            #define __NR_fork 2
            #define __NR_open 5
      From /usr/include/asm-x86_64/unistd.h:
            #define __NR_open 2
            #define __NR_fstat      5

---------------
Problem 1:
"auditctl -t" always translates numbers to name based on
/usr/include/asm-x86_64/unistd.h
(When compiled in 64bit mode on a 64bit system).

Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.

Possible Solution 2:
Modify auditctl to return both 32bit and 64bit syscall names associated
with that number.  This will require a change in how Steve creates his
table.
      Example:
            auditctl -t 2
           Would Return:
            32bit: fork
            64bit: open

Possible Solution 3:
Modify auditctl -t option to require an additional flag indicating whether
the 32bit or the 64bit syscall number should be returned.  Could possibly
use the "-F pers=" flag.

---------------
Problem 2:
"audictl -a" rule also always translates numbers to the syscall name found
in /usr/include/asm-x86_64/unistd.h

Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.

Possible Solution 2:
auditctl -a <l,a> -S <syscall name> should require additional flag
indicating if 32bit, 64bit, or both syscalls should be audited.  Could
possibly use the "pers" flag, assuming personality can determine if a
syscall was compiled 32bit or 64bit.
Then audit rule(s) can be added for the correct syscall number(s).
auditctl -A, and auditctl -d rules would also need to be changed.

---------------
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.

Possible Solution 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.
Then we would not need to filter on "pers" flag.

Possible Solution 2:
Fix personality so that it determines from the binary whether it was 32bit
or 64bit.

---------------
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 1:
Modify /usr/include/asm-i386/unistd.h and /usr/include/asm-x86_64/unistd.h
so that the 32bit and the 64bit syscall number of any syscall are the same
number.

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.

---------------
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.

Possible Solution 1:
Add these other syscalls (found in Klaus' syscalltab file, but not in
unistd.h).

Possible Solution 2:
Include an additional header file containing these other syscalls (found in
Klaus' syscalltab file, but not in unistd.h) along with audit, so that
audictl is able to translate those syscall numbers to name.

---------------

I don't know how feasible it is to change the <syscall name> to <syscall
number> mapping so that usr/include/asm-i386/unistd.h and
/usr/include/asm-x86_64/unistd.h are in agreement with each other.  But if
it is possible to change this, it could fix several of our problems.

-debbie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050311/afb38cd4/attachment.htm>