stime(2) auditing on x86_64

stime(2) auditing on x86_64

[Todd, Charles]

[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]

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.  I've looked at the
source code and stime(2) only seems to be audited on i386, ppc, and
s390.  stime(2) is in my libc (nm /lib/libc.so.6 | grep stime).
 
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
 
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?
 
Thanks,
Charlie Todd 
Ball Aerospace & Technologies Corp.  

 



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

[-- Attachment #1.2: Type: text/html, Size: 2326 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: stime(2) auditing on x86_64

[Steve Grubb]

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

RE: stime(2) auditing on x86_64

[Todd, Charles]

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

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

DISA's intent and their SRRs have always been two completely separate
entities.  Testers only see that I don't have that flag, and less
resourceful security folks won't know how to argue back.  Ultimately, we
need to teach DISA to write better tests.  

Thanks for the on-target response.  Sorry to see you were checking
e-mail on the weekend. :-)

Charlie Todd



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

RE: stime(2) auditing on x86_64

[Matthew Booth]

[-- Attachment #1.1: Type: text/plain, Size: 1744 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: stime(2) auditing on x86_64

[Steve Grubb]

On Sunday 28 October 2007 05:51:03 pm Todd, Charles wrote:
> > 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?

Somewhere deeper inside, they probably share some code. But the audit hooks 
are at the entry/exit to the syscall. So, covering one does not cover the 
other. As Matt mentioned, you need 2 syscall rules explicitly stating bit 
size.


> > Not really, I think DISA is telling you the intent and that
> > needs to be interpretted/extended to cover bi-arch systems. 
>
> DISA's intent and their SRRs have always been two completely separate
> entities.  Testers only see that I don't have that flag, and less
> resourceful security folks won't know how to argue back.  Ultimately, we
> need to teach DISA to write better tests.

I'll be updating the sample audit rule sets in the next release to reflect 
both the subtree audit capability (since that's now merged in 2.6.24) and the 
bit sizing. Hopefully this updated rule set will trickle down to the right 
places.

-Steve