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

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

The other problem is that the audit record doesn't show "syscall=open".
Currently it shows "syscall=2" or "syscall=5", with no mention of mode.
So if an admin wants to see all audit records for the open syscall, they
have to check all records with either "syscall=2" (open 64bit) or
"syscall=5"(open 32bit).  But some of those records could of actually been
generated by 32bit fork (also "syscall=2") or 64bit fstat (also "syscall=5").
Maybe this is something that can be covered by one of the admin tools.
But the record still needs to mention the mode (at least when it is not default case)
in order for the admin tool to be able to distinguish between 32bit open
and a 64bit fstat (both syscall=5).

> Have you tried this on ia64 by any chance?
No.  We don't have an ia64 system yet.  Once we do, I will try it.


> > > 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.
We could assume if not indicated then the default would be 64bit on a 64bit system.  
But we need a way to indicate that it is not the default case.


> 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.
Maybe this is more of a "nice to have" item.