From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Todd, Charles" Subject: stime(2) auditing on x86_64 Date: Sat, 27 Oct 2007 00:29:39 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2116041769==" Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9R4Tq9L003307 for ; Sat, 27 Oct 2007 00:29:52 -0400 Received: from p02c11o146.mxlogic.net (p02c11o146.mxlogic.net [208.65.144.79]) by mx3.redhat.com (8.13.1/8.13.1) with ESMTP id l9R4Tfhs000771 for ; Sat, 27 Oct 2007 00:29:41 -0400 Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com This is a multi-part MIME message. --===============2116041769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="=_reb-r61481ADD-t4722BEB6" This is a multi-part MIME message. --=_reb-r61481ADD-t4722BEB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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). =20 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 =20 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? =20 Thanks, Charlie Todd=20 Ball Aerospace & Technologies Corp. =20 =20 This message and any enclosures are intended only for the addressee. Pleas= e =20 notify the sender by email if you are not the intended recipient. If you a= re =20 not the intended recipient, you may not use, copy, disclose, or distribute = this =20 message or its contents or enclosures to any other person and any such acti= ons =20 may be unlawful. Ball reserves the right to monitor and review all message= s =20 and enclosures sent to or from this email address. --=_reb-r61481ADD-t4722BEB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was try= ing to get=20 my system to pass a System Readiness Review (SRR) from disa.mil and it woul= d=20 appear that stime(2) is not audited under x86_64, either in v1.0.15 or v1.2= .1 of=20 auditd. I've looked at the source code and stime(2) only seems to be= =20 audited on i386, ppc, and s390. stime(2) is in my libc (nm /lib/libc.= so.6=20 | grep stime).

Is this o= n purpose=20 or is there something deeper? The full line of what DISA expect= ed me=20 to configure is

-a exit,a= lways -S=20 stime -S acct -S reboot -S swapon

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

Thanks,

Charlie Todd
Ball Aerospa= ce=20 & Technologies Corp.


This message and any enclosures are intended only for the addressee.  Pleas=
e =20
notify the sender by email if you are not the intended recipient.  If you a=
re =20
not the intended recipient, you may not use, copy, disclose, or distribute =
this =20
message or its contents or enclosures to any other person and any such acti=
ons =20
may be unlawful.  Ball reserves the right to monitor and review all message=
s =20
and enclosures sent to or from this email address.

--=_reb-r61481ADD-t4722BEB6-- --===============2116041769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2116041769==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: stime(2) auditing on x86_64 Date: Sat, 27 Oct 2007 10:55:27 -0400 Message-ID: <200710271055.28054.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Todd, Charles" Subject: RE: stime(2) auditing on x86_64 Date: Sun, 28 Oct 2007 17:51:03 -0400 Message-ID: References: <200710271055.28054.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: <200710271055.28054.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux Audit List-Id: linux-audit@redhat.com > -----Original Message----- > From: Steve Grubb > Sent: Saturday, October 27, 2007 10:55 AM > Subject: Re: stime(2) auditing on x86_64 >=20 > On Saturday 27 October 2007 12:29:39 am Todd, Charles wrote: > > I was trying to get my system to pass a System Readiness=20 > Review (SRR)=20 > > from disa.mil and it would appear that stime(2) is not=20 > audited under=20 > > x86_64, either in v1.0.15 or v1.2.1 of auditd. >=20 > That is because x86_64 does not have that syscall. It uses=20 > settimeofday for the same functionality. But, it does exist=20 > in the 32 bit compatibility layer.=20 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=20 > > already captures adjtimex and settimeofday. I just want to pass my=20 > > test, but is there overlap here that I should push back on? >=20 > Not really, I think DISA is telling you the intent and that=20 > needs to be interpretted/extended to cover bi-arch systems. I=20 > should probably update the man pages to clarify things=20 > regarding bi-arch systems. I think Matt Booth pointed out=20 > something similar a week or two ago. >=20 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. =20 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. Ple= ase =20 notify the sender by email if you are not the intended recipient. If you= are =20 not the intended recipient, you may not use, copy, disclose, or distribut= e this =20 message or its contents or enclosures to any other person and any such ac= tions =20 may be unlawful. Ball reserves the right to monitor and review all messa= ges =20 and enclosures sent to or from this email address. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: RE: stime(2) auditing on x86_64 Date: Sun, 28 Oct 2007 22:46:36 +0000 Message-ID: <1193611596.6385.6.camel@localhost.localdomain> References: <200710271055.28054.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1656845611==" Return-path: Received: from [192.168.250.105] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id l9SMkdbc003483 for ; Sun, 28 Oct 2007 18:46:45 -0400 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1656845611== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QFT7tkUMm/7k09amuxVo" --=-QFT7tkUMm/7k09amuxVo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 > >=20 > > On Saturday 27 October 2007 12:29:39 am Todd, Charles wrote: > > > I was trying to get my system to pass a System Readiness=20 > > Review (SRR)=20 > > > from disa.mil and it would appear that stime(2) is not=20 > > audited under=20 > > > x86_64, either in v1.0.15 or v1.2.1 of auditd. > >=20 > > That is because x86_64 does not have that syscall. It uses=20 > > settimeofday for the same functionality. But, it does exist=20 > > in the 32 bit compatibility layer.=20 >=20 > 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 --=20 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 --=-QFT7tkUMm/7k09amuxVo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBHJRFMNEHqGdM8NJARAsWsAJ4yab1bqevBcqcyOWR73W9CNj+hOwCgi8fE nsIPQbmOfYgXMp5x+v9VC2o= =v8HH -----END PGP SIGNATURE----- --=-QFT7tkUMm/7k09amuxVo-- --===============1656845611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1656845611==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: stime(2) auditing on x86_64 Date: Mon, 29 Oct 2007 09:11:52 -0400 Message-ID: <200710290911.52675.sgrubb@redhat.com> References: <200710271055.28054.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Todd, Charles" Cc: Linux Audit List-Id: linux-audit@redhat.com 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