32bit and 64bit syscall issues
Chris Wright
chrisw at osdl.org
Tue Mar 15 08:52:17 UTC 2005
* Debora Velarde (dvelarde at us.ibm.com) wrote:
> > > ---------------
> > > 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.
OK, that sounds like a small buglet to me.
> > > ---------------
> > > 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).
Hrm, I didn't have this problem. But anyway, if you look at the x86_64
kernel, it looks like you'll get PER_LINUX|READ_IMPLIES_EXEC or simply
PER_LINUX for a 32bit binaries. In either case, this is not useful for
32bit vs. 64bit distinction. However, looking at sparc64 and ia64,
for example, they appear to set PER_LINUX32 for 32-bit ELF programs.
Looks as if this was intentional on x86_64.
> Is personality only useful in determining what OS it was compiled on, and
> not the mode the program itself was compiled in?
One issue is, personality can be trivially set from userspace. So, it looks
to be meaningless for audit since the user has ability to change it, w/out
audit being informed, allowing user to potentially dodge audit filters.
> 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?
No, that's not the right method. The kernel knows which mode the binary
is running in. The question, in my mind, is about setting which modes
to care about. E.g. if you say -S open -F uid=500, you want open()
calls to be audited regargdless of mode (otherwise user could use 32bit
app to avoid being audited).
> > > 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?
Have you tried this on ia64 by any chance?
> > > ---------------
> > > 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.
Sorry, by native I meant 64bit on a 64bit machine.
> > > ---------------
> > > 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.
Heh, I see. This is an issue of legacy interfaces (like exporting only
16bit uids), not mode (although I wouldn't be surprised if x86_64 64bit
mode didn't even support the old chown16, since its apps are newer,
meaning compiled recently and against newer glibc, and would never pick
up the old legcay interface). Realistically, I'd expect these are
things you'll find rarely, maybe in statically linked old binaries.
It's probably simplest (esp. for admins) to make auditctl aware of these
idiosyncrasies.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
More information about the Linux-audit
mailing list