RE: stime(2) auditing on x86_64
On Sun, 2007-10-28 at 17:51 -0400, Todd, Charles wrote:
> -----Original Message-----
> From: Steve Grubb
> Sent: Saturday, October 27, 2007 10:55 AM
> Subject: Re: stime(2) auditing on x86_64
>
> On Saturday 27 October 2007 12:29:39 am Todd, Charles wrote:
> > I was trying to get my system to pass a System Readiness
> Review (SRR)
> > from disa.mil and it would appear that stime(2) is not
> audited under
> > x86_64, either in v1.0.15 or v1.2.1 of auditd.
>
> That is because x86_64 does not have that syscall. It uses
> settimeofday for the same functionality. But, it does exist
> in the 32 bit compatibility layer.
Okay, I understand the bi-arch thing except one thing: does that mean
the 32-bit compatability layer is ultimately calling the 64-bit version?
If I audit settimeofday(), will it grab both the 64-bit version as well
as the brokered 32-bit stime() call? My gut tells me yes, but I wanted
to ask just to be sure.
No, it will not do this. In fact, it'll do something quite bizarre
instead.
Assuming you didn't explicitly specify an architecture, settimeofday()
will be translated into a syscall number for the default architecture
for x86_64: 164. This will cause an audit record to be generated for any
system call with number 164, namely 64 bit settimeofday() calls, or 32
bit setresuid() calls. This is unlikely to be what you want.
In short, on x86_64 you need to filter on architecture for every rule,
and you need to specify them all twice.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
Attachments:
- signature.asc (application/pgp-signature — 189 bytes)