From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Todd, Charles" Subject: close(2) not being audited? Date: Thu, 28 Dec 2006 16:58:44 -0500 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1496703572==" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBSLwr19022127 for ; Thu, 28 Dec 2006 16:58:53 -0500 Received: from extavgw4.ball.com (extavgw4.ball.com [162.18.103.211]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBSLwqLo022036 for ; Thu, 28 Dec 2006 16:58:52 -0500 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@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============1496703572== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72ACB.57BD959F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72ACB.57BD959F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, I'm on an RHEL4u3 with Steve's preliminary 1.0.15 package (I built the RPM) under x86_64 2.6.9-34-ELsmp. I'm using the CAPP.rules sample fileset to great success. NISPOM 8-602 requires that CLOSE operations on security-relevant objects be logged. Well, I've got logging for OPEN on security-relevant objects (with the watches) working VERY well (yeah!!!). The default CAPP.rules file had nothing about close(2), so just to test it, I ran: auditctl -a entry,possible -S close and then as a normal user typed: cat /etc/group (which is a security-relevant object that I have permission to open, and thus eventually close) However, when I review the audit files, nothing is logged. If I change the "entry,possible" to "entry,always" then lots of stuff gets logged, but not my actual opening of the /etc/group file. There is only one other thing that could be a configuration issue: "auditctl -l |grep /etc/group" reveals an additional "perm=3Dwa" field that is set by the -p option in CAPP.rules, but even if root writes to one of the watched files, close(2) is still not logged. =20 Do I have a configuration problem or is something deeper going on? =20 Thanks, Charlie Todd=20 Ball Aerospace & Technologies Corp. =20 ctodd- at -ball.com=20 =20 ------_=_NextPart_001_01C72ACB.57BD959F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

I'm on = an RHEL4u3=20 with Steve's preliminary 1.0.15 package (I built the RPM) under x86_64=20 2.6.9-34-ELsmp. I'm using the CAPP.rules sample fileset to great=20 success. NISPOM 8-602 requires that CLOSE operations on = security-relevant=20 objects be logged. Well, I've got logging for OPEN on = security-relevant=20 objects (with the watches) working VERY well (yeah!!!). The = default=20 CAPP.rules file had nothing about close(2), so just to test it, I=20 ran:

= auditctl -a=20 entry,possible -S close

and = then as a normal=20 user typed: cat /etc/group (which is a security-relevant object that I = have=20 permission to open, and thus eventually close)

However, when I=20 review the audit files, nothing is logged. If I change the=20 "entry,possible" to "entry,always" then lots of stuff gets logged, but = not my=20 actual opening of the /etc/group file.

= There is only=20 one other thing that could be a configuration issue: "auditctl -l |grep=20 /etc/group" reveals an additional "perm=3Dwa" field that is set by the = -p option=20 in CAPP.rules, but even if root writes to one of the watched files, = close(2) is=20 still not logged.

Do I have a configuration problem or is = something=20 deeper going on?

Thanks,

Charlie Todd
Ball = Aerospace=20 & Technologies Corp.
ctodd- at=20 -ball.com

------_=_NextPart_001_01C72ACB.57BD959F-- --===============1496703572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1496703572==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: close(2) not being audited? Date: Sat, 30 Dec 2006 09:36:05 -0500 Message-ID: <200612300936.05707.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 Thursday 28 December 2006 16:58, Todd, Charles wrote: > NISPOM 8-602 requires that CLOSE operations on security-relevant objects be > logged. Well, I've got logging for OPEN on security-relevant objects (with > the watches) working VERY well (yeah!!!). The default CAPP.rules file had > nothing about close(2), CAPP says nothing about this syscall other than the ability to audit it. Which you can get with "auditctl -a entry,always -S close", which admittedly is overkill. > so just to test it, I ran: > auditctl -a entry,possible -S close > and then as a normal user typed: cat /etc/group (which is a > security-relevant object that I have permission to open, and thus > eventually close) I'd want to see the accompanying watch for that file. > However, when I review the audit files, nothing is logged. Hmm. > If I change the "entry,possible" to "entry,always" then lots of stuff gets > logged, but not my actual opening of the /etc/group file. This would log all close system calls - even socket closes. > There is only one other thing that could be a configuration issue: > "auditctl -l |grep /etc/group" reveals an additional "perm=wa" field > that is set by the -p option in CAPP.rules, but even if root writes to > one of the watched files, close(2) is still not logged. I think that open is called with either read and/or write flag set. This is how it picks up an event for open. However, close is neither read nor write. > Do I have a configuration problem or is something deeper going on? Probably something deeper. I'd say you should open a support request so that it gets fixed. I think we'd also want to verify this for the current upstream kernels to make sure kernel.org kernels havethis solved. FC6 is probably new enough to test for that purpose. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 12:37:40 -0500 Message-ID: <200701261237.40345.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 Thursday 28 December 2006 16:58, Todd, Charles wrote: > NISPOM 8-602 requires that CLOSE operations on security-relevant objects be > logged. Out of curiosity, what level of effort does the audit system need to go to? Would auditing the close syscall be sufficient? Does dups() need to be followed? What about descriptor inheritance? And passing descriptors between processes via af_unix? -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: ramsdell@mitre.org (John D. Ramsdell) Subject: Re: close(2) not being audited? Date: 26 Jan 2007 13:03:20 -0500 Message-ID: References: <200701261237.40345.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <200701261237.40345.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: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com > Out of curiosity, what level of effort does the audit system need to > go to? Would auditing the close syscall be sufficient? Does dups() > need to be followed? What about descriptor inheritance? And passing > descriptors between processes via af_unix? Keeping track of the life cycle of file descriptors, though dups, forks, and close on execs, is what Polgen's tracker does. Well, almost--it doesn't handle passing descriptors between processes via af_unix, and it doesn't handle the System V IPC calls invoked through ipc. In short, once the audit parsing library is available, I'll use it to feed the results of an ausearch to the tracker. It's output may be of use in analyzing logs, in addition to being an important component in our policy generation tool. John From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wieprecht, Karen M." Subject: RE: close(2) not being audited? Date: Fri, 26 Jan 2007 15:14:10 -0500 Message-ID: References: <200701261237.40345.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: <200701261237.40345.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: Steve Grubb , linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@redhat.com Actually, the exact wording says: "Successful and unsuccessful accesses to security-relevant objects and directories" It does not specify exactly how that should be collected, but the NISPOM does request that the audit record include who tried to access it, what they tried to access, the time and date of the access attempt, what command they were trying to run (rm, chmod, etc.), and if they were successful or not. What happens behind the scenes after the operating system takes over the request may not be of as much interest unless collecting that info helps to provide the above details to the audit record.=20 -Karen Wieprecht -----Original Message----- From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb Sent: Friday, January 26, 2007 12:38 PM To: linux-audit@redhat.com Cc: Todd, Charles Subject: Re: close(2) not being audited? On Thursday 28 December 2006 16:58, Todd, Charles wrote: > NISPOM 8-602 requires that CLOSE operations on security-relevant=20 > objects be logged. Out of curiosity, what level of effort does the audit system need to go to?=20 Would auditing the close syscall be sufficient? Does dups() need to be followed? What about descriptor inheritance? And passing descriptors between processes via af_unix? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 17:19:33 -0500 Message-ID: <20070126221933.GF14621@devserv.devel.redhat.com> References: <200701261237.40345.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline 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: "Wieprecht, Karen M." Cc: "Todd, Charles" , linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote: > Actually, the exact wording says: > > "Successful and unsuccessful accesses to security-relevant objects and > directories" > > It does not specify exactly how that should be collected, but the > NISPOM does request that the audit record include who tried to access > it, what they tried to access, the time and date of the access attempt, > what command they were trying to run (rm, chmod, etc.), and if they > were successful or not. What happens behind the scenes after the > operating system takes over the request may not be of as much interest > unless collecting that info helps to provide the above details to the > audit record. Please, define "access". Consider the following sequence: on April 1st: fd = open(foo, O_RDWR); p = mmap(..., fd, ...); close(fd); two days later: modify area pointed to by p a month later: munmap(p, ...); What do you want in the log? More specifically, _when_ do you want it? Is that close() worth more than munmap()? All file access will be done at least a couple of days after it and file will remain open for more than a month, despite successful call of close(2). The main question here is what are those logs supposed to be useful for, beside the CYA exercises. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 17:01:12 -0600 Message-ID: <20070126170112.6ac08156@crumpet> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0QN1Ro7018188 for ; Fri, 26 Jan 2007 18:01:27 -0500 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l0QN1Q3v018629 for ; Fri, 26 Jan 2007 18:01:26 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0QN1Ef1007275 for ; Fri, 26 Jan 2007 18:01:14 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0QN1EfP227802 for ; Fri, 26 Jan 2007 18:01:14 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0QN1EEC022752 for ; Fri, 26 Jan 2007 18:01:14 -0500 Received: from crumpet (dyn95340155.austin.ibm.com [9.53.40.155]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0QN1EFs022726 for ; Fri, 26 Jan 2007 18:01:14 -0500 In-Reply-To: <20070126221933.GF14621@devserv.devel.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@redhat.com List-Id: linux-audit@redhat.com On Fri, 26 Jan 2007 17:19:33 -0500 Alexander Viro wrote: > On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote: > > Actually, the exact wording says: > > > > "Successful and unsuccessful accesses to security-relevant objects and > > directories" > > > > It does not specify exactly how that should be collected, but the > > NISPOM does request that the audit record include who tried to access > > it, what they tried to access, the time and date of the access attempt, > > what command they were trying to run (rm, chmod, etc.), and if they > > were successful or not. What happens behind the scenes after the > > operating system takes over the request may not be of as much interest > > unless collecting that info helps to provide the above details to the > > audit record. > > Please, define "access". Consider the following sequence: > on April 1st: > fd = open(foo, O_RDWR); > p = mmap(..., fd, ...); > close(fd); > two days later: modify area pointed to by p > a month later: munmap(p, ...); > > What do you want in the log? More specifically, _when_ do you want it? Write out a log when the last reference to the fd is put back... whether that's from a close or an munmap. -tim From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 18:20:51 -0500 Message-ID: <20070126232051.GG14621@devserv.devel.redhat.com> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20070126170112.6ac08156@crumpet> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Timothy R. Chavez" Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote: > > Please, define "access". Consider the following sequence: > > on April 1st: > > fd = open(foo, O_RDWR); > > p = mmap(..., fd, ...); > > close(fd); > > two days later: modify area pointed to by p > > a month later: munmap(p, ...); > > > > What do you want in the log? More specifically, _when_ do you want it? > > Write out a log when the last reference to the fd is put back... whether > that's from a close or an munmap. Sigh... One more time: there are two distinct classes of objects - opened files and opened descriptors. That's the point - by the time of munmap() there is no file descriptor at all. It's been gone for a month. Descriptor getting closed != file getting closed. If you are talking about the last reference to opened file - OK. But there won't necessary be any descriptors refering to it. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 18:29:10 -0500 Message-ID: <20070126232910.GH14621@devserv.devel.redhat.com> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20070126170112.6ac08156@crumpet> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Timothy R. Chavez" Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote: > > What do you want in the log? More specifically, _when_ do you want it? > > Write out a log when the last reference to the fd is put back... whether > that's from a close or an munmap. BTW... Consider the following: threads A and B share descriptor table. Their stdin is a terminal. Apr 1: thread A calls read(0, buf, 512); Apr 2: thread B does close(0); May 1: user hits enter After Apr 2 we'll have descriptor 0 closed. Thread A is still sitting in read() and it couldn't care less about descriptors. The file is still opened, even though all descriptors are gone. On May 1 read() in thread A finally completes. Upon exit from read() we give up a reference to file, so it finally gets closed. IOW, you'll get "it's been closed by read(2)" in logs. The same may apply to any system call doing file IO. So userland would better not assume that something recognizable is doing that... From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 17:46:25 -0600 Message-ID: <20070126174625.3f26c955@crumpet> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> <20070126232051.GG14621@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070126232051.GG14621@devserv.devel.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: Alexander Viro Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, 26 Jan 2007 18:20:51 -0500 Alexander Viro wrote: > On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote: > > > Please, define "access". Consider the following sequence: > > > on April 1st: > > > fd = open(foo, O_RDWR); > > > p = mmap(..., fd, ...); > > > close(fd); > > > two days later: modify area pointed to by p > > > a month later: munmap(p, ...); > > > > > > What do you want in the log? More specifically, _when_ do you want it? > > > > Write out a log when the last reference to the fd is put back... whether > > that's from a close or an munmap. > > Sigh... One more time: there are two distinct classes of objects - opened > files and opened descriptors. That's the point - by the time of munmap() > there is no file descriptor at all. It's been gone for a month. > > Descriptor getting closed != file getting closed. If you are talking about > the last reference to opened file - OK. But there won't necessary be > any descriptors refering to it. Yep, I was referring to last reference to opened file. I'd hate to suggest adding a field to the file like "opened_as" which would store the original fd it was assigned, but that would be enough to associate the open() record and the final "close" record. -tim PS: Ugh, at this list for being write-protected :). From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Antill Subject: Re: close(2) not being audited? Date: Sun, 28 Jan 2007 16:40:56 -0500 Message-ID: <1170020456.26475.6.camel@code.and.org> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> <20070126232051.GG14621@devserv.devel.redhat.com> <20070126174625.3f26c955@crumpet> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1748418952==" Return-path: In-Reply-To: <20070126174625.3f26c955@crumpet> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Timothy R. Chavez" Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1748418952== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QYZLVC+ZeazEwEqQFLwF" --=-QYZLVC+ZeazEwEqQFLwF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-01-26 at 17:46 -0600, Timothy R. Chavez wrote: > Yep, I was referring to last reference to opened file. >=20 > I'd hate to suggest adding a field to the file like "opened_as" which wou= ld > store the original fd it was assigned, but that would be enough to associ= ate > the open() record and the final "close" record. fd1 =3D open(...); ptr1 =3D mmap(fd1, ...); close(fd1); fd2 =3D open(...); assert(fd1 =3D=3D fd2); ptr2 =3D mmap(fd2, ...); close(fd2); munmap(ptr1, ...); munmap(ptr2, ...); ...what should appear in the logs here? How are you going to tell which fd each munmap() belongs to? Maybe you mean "log inode/device for the file" and not "original fd", and then if/when you get confused it doesn't matter? --=20 James Antill --=-QYZLVC+ZeazEwEqQFLwF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFvRho11eXTEMrxtQRArjQAJ0Xe9ohli/u39JkRo5cvQzHIYqmugCgh8wM +WyyLTSM+uwaodkr0orApP8= =iTuK -----END PGP SIGNATURE----- --=-QYZLVC+ZeazEwEqQFLwF-- --===============1748418952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1748418952==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: close(2) not being audited? Date: Mon, 29 Jan 2007 14:19:31 -0600 Message-ID: <20070129141931.75da4731@crumpet> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> <20070126232051.GG14621@devserv.devel.redhat.com> <20070126174625.3f26c955@crumpet> <1170020456.26475.6.camel@code.and.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1170020456.26475.6.camel@code.and.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: James Antill Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sun, 28 Jan 2007 16:40:56 -0500 James Antill wrote: > On Fri, 2007-01-26 at 17:46 -0600, Timothy R. Chavez wrote: > > > Yep, I was referring to last reference to opened file. > > > > I'd hate to suggest adding a field to the file like "opened_as" which would > > store the original fd it was assigned, but that would be enough to associate > > the open() record and the final "close" record. > > > fd1 = open(...); > ptr1 = mmap(fd1, ...); > close(fd1); > > fd2 = open(...); > assert(fd1 == fd2); > ptr2 = mmap(fd2, ...); > close(fd2); > > munmap(ptr1, ...); > munmap(ptr2, ...); > > ...what should appear in the logs here? How are you going to tell which > fd each munmap() belongs to? > Maybe you mean "log inode/device for the file" and not "original fd", > and then if/when you get confused it doesn't matter? > Well yes, I was assuming you would have the additional context provided by other fields in the record such as inode and device, but on second thought, I think you are right that such information should be sufficient to tie the "close" record with the open() record without needing to correlate an fd between the two (which, like you suggest, would be ambiguous without the additional context, anyway). -tim From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 17:00:18 -0600 Message-ID: <20070126170018.23fd1cd2@crumpet> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0QN0R1e017980 for ; Fri, 26 Jan 2007 18:00:27 -0500 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l0QN0QMk018366 for ; Fri, 26 Jan 2007 18:00:27 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0QN0Ket025947 for ; Fri, 26 Jan 2007 18:00:20 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0QN0K8P038154 for ; Fri, 26 Jan 2007 18:00:20 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0QN0KFd030671 for ; Fri, 26 Jan 2007 18:00:20 -0500 Received: from crumpet (dyn95340155.austin.ibm.com [9.53.40.155]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0QN0Kqe030626 for ; Fri, 26 Jan 2007 18:00:20 -0500 In-Reply-To: <20070126221933.GF14621@devserv.devel.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@redhat.com List-Id: linux-audit@redhat.com On Fri, 26 Jan 2007 17:19:33 -0500 Alexander Viro wrote: > On Fri, Jan 26, 2007 at 03:14:10PM -0500, Wieprecht, Karen M. wrote: > > Actually, the exact wording says: > > > > "Successful and unsuccessful accesses to security-relevant objects and > > directories" > > > > It does not specify exactly how that should be collected, but the > > NISPOM does request that the audit record include who tried to access > > it, what they tried to access, the time and date of the access attempt, > > what command they were trying to run (rm, chmod, etc.), and if they > > were successful or not. What happens behind the scenes after the > > operating system takes over the request may not be of as much interest > > unless collecting that info helps to provide the above details to the > > audit record. > > Please, define "access". Consider the following sequence: > on April 1st: > fd = open(foo, O_RDWR); > p = mmap(..., fd, ...); > close(fd); > two days later: modify area pointed to by p > a month later: munmap(p, ...); > > What do you want in the log? More specifically, _when_ do you want it? Write out a log when the last reference to the fd is put back... whether that's from a close or an munmap. -tim From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: close(2) not being audited? Date: Fri, 26 Jan 2007 18:03:22 -0600 Message-ID: <20070126180322.74db01da@crumpet> References: <200701261237.40345.sgrubb@redhat.com> <20070126221933.GF14621@devserv.devel.redhat.com> <20070126170112.6ac08156@crumpet> <20070126232910.GH14621@devserv.devel.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070126232910.GH14621@devserv.devel.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: Alexander Viro Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Fri, 26 Jan 2007 18:29:10 -0500 Alexander Viro wrote: > On Fri, Jan 26, 2007 at 05:01:12PM -0600, Timothy R. Chavez wrote: > > > What do you want in the log? More specifically, _when_ do you want it? > > > > Write out a log when the last reference to the fd is put back... whether > > that's from a close or an munmap. > > BTW... Consider the following: threads A and B share descriptor table. > Their stdin is a terminal. > Apr 1: thread A calls read(0, buf, 512); > Apr 2: thread B does close(0); > May 1: user hits enter > > After Apr 2 we'll have descriptor 0 closed. Thread A is still sitting in > read() and it couldn't care less about descriptors. The file is still > opened, even though all descriptors are gone. > > On May 1 read() in thread A finally completes. Upon exit from read() > we give up a reference to file, so it finally gets closed. > > IOW, you'll get "it's been closed by read(2)" in logs. The same > may apply to any system call doing file IO. So userland would better > not assume that something recognizable is doing that... That seems perfectly reasonable to me. -tim