Re: 32bit and 64bit syscall issues
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.
Attachments:
- attachment.html (text/html — 2.9 KB)