From sacadmin Fri Mar 31 15:28:57 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2VNSvIQ002405 for ; Fri, 31 Mar 2006 15:28:57 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k2VNRibH019859; Fri, 31 Mar 2006 15:27:44 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k2VNRiY8019858; Fri, 31 Mar 2006 15:27:44 -0800 (PST) Date: Fri, 31 Mar 2006 15:27:44 -0800 (PST) From: Gary Winiger Message-Id: <200603312327.k2VNRiY8019858@marduk.eng.sun.com> To: psarc@sac.eng.sun.com Subject: 2006/213 FMRI Audit Token Cc: westmore@eng, jwadams@eng, dave.linder@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 2982 I'm sponsoring this fast track on behalf of the Audit Project team and the SMF Project team. It requests a patch release binding. The exposed interfaces were never formally ARCed. They have been treated by the Audit Project team as stable for some time. The man pages are updated to indicate Stable. This project requests a Stable interface taxonomy for the proposed changes. Full diff-marked man pages are in the case directory. The timer is set for 7 April, 2006. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: When SMF was introduced, it was known that for Common Criteria evaluation purposes, it would have to audit the administrative actions that it implemented. Working in concert, the Audit and SMF project teams have identified that a new audit token type is desired to recored the FRMI. An audit token is a structure within audit.log(4) that provides an information component of an audit record. Defining an audit token allows that site administrator to select audit records from the audit trail with a specific value. For example all records with FMRI "system/system-log". Proposal: Add a new audit token named "fmri" and permit selection of audit records containing that FMRI. The auditreduce(1M) service instance is of the same form accepted throughout the SMF world. The actual toke value is the fully qualified FMRI. ++++++++++++++++ audit.log(4): File Formats audit.log(4) NAME audit.log - audit trail file DESCRIPTION The audit.log files contains audit records. Each audit record is made up of audit tokens. Each record contains a header token followed by various data tokens. Depending on the audit policy in place by auditon(2), optional other tokens such as trailers or sequences may be included. The tokens are defined as follows: + The fmri token consists of: + + token ID 1 byte + fmri length 2 bytes + fmri including terminating NULL byte ++++++++++++++++ auditreduce(1M): System Administration Commands auditreduce(1M) NAME auditreduce - merge and select audit records from audit trail files SYNOPSIS auditreduce [options] [audit-trail-file...] OPTIONS Record Selection Options The record selection options listed below are used to indi- cate which records are written to the output file produced by auditreduce. Multiple arguments of the same type are not permitted. -o object_type=objectID_value Select records by object type. A match occurs when the record contains the information describing the speci- fied object_type and the object ID equals the value specified by objectID_value. The allowable object types and values are as follows: + fmri=service_instance + Select records containing fault management resource + identifier (FMRI) objects with the specified service + instance. See smf(5). From sacadmin Mon Apr 3 01:51:28 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k338pRIQ020139 for ; Mon, 3 Apr 2006 01:51:28 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k338pNoR006620; Mon, 3 Apr 2006 09:51:23 +0100 (BST) Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k338pL4h023071; Mon, 3 Apr 2006 09:51:22 +0100 (BST) Message-ID: <4430E209.5070909@Sun.COM> Date: Mon, 03 Apr 2006 09:51:21 +0100 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM Subject: Re: 2006/213 FMRI Audit Token References: <200603312327.k2VNRiY8019858@marduk.eng.sun.com> In-Reply-To: <200603312327.k2VNRiY8019858@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 95 What about the xml output from praudit(1m) ? Does the DTD need updating ? -- Darren J Moffat From sacadmin Mon Apr 3 08:01:12 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k33F1CIQ011690 for ; Mon, 3 Apr 2006 08:01:12 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k33Exthu022026; Mon, 3 Apr 2006 07:59:55 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k33ExtQk022025; Mon, 3 Apr 2006 07:59:55 -0700 (PDT) Date: Mon, 3 Apr 2006 07:59:55 -0700 (PDT) From: Gary Winiger Message-Id: <200604031459.k33ExtQk022025@marduk.eng.sun.com> To: gww@eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: 2006/213 FMRI Audit Token Cc: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM X-Sun-Charset: US-ASCII Status: RO Content-Length: 640 > What about the xml output from praudit(1m) ? I'm not sure what you're looking for here. Yes, fmri tokens will be translated in both the traditional and xml format of praudit output. > Does the DTD need updating ? Yes, and probably the XSL. Is this architectural or implementation? I agree, the project is not complete without a complete implementaion. Is there a request here to see the dtd and xsl changes as part of this case, or just to state that all parts of the Solaris Audit trail will implement the fmri token? Gary.. P.S. Waiting on Ric Aleshire for some consultation here before the prototype is complete. From sacadmin Mon Apr 3 08:11:27 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k33FBQIQ012184 for ; Mon, 3 Apr 2006 08:11:26 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k33F8CoR024095; Mon, 3 Apr 2006 16:08:12 +0100 (BST) Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k33F8AYK009430; Mon, 3 Apr 2006 16:08:12 +0100 (BST) Message-ID: <44313A5A.6030406@Sun.COM> Date: Mon, 03 Apr 2006 16:08:10 +0100 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM Subject: Re: 2006/213 FMRI Audit Token References: <200604031459.k33ExtQk022025@marduk.eng.sun.com> In-Reply-To: <200604031459.k33ExtQk022025@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1255 Gary Winiger wrote: >> What about the xml output from praudit(1m) ? > > I'm not sure what you're looking for here. Yes, fmri tokens > will be translated in both the traditional and xml format > of praudit output. > >> Does the DTD need updating ? > > Yes, and probably the XSL. > > Is this architectural or implementation? Architecture, the DTD for praudit(1m) is an interface. The changes to the DTD are as important as the changes to the binary audit trail, ie audit.log(4) - in fact I believe much more important since it is much more likely that people depend on the DTD and XSL than on the binary trail these days (or at least I hope it is!). Even though praudit(1m) says the output is unstable, I believe the XML output is intended to be parsable but the other outputs are not, correct ? > I agree, the project is > not complete without a complete implementaion. Is there a request > here to see the dtd and xsl changes as part of this case, or just to > state that all parts of the Solaris Audit trail will implement > the fmri token? I'd like to see the dtd and xsl and know if the version of those is changing or not - ie what if any upgrade issues are expected for people who use the XML output. -- Darren J Moffat From sacadmin Mon Apr 3 11:38:05 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k33Ic5IQ028107 for ; Mon, 3 Apr 2006 11:38:05 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k33Iansl024202; Mon, 3 Apr 2006 11:36:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k33IanqY024201; Mon, 3 Apr 2006 11:36:49 -0700 (PDT) Date: Mon, 3 Apr 2006 11:36:49 -0700 (PDT) From: Gary Winiger Message-Id: <200604031836.k33IanqY024201@marduk.eng.sun.com> To: gww@eng.sun.com, Darren.Moffat@sun.com Subject: Re: 2006/213 FMRI Audit Token Cc: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1879 > > Is this architectural or implementation? > > Architecture, the DTD for praudit(1m) is an interface. > > The changes to the DTD are as important as the changes to > the binary audit trail, ie audit.log(4) - in fact I believe much more > important since it is much more likely that people depend on the DTD and > XSL than on the binary trail these days (or at least I hope it is!). What exactly are you asking for from this case? I don't find the adt_record.dtd.1 or adt_record.xsl.1 in man page. PSARC/2002/377 Audit Trail Translation to XML introduced the -x form or praudit output as Unstable. PSARC/2003/653 Zone name audit token introduced the zone token without any mention of the dtd or xsl. Are you asserting that this project doesn't qualify for a patch release binding? If so, please say why. > Even though praudit(1m) says the output is unstable, I believe > the XML output is intended to be parsable but the other outputs > are not, correct ? In 2002/377, all output was ARCed as Unstable. I expect that to carry forward even into the new taxonomy; -x uncommitted, non-xml output Not an Interface. > > I agree, the project is > > not complete without a complete implementaion. Is there a request > > here to see the dtd and xsl changes as part of this case, or just to > > state that all parts of the Solaris Audit trail will implement > > the fmri token? > > I'd like to see the dtd and xsl and know if the version of > those is changing or not - ie what if any upgrade issues > are expected for people who use the XML output. If I read this correctly you're asserting that this project doesn't qualify for a patch binding if updates are made to the dtd/xsl. I don't agree and would like more detail about your concern. Gary.. P.S. I'm happy for you to be a code reviewer once the prototype is ready for prime time. From sacadmin Tue Apr 4 02:18:33 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k349IWIQ005309 for ; Tue, 4 Apr 2006 02:18:32 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k349ISoR027228; Tue, 4 Apr 2006 10:18:28 +0100 (BST) Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k349IQ3o006902; Tue, 4 Apr 2006 10:18:28 +0100 (BST) Message-ID: <443239E2.60005@Sun.COM> Date: Tue, 04 Apr 2006 10:18:26 +0100 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM Subject: Re: 2006/213 FMRI Audit Token References: <200604031836.k33IanqY024201@marduk.eng.sun.com> In-Reply-To: <200604031836.k33IanqY024201@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3468 Gary Winiger wrote: >>> Is this architectural or implementation? >> Architecture, the DTD for praudit(1m) is an interface. >> >> The changes to the DTD are as important as the changes to >> the binary audit trail, ie audit.log(4) - in fact I believe much more >> important since it is much more likely that people depend on the DTD and >> XSL than on the binary trail these days (or at least I hope it is!). > > What exactly are you asking for from this case? I don't find > the adt_record.dtd.1 or adt_record.xsl.1 in man page. Really ? In the FILES section of praudit(1m): /usr/share/lib/xml/dtd Directory containing the verisioned DTD file refer- enced in XML output, for example, adt_record.dtd.1. /usr/share/lib/xml/style Directory containing the versioned XSL file refer- enced in XML output, for example, adt_record.xsl.1. > PSARC/2002/377 Audit Trail Translation to XML > introduced the -x form or praudit output as Unstable. Right so it is an interface that can't be broken in a micro/patch binding. I believe this > PSARC/2003/653 Zone name audit token > introduced the zone token without any mention of the dtd or > xsl. I didn't catch it then, did the DTD and XSL get updated as a result of the implementation of that case ? > Are you asserting that this project doesn't qualify for a > patch release binding? If so, please say why. It is my understanding that if you change the DTD you update the DTD at all you need to change the version number. The DTD is Unstable. Unless we present the changes to the DTD including, if required the new version number info, I can't tell if it would be compatible or not so I can't say it if it is suitable for patch binding (being that Unstable interfaces shouldn't break in a patch). > In 2002/377, all output was ARCed as Unstable. I expect that to > carry forward even into the new taxonomy; -x uncommitted, non-xml > output Not an Interface. I would actually expect that the XML output should be Stable/Commmited but (and it is by virtue of using a DTD) versioned. > If I read this correctly you're asserting that this project > doesn't qualify for a patch binding if updates are made to > the dtd/xsl. I don't agree and would like more detail about > your concern. Without seeing the DTD/XSL I can't say if it is compatible or not so I don't know if it is or now. I very much doubt I would reject this case it is just too much goodness and really needs to have patch binding for the CC eval. It is really just that I want to make sure that if we should be upping the version number of the DTD (and I think adding elements requires that but I'm no XML expert) then it is an interface that should be presented with the case. Given that the XML output is Unstable and the DTD defines what that output is. > Gary.. > P.S. I'm happy for you to be a code reviewer once the prototype > is ready for prime time. More than happy to review! I'm trying to make sure that the line between architecture and implementation for things like this is clear. I think it is a little fuzzy in many peoples heads at the moment as we gain experience with revising DTDs. -- Darren J Moffat From sacadmin Tue Apr 4 08:26:28 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k34FQSIQ022503 for ; Tue, 4 Apr 2006 08:26:28 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k34FPBuZ025789; Tue, 4 Apr 2006 08:25:11 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k34FPBhY025788; Tue, 4 Apr 2006 08:25:11 -0700 (PDT) Date: Tue, 4 Apr 2006 08:25:11 -0700 (PDT) From: Gary Winiger Message-Id: <200604041525.k34FPBhY025788@marduk.eng.sun.com> To: gww@eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: 2006/213 FMRI Audit Token Cc: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM X-Sun-Charset: US-ASCII Status: RO Content-Length: 6199 > > What exactly are you asking for from this case? I don't find > > the adt_record.dtd.1 or adt_record.xsl.1 in man page. > > Really ? > > In the FILES section of praudit(1m): Yes, they are there. I meant individual man pages on the adt_record.dtd/xsl that there should have been updates made and recorded with the case. > > PSARC/2002/377 Audit Trail Translation to XML > > introduced the -x form or praudit output as Unstable. > > Right so it is an interface that can't be broken in a micro/patch > binding. I believe this > > > PSARC/2003/653 Zone name audit token > > introduced the zone token without any mention of the dtd or > > xsl. > > I didn't catch it then, did the DTD and XSL get updated as a > result of the implementation of that case ? Yes. Every new token updates the dtd/xsl. > > Are you asserting that this project doesn't qualify for a > > patch release binding? If so, please say why. > > It is my understanding that if you change the DTD you update the DTD at > all you need to change the version number. The DTD is Unstable. I'm not an expert here. That sure doesn't seem to be the way other projects have worked. Nor, is it the way the Audit project has worked in the past. I understood dtd versioning was like a library. Upwardly compatible changes didn't rev the version, while incompatible ones did; you could add, but not subtract nor change in an incompatible way. Offline, perhaps you can point this project to expert advice. > Unless we present the changes to the DTD including, if required the new > version number info, I can't tell if it would be compatible or not so I > can't say it if it is suitable for patch binding (being that Unstable > interfaces shouldn't break in a patch). > Without seeing the DTD/XSL I can't say if it is compatible or > not so I don't know if it is or now. > More than happy to review! Prototype --- I'll accept the approval of this case as your code review ;-) ------- usr/src/lib/libbsm/adt_record.dtd.1 ------- Index: usr/src/lib/libbsm/adt_record.dtd.1 *** /ws/onnv-clone/usr/src/lib/libbsm/adt_record.dtd.1 Sat Jun 11 23:22:25 2005 --- /net/rankine.eng/export9/gww/smf/usr/src/lib/libbsm/adt_record.dtd.1 Mon Apr 3 08:34:18 2006 *************** *** 1,15 **** --- 23,29 ---- CDDL HEADER END ! ident "@(#)adt_record.dtd.1 1.11 06/04/03 SMI" --> *************** *** 85,90 **** --- 84,90 ---- exit | exec_args | exec_env | + fmri | group | information_label | ip | *************** *** 216,221 **** --- 216,224 ---- seq-num CDATA #REQUIRED > + + + ------- usr/src/lib/libbsm/adt_record.xsl.1 ------- Index: usr/src/lib/libbsm/adt_record.xsl.1 *** /ws/onnv-clone/usr/src/lib/libbsm/adt_record.xsl.1 Sat Jun 11 23:22:25 2005 --- /net/rankine.eng/export9/gww/smf/usr/src/lib/libbsm/adt_record.xsl.1 Mon Apr 3 08:34:19 2006 *************** *** 1,15 **** --- 23,29 ---- CDDL HEADER END ! ident "@(#)adt_record.xsl.1 1.10 06/04/03 SMI" --> *************** *** 170,175 **** --- 169,179 ---- seq-num: + +
+ FMRI: + +
GROUP From sacadmin Wed Apr 5 03:47:40 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k35AldIQ013014 for ; Wed, 5 Apr 2006 03:47:39 -0700 (PDT) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35AlZoR017502; Wed, 5 Apr 2006 11:47:35 +0100 (BST) Received: from [129.150.120.102] (vpn-129-150-120-102.UK.Sun.COM [129.150.120.102]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k35AlY8A007543; Wed, 5 Apr 2006 11:47:35 +0100 (BST) Message-ID: <44339FD4.7050405@Sun.COM> Date: Wed, 05 Apr 2006 11:45:40 +0100 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Gary Winiger CC: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM Subject: Re: 2006/213 FMRI Audit Token References: <200604041525.k34FPBhY025788@marduk.eng.sun.com> In-Reply-To: <200604041525.k34FPBhY025788@marduk.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 332 The DTD and XSL look fine. As Gary mentioned to me offline he has check with an XML expert and these changes are compatible so don't require a change in the version number. I'm happy with this case now. I would like that all future cases that add new audit tokens present the DTD and XSL as part of the case material. Darren. From sacadmin Wed Apr 5 12:06:43 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k35J6hIQ029249 for ; Wed, 5 Apr 2006 12:06:43 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id k35J5ORo007976; Wed, 5 Apr 2006 12:05:25 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.12.11+Sun/8.12.11/Submit) id k35J5Ocb007975; Wed, 5 Apr 2006 12:05:24 -0700 (PDT) Date: Wed, 5 Apr 2006 12:05:24 -0700 (PDT) From: Gary Winiger Message-Id: <200604051905.k35J5Ocb007975@marduk.eng.sun.com> To: gww@eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: 2006/213 FMRI Audit Token Cc: psarc@sac.eng.sun.com, westmore@eng.sun.com, jwadams@eng.sun.com, dave.linder@Sun.COM X-Sun-Charset: US-ASCII Status: RO Content-Length: 57 This case was approved at today's PSARC meeting. Gary..