Re: stime(2) auditing on x86_64

[Steve Grubb <sgrubb@redhat.com>]

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. 
So, you would need to qualify that with b32 to tell it that it should be 
confined to 32 bit processes.

[root ~]# auditctl -a always,exit -F arch=b32 -S stime
[root ~]# auditctl -l
LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=stime

I believe that arch is the only -F option that can be allowed before the -S 
option and its to tell auditctl which syscall table to use for the syscall 
lookup.

> Is this on purpose or is there something deeper?   The full line of what
> DISA expected me to configure is
> -a exit,always -S stime -S acct -S reboot -S swapon

Be careful on bi-arch systems. There are several syscalls that change their 
syscall number between 32 & 64 bit, so you may need 2 sets of rules, one 
with -F arch=b32 and the other with b64. But there are differences between 
arches so that some syscalls have another name on 64 as compared with 32 bit.


> A careful observer will note that the CAPP suggested configuration
> already captures adjtimex and settimeofday.  I just want to pass my
> test, but is there overlap here that I should push back on?

Not really, I think DISA is telling you the intent and that needs to be 
interpretted/extended to cover bi-arch systems. I should probably update the 
man pages to clarify things regarding bi-arch systems. I think Matt Booth 
pointed out something similar a week or two ago.

-Steve