11:29 p.m.
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.
9:55 a.m.
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
4:51 p.m.
-----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.
5:46 p.m.
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
8:11 a.m.
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
6263
days inactive
6265
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
Matthew Booth -
Steve Grubb -
Todd, Charles