From gww@sac.sfbay.sun.com Tue Mar 31 20:01:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3131XYI004703 for ; Tue, 31 Mar 2009 20:01:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3131Quq046948; Tue, 31 Mar 2009 21:01:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE00J0JJ2K9800@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Mar 2009 20:01:32 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE002RXJ2KA3C0@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Mar 2009 20:01:32 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3131TUS017158; Tue, 31 Mar 2009 20:01:29 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3131RtL004334; Tue, 31 Mar 2009 20:01:27 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3131R13004261; Tue, 31 Mar 2009 20:01:27 -0700 (PDT) Date: Tue, 31 Mar 2009 20:01:27 -0700 (PDT) From: Gary Winiger Subject: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] To: PSARC-ext@sun.com Cc: audit-core@sun.com, jan.friedel@sun.com Message-id: <200904010301.n3131R13004261@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2575 I'm sponsoring this fast track for Jan Friedel and the Solaris Audit project team. The case seeks a Patch Release Binding and a mixed Interface Taxonomy. Committed for the auditd interface, plugin audit_remote; Contracted Project Private for the client-server protocol; no change for the audit.log format and contents sent from the client to the server. See audit_remote(5). auditd(1m), audit_warn(1m), audit.log(4) man pages are unchanged and in the case directory for convenience, as well as the new man page for audit_remote(5) which comprised the majority of the case specification. The timer is set for 8 Apr, 2009. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: ========== PSARC/2002/150 Secure Remote Audit Log started out to provide the functionality that this project proposes. During review, 2002/150's scope was reduced to provide a framework in which to write "auditd plugins" and to provide two auditd(1m) plugins: audit_binfile(5) and audit_syslog(5). audit_binfile writes the binary Solaris Audit log (audit.log(4)) to an administratively configured file. audit_syslog formats and writes syslog(3) messages to the LOG_AUDIT facility. Proposal: ======== Provide for sending the binary Solaris Audit Log securely to a remote system by providing a new auditd plugin audit_remote(5). audit_remote sends the binary audit trail to a configured remote server in the same format as audit_binfile writes to the filesystem. It does this using libgss(3lib) to authenticate the server, and to privacy and integrity protect the transmission. Any of the available GSS mechanisms may be used. The protocol between the plugin and the "audit server" is versioned. Issues: ====== This project only provides the sending side of a complete Solaris remote audit trail solution. The receiving side will to be covered by another, as yet, unscheduled project. The project team believes this case is complete without the receiving side and has a customer request to provide the sending side. (A prototype receiving side will be used for testing, but will not be delivered as part of this project.) While Solaris GSS presently supports both Kerberos v5 and Diffie-Hellman GSS mechanisms as well as SPNEGO, RFC2478, (PSARC/2003/008 SPNEGO GSS Mechanism) mechanism negotiation, the project team believe the Kerberos mechanism is presently the only practical one for general deployment. A "solaris_audit" service port has been requested from IANA, but not yet granted. Is audit_remote(5) sufficiently descriptive to construct a receiving service? From Darren.Moffat@sun.com Wed Apr 1 01:42:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n318gJ5b024937 for ; Wed, 1 Apr 2009 01:42:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n318foID003173; Wed, 1 Apr 2009 09:42:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE0013GYUG2A00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Apr 2009 01:42:16 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE00JOFYUEJ720@nwk-avmta-1.sfbay.Sun.COM>; Wed, 01 Apr 2009 01:42:15 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n318gDeJ022688; Wed, 01 Apr 2009 08:42:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHE00C00XVOZ100@fe-emea-10.sun.com>; Wed, 01 Apr 2009 09:42:13 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHE00G2IYU8IXD0@fe-emea-10.sun.com>; Wed, 01 Apr 2009 09:42:09 +0100 (BST) Date: Wed, 01 Apr 2009 09:42:07 +0100 From: Darren J Moffat Subject: Re: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] In-reply-to: <200904010301.n3131R13004261@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, audit-core@sun.com, Jan.Friedel@sun.com Message-id: <49D328DF.5080201@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904010301.n3131R13004261@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 2238 Gary Winiger wrote: > This project only provides the sending side of a complete Solaris remote > audit trail solution. The receiving side will to be covered by another, > as yet, unscheduled project. The project team believes this case is complete > without the receiving side and has a customer request to provide the sending > side. (A prototype receiving side will be used for testing, but will > not be delivered as part of this project.) Normally I'd be very unhappy about having only a client side to a brand new protocol, particularly given that this is not one specified by any standards body. However the prototype server does exist and I am aware that at least one other server side implementation will be written. Not really an ARC issue but I'd like to see that the prototype server at least be put into a test suite that can be run. > While Solaris GSS presently supports both Kerberos v5 and Diffie-Hellman GSS > mechanisms as well as SPNEGO, RFC2478, (PSARC/2003/008 SPNEGO GSS Mechanism) > mechanism negotiation, the project team believe the Kerberos mechanism is > presently the only practical one for general deployment. > > A "solaris_audit" service port has been requested from IANA, but not yet > granted. Given that the plugin config syntax allows for any port I'm happy that this project can integrate without depending on the IANA assignment. It just means there will be no entry in services(4) for solaris_audit and the plugin must be configured with a port number. If that is the case then the man page should document that fact. > Is audit_remote(5) sufficiently descriptive to construct a receiving service? The only assumption I'm making (and sorry I didn't notice this before in the pre-review) is that each message preceded by a TLV is exactly one complete binary audit record and that we never attempt to send partial records. While that is pretty much implicit in the fact that this is and auditd plugin (and thus never sees partial records), it might be worth making it explicit. Other than that I think I could write a server for this given the description in audit_remote(5). Overall I'm happy with the case architecture and the above are really nits. -- Darren J Moffat From gww@sac.sfbay.sun.com Fri Apr 3 13:33:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n33KXOZN012468 for ; Fri, 3 Apr 2009 13:33:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n33KXM1I003041; Sat, 4 Apr 2009 04:33:23 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHJ00E0DL3LJB00@brm-avmta-1.central.sun.com>; Fri, 03 Apr 2009 14:33:21 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHJ005B3L3KL450@brm-avmta-1.central.sun.com>; Fri, 03 Apr 2009 14:33:21 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33KXIR5020919; Fri, 03 Apr 2009 13:33:18 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n33KXIlI012464; Fri, 03 Apr 2009 13:33:18 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n33KXITZ012463; Fri, 03 Apr 2009 13:33:18 -0700 (PDT) Date: Fri, 03 Apr 2009 13:33:18 -0700 (PDT) From: Gary Winiger Subject: Re: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] To: Darren.Moffat@sun.com, gww@sac.sfbay.sun.com Cc: Jan.Friedel@sun.com, audit-core@sun.com, psarc-ext@sun.com Message-id: <200904032033.n33KXITZ012463@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4173 > Gary Winiger wrote: > > This project only provides the sending side of a complete Solaris remote > > audit trail solution. The receiving side will to be covered by another, > > as yet, unscheduled project. The project team believes this case is complete > > without the receiving side and has a customer request to provide the sending > > side. (A prototype receiving side will be used for testing, but will > > not be delivered as part of this project.) > > Normally I'd be very unhappy about having only a client side to a brand > new protocol, particularly given that this is not one specified by any > standards body. > > However the prototype server does exist and I am aware that at least one > other server side implementation will be written. A very early version of this work is on the opensolaris.org audit project page. When the prototype server, which will be used for testing, is updated, the project team plans to put that code on the audit project page. > Not really an ARC issue but I'd like to see that the prototype server at > least be put into a test suite that can be run. As there really isn't an Audit test suite that is part of regular release testing, this is something management has known about for years, the project team cannot guarantee this. However, when resources are provided to create such a test suite, if the receiving side isn't completed, the prototype used for unit testing will be included. > > Is audit_remote(5) sufficiently descriptive to construct a receiving service? > > The only assumption I'm making (and sorry I didn't notice this before in > the pre-review) is that each message preceded by a TLV is exactly one > complete binary audit record and that we never attempt to send partial > records. While that is pretty much implicit in the fact that this is > and auditd plugin (and thus never sees partial records), it might be > worth making it explicit. Yes, that's the way auditd hands things to the plugins, (see PSARC/2002/150 final.materials/audit_plugin.3 for convenience: ``auditd_rc_t auditd_plugin(const char *buffer, size_t buf_len, uint32_t sequence, char **error_text); auditd_plugin() passes one audit record with the length buf_len. Each record has a sequence number which is a counter maintained by the audit daemon and which starts at one when the plugin is loaded; the count exists primarily for debug and is incremented each time a buffer is queued for your plugin. It overflows to zero with no error. See audit.log(4) for a description of the audit record contents. Error return values (return code of other than AUDITD_SUCCESS) are used to generate warnings from the audit daemon using the audit_warn(1M) script and syslog(3C) and the string returned via "error_text", is passed to audit_warn. If no error text is to be returned, use NULL rather than an empty string. auditd_plugin() may be called from concurrent threads within the audit daemon.'' I'm not sure why it should matter in the protocol, please clarify. A binary blob of audit.log comes to each of the plugins. The audit_binfile plugin writes that blob to the end of the currently active audit trail. audit_remote packages that blob up and sends it as TLV, the receiver unpacks the blob. If the receiver needs to parse the blob, it has to understand the binary audit trail completely as does audit_syslog(5). If the receiver just needs to act like audit_binfile and writes the blob to an active file, it shouldn't matter. Where it might matter is if the receiver want to write each audit.log record to a separate "database record" and not have to parse the binary audit trail. For that concern, the protocol definition will be updated to say that each TVL, represents one audit.log record. If that's the concern, does this addition resolve the concern? Gary.. P.S. There are also minor non architectural typos in the present audit_remote.5. They will also be updated as a final spec when the case closes. s/solaris_audit/solaris-audit/ s/purple.ebay.sun.com:4592:/purple.ebay.sun.com:4592/ From gww@sac.sfbay.sun.com Tue Apr 7 09:52:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n37Gq4kg001173 for ; Tue, 7 Apr 2009 09:52:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n37Gq3cq028188; Tue, 7 Apr 2009 10:52:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHQ00D0JPIRJ100@nwk-avmta-2.sfbay.sun.com>; Tue, 07 Apr 2009 09:52:03 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHQ005XJPIQS2C0@nwk-avmta-2.sfbay.sun.com>; Tue, 07 Apr 2009 09:52:03 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n37Gq0IB007876; Tue, 07 Apr 2009 09:52:00 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n37Gq0R7001154; Tue, 07 Apr 2009 09:52:00 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n37Gpx0R001153; Tue, 07 Apr 2009 09:52:00 -0700 (PDT) Date: Tue, 07 Apr 2009 09:52:00 -0700 (PDT) From: Gary Winiger Subject: Re: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] To: PSARC-ext@sun.com, darren.moffat@sun.com, gww@sac.sfbay.sun.com Cc: audit-core@sun.com, jan.friedel@sun.com Message-id: <200904071652.n37Gpx0R001153@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 322 > The timer is set for 8 Apr, 2009. Members as there is no meeting on 8 Apr, I'd like to confirm that all the issues have been resolved. I believe so. I could read Darren's posting to the case as a +1, and I'd like to ensure I've addressed things before moving on. So, I'm asking if there is a formal +1. Gary.. From Darren.Moffat@sun.com Tue Apr 7 09:54:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n37GswBU001587 for ; Tue, 7 Apr 2009 09:54:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n37Gsj6t025600; Tue, 7 Apr 2009 17:54:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHQ00D05PNIND00@nwk-avmta-2.sfbay.sun.com>; Tue, 07 Apr 2009 09:54:54 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHQ005ANPNHSDD0@nwk-avmta-2.sfbay.sun.com>; Tue, 07 Apr 2009 09:54:54 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n37Gsrjf021747; Tue, 07 Apr 2009 16:54:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHQ00900OW44D00@fe-emea-10.sun.com>; Tue, 07 Apr 2009 17:54:53 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHQ00J6NPMW75E0@fe-emea-10.sun.com>; Tue, 07 Apr 2009 17:54:32 +0100 (BST) Date: Tue, 07 Apr 2009 17:54:31 +0100 From: Darren J Moffat Subject: Re: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] In-reply-to: <200904071652.n37Gpx0R001153@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, audit-core@sun.com, Jan.Friedel@sun.com Message-id: <49DB8547.1070909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904071652.n37Gpx0R001153@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 445 Gary Winiger wrote: >> The timer is set for 8 Apr, 2009. > > Members as there is no meeting on 8 Apr, I'd like to confirm that > all the issues have been resolved. I believe so. I could read > Darren's posting to the case as a +1, and I'd like to ensure > I've addressed things before moving on. > > So, I'm asking if there is a formal +1. I'm happy with the responses to my inquiries so I'm formally giving my +1. -- Darren J Moffat From gww@sac.sfbay.sun.com Wed Apr 8 12:01:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38J1BDO000175 for ; Wed, 8 Apr 2009 12:01:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38J1Amx014229; Wed, 8 Apr 2009 12:01:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00403Q5YSL00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Apr 2009 12:01:10 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00L8VQ5YAE80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Apr 2009 12:01:10 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38J19Ke036505; Wed, 08 Apr 2009 12:01:09 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38J1839029834; Wed, 08 Apr 2009 12:01:08 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n38J18Ai029805; Wed, 08 Apr 2009 12:01:08 -0700 (PDT) Date: Wed, 08 Apr 2009 12:01:08 -0700 (PDT) From: Gary Winiger Subject: Re: sending audit log to a remote system [PSARC/2009/208 FastTrack timeout 04/08/2009] To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com Cc: audit-core@sun.com, jan.friedel@sun.com Message-id: <200904081901.n38J18Ai029805@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 259 > The timer is set for 8 Apr, 2009. The timer having been reached, there being no outstanding issues, there being a positive acknowledgement +1, I've updated the spec (audit_remote.5) with diff marks and I've marked this case as closed approved. Gary.. From gww@sac.sfbay.sun.com Tue Jun 9 14:19:14 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n59LJDPP015472 for ; Tue, 9 Jun 2009 14:19:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n59LJ9YA024087; Wed, 10 Jun 2009 05:19:12 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKZ00301PVZRD00@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 15:19:11 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKZ002UVPVYK610@brm-avmta-1.central.sun.com>; Tue, 09 Jun 2009 15:19:10 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n59LJ8hg019933; Tue, 09 Jun 2009 14:19:08 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n59LJ8oZ015470; Tue, 09 Jun 2009 14:19:08 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n59LJ7nf015469; Tue, 09 Jun 2009 14:19:07 -0700 (PDT) Date: Tue, 09 Jun 2009 14:19:07 -0700 (PDT) From: Gary Winiger Subject: Update: PSARC/2009/208 - sending audit log to a remote system. To: PSARC-ext@sun.com Cc: audit-core@sun.com, jan.friedel@sun.com Message-id: <200906092119.n59LJ7nf015469@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2444 During the implementation and code review phase of PSARC/2009/208, a few changes to the protocol seemed to be advisable to make before audit_remote(5) was integrated. The version number remains unchanged. Only GSS-API functionality is supported at this time. Additionally, IANA granted the "solaris-audit" service port 16162/tcp. /etc/services will be updated with this integration. IANA will be sent the updated protocol specification. I've diff marked and updated audit_remote(5) man page and put it in the case directory. If anyone believes it's necessary to reopen the case, I'll do so and set a new timer. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary of protocol changes: ============================ 1) The protocol version handshake has been changed and moved from within the GSS context to precede GSS context establishment. This change is to allow other forms of OTW protection such as TLS, or even none as might be the case for IPsec protected peers. 2) As part of the GSS security context negotiation, input channel bindings is used to authenticate the version hand shake. 3) An "audit record" sequence number has been added to the sent audit records. That sequence number needs to be returned as part of the message retrieval acknowledgement. This greatly improves the efficiency of audit_remote's receiving thread in verification of the peer's receipt of audit records. Summary of non-protocol changes: ================================ 1) The default timeout has been reduced from 60 seconds to 5 (and the retry algorithm is a semi-exponential backoff) The default number of retries remains 3. 2) The use of TCP_CORK has been eliminated. It didn't appear to provide any benefit. Based on the current Solaris implementation, it seemed to require additional sender code complexity and system calls. If, in the future, this proves to be an unwise decision, TCP_CORK can be re-implemented in audit_remote(5) without affecting the protocol. 3) An explicit outstanding audit record count (rather than the implicit one from the kernel's queue control high water mark) can be specified. The qsize keyword specifies this value. Note that auditd also interprets this keyword for each plugin and allocates plugin specific resources based on it. auditd's default is also the kernel's queue control high water mark.