From Tue Oct 15 14:29:18 2002 Date: Tue, 15 Oct 2002 14:29:18 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 1034717358 1 Delete. This is a system message. --END+PSEUDO-- From sacadmin Mon Oct 7 15:45:14 2002 Date: Mon, 7 Oct 2002 15:42:42 -0700 (PDT) From: Ralph Campbell Subject: Re: PSARC/2002/150 Secure Remote Audit Log To: psarc@sac.eng.sun.com Cc: Tony.Panero@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9JQzEZTs4wWZ2E4Zx8VJoA== Content-Length: 5135 Status: RO X-Status: $$$$ X-UID: 0000000001 Since Gary is out this Wednesday, he posted his issues early to the issues file. Here are Tony's responses for the record. @(#)issues 1.1 02/10/04 Inception issues for 2002/150 Secure Remote Audit Log 10/09/2002 gw-0 Informational: [Tony: omitted -- no response required.] gw-1 Where will the syslog audit trail format be described in the man pages? Added to audit.log(4)? Tony OK. gw-2 What happens to the syslog audit thread when the disk thread has back pressure (file system full)? Presumably if the policy is count, only the disk thread will drop records. If the policy is suspend, both threads will be affected. Is this detail documented for the customer? Tony The discussion of blocking / non-blocking is in the auditconfig man page; I'll update it to cover the loghost case. I agree in the case of the policy "count" being set -- I should continue outputting on any non-blocked thread. In the blocking case, this project adds a thread that does not block; the presumption is that if the policy is to block then if any thread is blocked, all threads are blocked, including those that don't provide backpressure such as UDP. (My answer assumes the future case where UDP is replaced with a reliable mechansim.) gw-3 How will misconfigurations of audit_control loghost: loghostexcl: be reported? Tony The current situation is less than ideal. The audit flags are read by login, ftpd, sshd, and other programs and daemons that do user authentication and set audit characteristics. In each case, a failure to parse results in no error message and no audit flags being set. If an administrator is curious why no audit records are being generated, running "auditconfig -chkaconf" or " -chkconf", will generate an error message. For the new flags the consistent solution would be to return an error in the case of auditconfig and to default to "no additional filtering" in the case of auditd. The specification of audit directories for file output is validated not by auditconfig but by auditd, which outputs an error message to stderr if audit_control is missing and calls audit_warn() in the case of a parsing error. However auditd does not validate the listed directories -- it leaves that to its logic for finding available log space and later will output warnings via audit_warn. It would be more friendly if audit(1M) were to validate the directory parameters before signalling auditd to read audit_control. Since this "friendly" approach doesn't cover the case of boot time, the current auditd validation and error handling should be retained as well. Validation of the loghost and the existence of the associated plug in likewise should be done in two places -- in auditd to cover boot time reading of the audit_control and in audit prior to signalling auditd. gw-4 Why is adt_xmludp.so unstable? Perhaps its output format is evolving and content unstable? Tony adt_xmludp.so is Contracted private, but this applies primarily to its API. I'll correct the specification to make this consistent with the 20 Questions. However the output of the plug-in is the output of auditd and needs to be stated; since you've suggested that audit.log is the right place for a description of the log format, audit.log seems to be the right place for the taxonomy statement.. gw-5 What happens with the syslog records if the loghost is not a Solaris syslogd? Will they still have the same (after syslogd processing) format? Tony If the syslogd implementation is consistent with BSM syslog as described in RFC3164, the data as recorded will be parsable with the same tool (auditreduce) as with Solaris' syslogd. Tests with the Linux syslogd show that the "standard extension" of following the standard header with a "[...]" section is correctly represented even though Linux syslog calls don't generate this section. No tests have been done with other than the Linux and Solaris implementations. gw-6 In order to take into account a potential (future) ability to have multiple loghost: lines, please find a way to specify the exclude flags relative to the loghost line or plug-in filter. Tony OK. gw-7 For commitment when the SPI is described, will there be a way to associate a 3rd party plug-in other than through the loghost: line? If not, it may be misnamed. Tony Assuming you mean "loghost" by "it", I think you mean that the SPI is to be used for a plug-in but there is no remote host to define. I'm open to different names -- any suggestions? For now my preference is to document the use of this configuration line. In the case I think you're describing, the loghost name will be passed to the plug-in, which is free to ignore it. However, gw-3 leads me to think the audit command should validate that loghost, so at a minimum I need to specify a way to say "ignore." gw-8 Need to document the loghost: library such that it is either an explicit path, or the path prefix is implied. As auditd is presently 32 bit, perhaps a syntax like pam.conf $ISA may make sense if auditd would ever become 64 bit. Tony OK. From sacadmin Tue Oct 22 14:04:37 2002 Date: Tue, 22 Oct 2002 15:00:20 -0600 From: Andy Rudoff X-Accept-Language: en MIME-Version: 1.0 To: psarc-record@sac.eng.sun.com Subject: Re: meeting notes: PSARC 2002/150 issue concerning syslog Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3440 for the record... -andy Tony Panero wrote: > > I didn't take notes since I listen better without a pen in my hand. > Please let me know if this summary misses any important details. > > There were two positions stated which were not resolved. The PSARC > position was primarily articulated by Mike, and was an amplification > of what was originally voiced by Andy R and Jim: > > Syslog is not the place for machine parsable data in Solaris. > > Allowing one project to use syslog for remote logging puts > PSARC in a poor position for arguing against this use in other > projects and encourages more customer requests for this sort > of data in syslog and more customer complaints when their > syslog parsers break. > > There is no Solaris strategy or plan for remote log facilities > that meet the Solaris goals of structured logs for machine > parsable data. > > The project team agrees that syslog is a non-optimal solution to remote > logging but has funding and priority based on a syslog solution, so the > PSARC-suggested routes to resolution that don't result in syslog > messages, while consistent with PSARC's view of how logs should be > built and consistent with the project team's preference for reliable > and secure transport, don't appear to provide a reason for the project > to continue. > > Mike also said that the need for remote logging with structured logs > is coming for other projects and expressed a hope that the remote > audit project would make a proposal that would cover these projects as > well. He also recommended we redo our research into alternatives with > the hope we will come up with a different answer next time; he also > recommended getting significant marketing support to talk to customers > about non-syslog solutions to the problem of remote logging. A new > line of investigation that was suggested, albeit with lukewarm > enthusiasm, was SIM/WBEM. The latter suggestion was to discuss with > the relevant team the idea of using SIM/WBEM to be the structured log > transport. > > I think the result of our discussion of nsyslog and Secure Syslog was > mixed; nsyslog was viewed as just another way of doing syslog while > Secure Syslog somehow was deemed worth revisiting. I have no > intention of doing so since it is still syslog in the sense that it > carries "interesting" events intended for human viewing and appears to > be a blind alley in that it mets neither PSARC's nor the customers' > goals. > > We also discussed the idea (Jim) that we would limit the syslog > solution to non-Solaris destinations and the idea (Mike) that we would > create a simple audit channel carrying XML data and would provide > sample code (Perl?) to assist customers with receiving and possibly > parsing the data stream. This later idea is essentially our original > project proposal except that we would have shipped binary data to be > optionally translated to XML offline. > > The project team is presently investigating ideas that would recast > the project to meet other Hardened Solaris Program goals (i.e., "get > funded") and preserve the basic architecture (i.e., a pluggable auditd > interface) that we feel is needed for a series of audit projects, > including remote logs and a better interface to IDS products. > > Tony > -_-_-_-_-_- > Tony Panero > 650 786-0984 / x 80984 / MPK17-301, office 3345 From sacadmin Thu Oct 31 18:15:49 2002 Date: Thu, 31 Oct 2002 18:10:24 -0800 (PST) From: Gary Winiger To: psarc-record@sac.eng.sun.com Subject: Re: PSARC 2002/150: remote audit Cc: tony.panero@sun.com, gww@marduk.eng.sun.com Content-Length: 161 This is an edited record the offline discussion and result of issues raised and not resolved at the inception review. Gary.. ----- Begin Included Message ----- From Tony.Panero@eng.sun.com Wed Oct 9 13:45:28 2002 Date: Wed, 9 Oct 2002 13:45:54 -0700 (PDT) From: Tony Panero Subject: meeting request: PSARC 2002/150 issue concerning syslog To: andy.rudoff@sun.com, joseph.kowalski@sun.com, paul.sangster@sun.com, gary.winiger@sun.com, scott.rotondo@sun.com, michael.shapiro@sun.com, james.d.carlson@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com Cc: ralph.campbell@sun.com Content-Length: 2541 In the inception review for PSARC 2002/150, "Secure Remote Audit Log," the issue of whether syslog is the appropriate transport for Solaris audit data; I was directed to collect an appropriate group of people to discuss this issue and you're one of them. Please let me know of your availability (or disinterest) for a 10am meeting on Tuesday, Oct 22. If you have a conflict, please let me know when in that week would be good. I'd expect the meeting to take at least one hour. The issue arises from trying to meet two seemingly unrelated requirements: First, we want to provide a mechanism for storing audit data in a location remote from its generation. The present audit mechanism writes logs to (possibly NFS mounted) local files which can be deleted or altered by an attacker who successfully compromises the system. With a remote logging mechanism, once collected, this data would be safe from the attacker. Second, our customers want us to provide audit data in text form over syslog. They want text since they have experience parsing text and don't want to write tools to parse our proprietary binary log. They want syslog because it is the only existing log solution that covers heterogenous systems including not only various computing platforms but firewalls and routers. The customers providing these requirements say they understand the limitations of UDP and are used to dealing with the network issues necessary to handle reasonable volumes of data. Clearly, the second requirement[1] limits the security associated with the first and this lack of communications security generated some grumbles from the PSARC members, but the key issue from PSARC is our intent to provide yet another "parse it yourself" syslog use when we as a company are trying to move toward structured logs as supported by libexacct. Between now and the meeting I'll bone up on libexacct and will explore various options that might meet the two primary requirements. I'll publish my notes prior to the meeting. Andy & Joe: If I missed the point on any of this, a correction would be appreciated. Thanks, Tony [1] In the discussions leading up to our plan to generate audit data over syslog, it became clear that the customer requirement is "syslog" and not "give me an interoperable, text solution." A requirement like that doesn't appear to provide a lot of wiggle room. -_-_-_-_-_- Tony Panero 650 786-0984 / x 80984 / MPK17-301, office 3345 ----- End Included Message ----- ----- Begin Included Message ----- From carlsonj@phorcys.east.sun.com Thu Oct 10 07:20:00 2002 Content-Transfer-Encoding: 7bit Date: Thu, 10 Oct 2002 10:20:22 -0400 From: James Carlson To: Tony Panero Cc: andy.rudoff@sun.com, joseph.kowalski@sun.com, paul.sangster@sun.com, gary.winiger@sun.com, scott.rotondo@sun.com, michael.shapiro@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com Subject: Re: meeting request: PSARC 2002/150 issue concerning syslog Content-Length: 6541 Tony Panero writes: > discuss this issue and you're one of them. Please let me know of your > availability (or disinterest) for a 10am meeting on Tuesday, Oct 22. I can do that. > The issue arises from trying to meet two seemingly unrelated > requirements: [...] > compromises the system. With a remote logging mechanism, once > collected, this data would be safe from the attacker. That's only moderately true: an attacker merely needs to (a) disrupt the insecure log delivery mechanism or (b) compromise the log host. Given that the attacker in question has already broken into a Solaris system, I'd expect that NT log host to be a cakewalk. None of this, though, is the real point. [...] > Clearly, the second requirement[1] limits the security associated > with the first and this lack of communications security generated some > grumbles from the PSARC members, but the key issue from PSARC is our > intent to provide yet another "parse it yourself" syslog use when we > as a company are trying to move toward structured logs as supported by > libexacct. This is the crux of the matter. I have great sympathy for the interoperability argument -- I am in networking, after all -- but, regardless of what customers might believe about syslog, I cannot live with dumping programmatic data here as the defined interface. This is wrong for several reasons: - it sets a very poor precedent for future cases; it will leave the ARC less able to reject inappropriate uses of syslog in the future. - it implictly tells customers that Sun thinks it's perfectly appropriate to parse syslog messages. - it puts illegible junk into a log file that is intended to be read by humans (or, at least, system administrators). - it may well end up requiring additional hacks to support the verbose nature of the source material. However, reading through the materials yet again, I think it's possible that I might have misunderstood a key point of what is intended here. Do you plan to write any XML messages via the local syslog(3C) interface in any case at all? Will these appear in any Solaris log file? This is what concerns me most. If not, and if the plan is to put together these XML messages over UDP to some foreign system without ever going through the local syslogd, then I'd be willing to accept this *provided that* appropriate warnings about the kludgy nature of the syslog beast are provided to anyone who might be tempted to use the 'feature,' and that a better (preferably standards- compliant) transport is available for use between Solaris hosts. The warnings would have to include these elements: - syslog isn't secure (for any value of 'secure'). - syslog isn't reliable. - log messages are unstable, and parsing them is foolish. I'm not wild about having some random utility issuing syslog-format messages over UDP without going through /etc/syslog.conf (thus duplicating existing duplicating syslogd functionality), but the resolution for that is SC advice fodder, not a technical change. What I think might have confused me here was the addition of the previously-unused 'audit' facility code as part of this case, and the references to /dev/log and syslogd. This makes it sound as though the intended configuration involves two Solaris hosts, one running the auditing code, and the other running a log server. If that's the only off-machine logging mechanism available for our own systems, then it appears to me that it's not being done for any explained interoperability reasons, and I'd have to consider voting to reject. (Traversing misconfigured firewalls doesn't hold water with me.) [As for the 'which reliable syslog standard should we follow?' controversy that popped up during review, I think the answer should be that we pick one that we think is right, and we run with it and champion it until some customers tell us that we're idiots and we then replace it. To do otherwise is to be perpetually far behind the competition and (worse) allows the competition to pick our technical direction for us. Just my $0.02.] > [1] In the discussions leading up to our plan to generate audit data > over syslog, it became clear that the customer requirement is "syslog" > and not "give me an interoperable, text solution." A requirement like > that doesn't appear to provide a lot of wiggle room. Here is an additional hack-around that I'd be willing to live with: You write plain English messages to syslog(3C). You place internal constraints on your own project such that you make sure you don't change the format of these messages. You document the message formats as an Unstable interface (with appropriate warnings about the bogosity of parsing log messages) for customers. You then write some example utility that reads in the English messages, grovels through them, and spits out XML or whatever data your auditing system needs. Customers are free to use the '@server' feature of syslog.conf to forward the messages as desired. As you can probably tell, my primary objection here is with the use of XML in debug log messages. I think it's deeply wrong. Not only is it as incomprehensible to the user as a Java traceback[1], but it looks to a customer as though you might be able to depend on it, and that's not the case. One other mechanism, which obviously won't fit the somewhat bizarre customer constraint that the transport of choice must be syslog, would be to open an HTTP or HTTP+TLS ('https') connection to the log host and do a POST option with a configured URL. You can then spew XML or any other odd data format without worries. I believe that'd be just as interoperable (is there really somebody out there who doesn't support web traffic?), far more reliable and secure (modulo the possible use of IIS on the log host), and would avoid the hassles of format conversions and inevitable interpolation of missing data. [1] - No, I'm really not singling out Java for abuse here. This is just a good, clear, common example of an error/debug message that a user can do nothing about. It's just baffling rather than being helpful. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 ----- End Included Message ----- ----- Begin Included Message ----- From Tony.Panero@eng.sun.com Thu Oct 10 08:37:23 2002 Date: Thu, 10 Oct 2002 08:37:46 -0700 (PDT) From: Tony Panero Subject: Re: meeting request: PSARC 2002/150 issue concerning syslog To: james.d.carlson@east.sun.com Cc: andy.rudoff@sun.com, joseph.kowalski@sun.com, paul.sangster@sun.com, gary.winiger@sun.com, scott.rotondo@sun.com, michael.shapiro@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com Content-Length: 1874 Jim, I'll defer discussion 'till later, but I think two answers and one question are called for. [...] > ... Do you plan to write any XML messages via the local > syslog(3C) interface in any case at all? Will these appear in any > Solaris log file? This is what concerns me most. If not, and if the > plan is to put together these XML messages over UDP to some foreign > system without ever going through the local syslogd, then I'd be > willing to accept this *provided that* appropriate warnings about the > kludgy nature of the syslog beast are provided to anyone who might be > tempted to use the 'feature,' and that a better (preferably standards- > compliant) transport is available for use between Solaris hosts. libxmludp.so writes UPD messages and does not call syslog(). Would you extend this case to require that we also release the "better" solution at the same time? [...] > What I think might have confused me here was the addition of the > previously-unused 'audit' facility code as part of this case, and the > references to /dev/log and syslogd. This makes it sound as though the > intended configuration involves two Solaris hosts, one running the > auditing code, and the other running a log server. If that's the only > off-machine logging mechanism available for our own systems, then it > appears to me that it's not being done for any explained > interoperability reasons, and I'd have to consider voting to reject. > (Traversing misconfigured firewalls doesn't hold water with me.) LOG_AUDIT is necessary on the syslog server to allow its syslog.conf to decide what to do with the incoming audit messages. However, you've repeated the first requirement I listed, which is off-machine logging and which is not being done for interoperability reasons. [...] Tony ----- End Included Message ----- ----- Begin Included Message ----- From carlsonj@phorcys.east.sun.com Thu Oct 10 09:48:23 2002 Content-Transfer-Encoding: 7bit Date: Thu, 10 Oct 2002 12:48:47 -0400 From: James Carlson To: Tony Panero Cc: andy.rudoff@sun.com, joseph.kowalski@sun.com, paul.sangster@sun.com, gary.winiger@sun.com, scott.rotondo@sun.com, michael.shapiro@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com Subject: Re: meeting request: PSARC 2002/150 issue concerning syslog Content-Length: 2376 Tony Panero writes: > I'll defer discussion 'till later, but I think two answers and one > question are called for. OK. > > ... Do you plan to write any XML messages via the local > > syslog(3C) interface in any case at all? Will these appear in any > > Solaris log file? This is what concerns me most. If not, and if the > > plan is to put together these XML messages over UDP to some foreign > > system without ever going through the local syslogd, then I'd be > > willing to accept this *provided that* appropriate warnings about the > > kludgy nature of the syslog beast are provided to anyone who might be > > tempted to use the 'feature,' and that a better (preferably standards- > > compliant) transport is available for use between Solaris hosts. > > libxmludp.so writes UPD messages and does not call syslog(). Would you > extend this case to require that we also release the "better" solution > at the same time? If it's intended to be used between Solaris systems at all, yes. The argument that this is for compatibility with foreign systems that have *no* decent alternative is the only one that I think is valid. What I do not want to see is this mechanism become the "good enough" solution for transferring audit data between Solaris systems that essentially prevents us from eventually doing the right thing, and I'm willing to say 'no' in an effort to prevent that. > LOG_AUDIT is necessary on the syslog server to allow its syslog.conf to > decide what to do with the incoming audit messages. However, you've > repeated the first requirement I listed, which is off-machine logging > and which is not being done for interoperability reasons. Er ... that doesn't quite work for me. Defining 'audit' within /etc/syslog.conf implies that we have one Solaris system transferring log records to another via XML over syslog. That's the case that I don't believe is acceptable. I agree that adding 'audit' (and anything else missing from the RFC) to our current syslogd implementation is a good thing, but not as a crutch for a missing *Solaris* feature. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 ----- End Included Message ----- ----- Begin Included Message ----- From Tony.Panero@eng.sun.com Tue Oct 22 13:18:21 2002 Date: Tue, 22 Oct 2002 13:18:51 -0700 (PDT) From: Tony Panero Subject: meeting notes: PSARC 2002/150 issue concerning syslog To: andy.rudoff@sun.com, james.d.carlson@sun.com, joseph.kowalski@sun.com, paul.sangster@sun.com, gary.winiger@sun.com, scott.rotondo@sun.com, michael.shapiro@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com Cc: ric.aleshire@sun.com, karsten.beins@sun.com Content-Length: 3277 I didn't take notes since I listen better without a pen in my hand. Please let me know if this summary misses any important details. There were two positions stated which were not resolved. The PSARC position was primarily articulated by Mike, and was an amplification of what was originally voiced by Andy R and Jim: Syslog is not the place for machine parsable data in Solaris. Allowing one project to use syslog for remote logging puts PSARC in a poor position for arguing against this use in other projects and encourages more customer requests for this sort of data in syslog and more customer complaints when their syslog parsers break. There is no Solaris strategy or plan for remote log facilities that meet the Solaris goals of structured logs for machine parsable data. The project team agrees that syslog is a non-optimal solution to remote logging but has funding and priority based on a syslog solution, so the PSARC-suggested routes to resolution that don't result in syslog messages, while consistent with PSARC's view of how logs should be built and consistent with the project team's preference for reliable and secure transport, don't appear to provide a reason for the project to continue. Mike also said that the need for remote logging with structured logs is coming for other projects and expressed a hope that the remote audit project would make a proposal that would cover these projects as well. He also recommended we redo our research into alternatives with the hope we will come up with a different answer next time; he also recommended getting significant marketing support to talk to customers about non-syslog solutions to the problem of remote logging. A new line of investigation that was suggested, albeit with lukewarm enthusiasm, was SIM/WBEM. The latter suggestion was to discuss with the relevant team the idea of using SIM/WBEM to be the structured log transport. I think the result of our discussion of nsyslog and Secure Syslog was mixed; nsyslog was viewed as just another way of doing syslog while Secure Syslog somehow was deemed worth revisiting. I have no intention of doing so since it is still syslog in the sense that it carries "interesting" events intended for human viewing and appears to be a blind alley in that it mets neither PSARC's nor the customers' goals. We also discussed the idea (Jim) that we would limit the syslog solution to non-Solaris destinations and the idea (Mike) that we would create a simple audit channel carrying XML data and would provide sample code (Perl?) to assist customers with receiving and possibly parsing the data stream. This later idea is essentially our original project proposal except that we would have shipped binary data to be optionally translated to XML offline. The project team is presently investigating ideas that would recast the project to meet other Hardened Solaris Program goals (i.e., "get funded") and preserve the basic architecture (i.e., a pluggable auditd interface) that we feel is needed for a series of audit projects, including remote logs and a better interface to IDS products. Tony -_-_-_-_-_- Tony Panero 650 786-0984 / x 80984 / MPK17-301, office 3345 ----- End Included Message ----- ----- Begin Included Message ----- From Tony.Panero@eng.sun.com Mon Oct 28 08:26:19 2002 Date: Mon, 28 Oct 2002 08:26:51 -0800 (PST) From: Tony Panero Subject: PSARC 2002/150: remote audit To: michael.shapiro@sun.com, james.d.carlson@sun.com, andy.rudoff@sun.com, joseph.kowalski@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com Cc: paul.sangster@sun.com, scott.rotondo@sun.com, ric.aleshire@sun.com, gary.winiger@sun.com Content-Length: 2745 After a bit of wrestling with which project goals are essential, we came up with a plan that we think meets both ONSC and PSARC requirements. What we propose is an enhancement to Solaris audit that meets the customer requests for audit data via syslog but also stays close to the expected use of syslog. Looking at syslog messages generated from our kernel as a model, it became clear that the definition of "English" is loose enough to be easily achieved (syslog header removed): se0 at ebus0: offset 14,400000 se0 is /pci@1f,4000/ebus@1/se@14,400000 pseudo-device: pm0 pm0 is /pseudo/pm@0 audiocs0 at ebus0: offset 14,200000 audiocs0 is /pci@1f,4000/ebus@1/SUNW,CS4231@14,200000 fd0 at ebus0: offset 14,3023f0 fd0 is /pci@1f,4000/ebus@1/fdthree@14,3023f0 pseudo-device: vol0 vol0 is /pseudo/vol@0 For audit messages, I propose we generate audit info syslog messages such as these (syslog header removed) chdir(2) ok obj /home/tpanero by tpanero as root from nishiki system booted login - rlogin ok by tpanero as tpanero from nishiki setaudit(2) ok by paf as root from elbow admin login fail by scottm as scottm from neutron access(2) ok obj /export/home/testsuites/tfile by paf as adm from 129.146.89.30 The syslog header for the above would be standard: Oct 22 09:37:26 ebi audit: [ID 686697.1 audit.info] For those of you familiar with audit records, the above messages would be constructed by selecting specific fields from specific tokens independent of how a particular audit record is structured. The ID field provides the key for referencing to the full audit log if added data is needed. In addition, the generation of these messages would be via filters defined separately from the standard audit class/event "preselection" mechanism to allow the customer to decide what are interesting events. Examples of the selection choices would be listing specific audit events, event classes, and pass or fail. I think this meets the spirit of syslog messages -- aimed at people, only incidentally parsable, and intended to convey the essentials of an event of interest. What we give up compared to our original proposal is the ability to reproduce in syslog the audit trail and substantial amounts of data normally carried in audit records; there would be no changes to the existing audit utilities used for filtering, merging, and displaying audit data since this pared down data cannot be reformatted into audit records. However we will implement the structure necessary to support a secure and reliable mechanism as a followup project. Whether that is a simple "audit channel" or a new Sun standard for remote logging is a future discussion. Tony ----- End Included Message ----- ----- Begin Included Message ----- From carlsonj@phorcys.east.sun.com Thu Oct 31 03:05:40 2002 Content-Transfer-Encoding: 7bit Date: Thu, 31 Oct 2002 06:06:32 -0500 From: James Carlson To: Tony Panero Cc: michael.shapiro@sun.com, andy.rudoff@sun.com, joseph.kowalski@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com, paul.sangster@sun.com, scott.rotondo@sun.com, ric.aleshire@sun.com, gary.winiger@sun.com Subject: Re: PSARC 2002/150: remote audit Content-Length: 2291 Tony Panero writes: > For audit messages, I propose we generate audit info syslog messages > such as these (syslog header removed) > > chdir(2) ok obj /home/tpanero by tpanero as root from nishiki > system booted > login - rlogin ok by tpanero as tpanero from nishiki > setaudit(2) ok by paf as root from elbow admin > login fail by scottm as scottm from neutron > access(2) ok obj /export/home/testsuites/tfile by paf as adm from 129.146.89.30 Those look fine to me. > In addition, the generation of these messages would be via filters > defined separately from the standard audit class/event "preselection" > mechanism to allow the customer to decide what are interesting events. > Examples of the selection choices would be listing specific audit > events, event classes, and pass or fail. I would also recommend just calling syslog(3C) or logger(1) rather than constructing UDP messages with syslog-format data in them. This would allow the customer to use the standard system configuration to control how and where the messages are delivered. > I think this meets the spirit of syslog messages -- aimed at people, > only incidentally parsable, and intended to convey the essentials of an > event of interest. Yes. > What we give up compared to our original proposal is the ability to > reproduce in syslog the audit trail and substantial amounts of data > normally carried in audit records; there would be no changes to the > existing audit utilities used for filtering, merging, and displaying > audit data since this pared down data cannot be reformatted into audit > records. However we will implement the structure necessary to support a > secure and reliable mechanism as a followup project. Whether that is a > simple "audit channel" or a new Sun standard for remote logging is a > future discussion. That sounds very much like the right path to me. This takes care of my concern that this mechanism would be used as a solution to a missing Solaris feature. Thanks! -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 ----- End Included Message ----- ----- Begin Included Message ----- From mws@poptart.eng.sun.com Thu Oct 31 10:39:52 2002 From: Michael Shapiro Subject: Re: PSARC 2002/150: remote audit To: Tony.Panero@eng.sun.com Date: Thu, 31 Oct 2002 10:40:59 -0800 (PST) Cc: michael.shapiro@sun.com, james.d.carlson@sun.com, andy.rudoff@sun.com, joseph.kowalski@sun.com, stephen.hahn@sun.com, andrew.tucker@sun.com, ralph.campbell@sun.com, paul.sangster@sun.com, scott.rotondo@sun.com, ric.aleshire@sun.com, gary.winiger@sun.com Content-Transfer-Encoding: 7bit Content-Length: 477 > After a bit of wrestling with which project goals are essential, we > came up with a plan that we think meets both ONSC and PSARC > requirements. What we propose is an enhancement to Solaris audit that > meets the customer requests for audit data via syslog but also stays > close to the expected use of syslog. > > [ ... ] Tony, Sounds like a decent short-term compromise to me. -Mike -- Mike Shapiro, Solaris Kernel Development. ----- End Included Message ----- From sacadmin Wed Nov 27 10:40:39 2002 Date: Wed, 27 Nov 2002 10:38:49 -0800 (PST) From: Gary Winiger To: psarc-members@sac.eng.sun.com Subject: Materials for 2002/150 Secure Remote Audit Log Cc: tony.panero@sun.com Content-Length: 835 The hard copy materials that I got yesterday included a getacinfo(3BSM) man page. This is not in the case materials directory and is not part of the case. RFC 3164, "The BSD syslog Protocol," similarly is not part of the case, and didn't need to be printed. It is reference material for those who may wish it. The section "Audit Changes For Solaris 10" is also informational. It represents the input to Tech Pubs for documentation changes. Committee suggestions here are gladly accepted. A suggested reading order might be: 20 Questions -- 20questions.txt Secure Remote Audit Log Specification -- specification.txt or .html inception issues -- incept_issues.txt Audit Changes For Solaris 10 -- informational -- adminDocInput.txt or .html man pages (except getacinfo) in any order desired Happy reviewing, Gary.. From sacadmin Wed Jan 22 11:39:01 2003 Date: Wed, 22 Jan 2003 11:37:13 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com Subject: Opinion for review: 2002/150 Secure Remote Audit Log Cc: tony.panero@sun.com Content-Length: 13663 Attached is the opinion for review. As a number of things needed to be updated in the spec following the vote, I've summarized the spec updates as well. While the updates may seem large, IMO, they largely represent the details presented at the review. IMO the spec now is in sync with the details already presented. The one exception is the addition of the audit_warn(1M) script to send messages of plugin failures to administrators. This also resulted in another return value for the interfaces in the plugin library to be able to send plugin specific messages to audit_warn. I'm setting that the review period at two weeks rather than the usual one to allow for those who wish to check the details to do so. Please review by 5 Feb 2003. For your viewing pleasure a PDF of the opinion is in the case directory. Thanks, Gary.. ======================== Spec Change Summary ======================= Renamed audit_sysudp(5) to audit_syslog(5) and updated to reflect the changes relative to audit_control(4) key=value syntax. Added -v option to audit(1M) to check the syntax an audit control file without trying to use it. Added new plugin audit_binfile(5) with an Evolving stability which implements the present binary audit trail. Changed the audit_control(4) plugin: syntax to be key-value pair with "=" as the key-value separator and ";" as the key-value pair separator. Extended the syntax to process multiple lines with "\" as a new line escape. The key name space starting with "p_" is reserved for plugin options. All other key names are for use by auditd(1M). Defined "name," the shared object path and "qsize," the maximum number of audit records to queue up waiting for audit_plugin() return before not accepting any more audit records from the kernel. (See auditconfig(1M) below.) Clarified the auditconfig(1M) "queue high water mark" and count policy defaults. The queue high water mark is used as the default queue size for the audit plugins when the qsize key word is not specified. Added new function "plugin" to audit_warn(1M) to report plugin problems to the audit administrator. The stability of audit_warn(1M) remains Evolving. By default, messages returned from the plugins are included in the report. The "plugin" function takes parameters which specify the plugin name, what type of error the plugin returned, and optional descriptive text string from the plugin. Changed the wording in syslog(3C) and syslog.conf(4) as requested from "Reserved for" to "Designated for". Removed internal words from /usr/include/security/auditd.h and added AUDITD_RETRY return code from auditd_plugin(3BSM) and updated the function signatures. Added prototype contract for audit_plugin(3BSM). Updated audit_plugin(3BSM): audit_plugin_open() now takes a typedef struct kva_s { } kva_t from which to gather its arguments with kva_match(3SECDB) (rather than char *argv[], int argc). It returns a list of key-value pairs to describe various functions to auditd. The present keys and values are "buftype=unpacked | packed". A packed buffer may contain multiple audit records for processing in a single call to audit_plugin(). An unpacked buffer contains only one audit record. It also may return a text string further describing an error return code. The effects of audit -s, -n, and -t are described: -s, which rereads audit_control(4) calls the audit_plugin_open() routines of each plugin with the current kva_list. -n, only effects the Solaris provided audit_binfile plugin. -t, drains the audit queue for each plugin and calls audit_plugin_close() after the queue is drained. auditd(1M) exist after all the plug ins have been closed. audit_plugin() may return a new code, AUDITD_RETRY, to indicate a temporary condition and the need to call it again with the same parameters. auditd will retry every 20 seconds. This is not configurable. The project team provided the following reasoning: 20 seconds is the currently unconfigurable sleep time when polling for corrective administrative action. There appears to be no reason for change. 20 seconds was chosen to minimize processing cost and still provide reasonably quick response to an administrator's correction of the underlying condition. ======================== Opinion for Review ======================= sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Secure Remote Audit Log Submitted by: Tony Panero File: PSARC/2002/150/opinion.ms Date: December 4th, 2002 Committee: Ralph Campbell (opinion written by Gary Winiger), James Carlson, Joseph Kowalski, Terrence Miller, Andy Tucker. Steering Committee: Solaris Operating Environment Steering Com- mittee soesc-prodteam@sun.com Operating Systems and Networking Steering Committee onsc@sun.com 1. Summary The project name reflects the original intent of the project and is a misnomer of the project approved. A more appropri- ate name would not include "secure." This project provides a mechanism to send binary audit data to an alternate and / or secondary destination. The current audit mechanism only allows recording the binary audit data in a file. The alternate or secondary destination is pro- vided for by a plug in to the audit mechanism. This project provides a plug in which sends the binary audit data to a file and one which formats the binary audit data as human readable syslog messages and forwards them to syslog(3C) as audit.info messages. Additionally it defines the LOG_AUDIT facility for Solaris to correspond with the audit facility defined in RFC 3164 [1]. The structure of this project is such that additional plug ins could be supported by a future project. 2. Decision & Precedence Information The project is approved as specified in reference [2]. The project may be delivered in a micro or patch release of Solaris. PSARC/2002/150 Copyright 2002 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |__________________|_________________|____________________| |Interface | Classification | Comments | |__________________|_________________|____________________| |audit(1M) | Evolving | | |auditd(1M) | Evolving | | |audit_warn(1M) | Evolving | new "plugin" | | | | subcommand | |audit_plugin(3BSM)| Contracted Pro-| auditd(1M) SPI | | | ject Private | interface | |audit_binfile(5) | Evolving | auditd(1M) plug | | | | in to implement | | | | the current | | | | binary audit | | | | trail | |audit_syslog(5) | Evolving | auditd(1M) plug | | | | in to write | | | | syslog messages | |audit_control(4) | Evolving | new keywords | |auditd.h | Contracted Pro-| audit_plugin(3BSM)| | | ject Private | header | |__________________|_________________|____________________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |__________________|_________________|__________________| |Interface | Classification | Comments | |__________________|_________________|__________________| |auditsvc(2) | Project Private| PSARC/2002/665 | |audit_plugin(3BSM)| Contracted Pro-| Defined by this | | | ject Private | project and | | | | used to imple- | | | | ment | | | | audit_syslog(5) | | | | and | | | | audit_binfile(5)| |audit_control(4) | Evolving | defines which | | | | audit paths are | | | | active | |syslog(3C) | Standard | | |__________________|_________________|__________________| 4. Opinion PSARC/2002/150 Copyright 2002 Sun Microsystems - 3 - 4.1. Not Secure When this project was initially submitted, it intended to use a secure remote logging protocol. The project could not find an acceptable standard one. It is beyond the scope of the project to create one. Some committee members felt Sun should take a leadership role in defining such a protocol. This lead to steering committee advice. Customers requested audit information be available through the syslog protocol. The project investigated the various proposals for "secure" syslog and found a lack of focus and movement toward con- sensus. Combining the customer request for syslog and the goal of remote audit log lead to the project as presented. 4.2. Structured syslog Messages The project proposed to use the syslog protocol [1] to directly write structured audit trail data to remote host formatted as XML compatible with PSARC/2002/377 "Audit Trail Translation to XML." The committee found two major faults with this approach: The direct formatting and transmission over UDP of syslog protocol messages. The precedence of creating structured stable data in syslog. The committee felt strongly that even to imply stability for one class of syslog messages would lead to customer calls for stability of all Sun syslog messages. The project removed its use of XML and created human readable syslog message that extract some significant parts of the audit trail data. 4.3. auditsvc(2) and audit_plugin(3BSM) This project prompted PSARC/2002/665 which reclassified auditsvc(2) as project private. Some committee members express concern that the customer(s) who may be using auditsvc would have their applications break. The project team pointed out that PSARC/2002/665 only reclassified auditsvc and that neither project will actually change the implementation in an incompatible way. auditsvc will be announced to be project private in the next micro release and its documentation removed in the next minor release. The known customer(s) reluctantly use auditsvc because there has been no alternative to capture the audit data in real- time for analysis. Use of auditsvc requires replacing auditd(1M). Such replacement is not supported by Sun. This project introduces audit_plugin which is intended to replace the need for customer use of auditsvc with a more efficient and stable interface. Because audit_plugin is a new inter- face, it is being classified as contracted project private. The project intends to offer contracts [3] to use the audit_plugin interfaces to the known auditsvc users. Once audit_plugin is proven it can be promoted to a public inter- face. PSARC/2002/150 Copyright 2002 Sun Microsystems - 4 - 4.4. auditconfig(1M) not getopt(3C) Compliant A committee member expressed concern with the lack of con- formance by auditconfig(1M) with getopt(3C). This project does not modify this command it only added notes to the man page. The command syntax is as it was when integrated in 1992. No ARC case can be found for the audit mechanism integrations. 4.5. syslog.conf(4) Poorly Worded A committee member express concern with the use of the word "reserved" in the syslog.conf man page. This project has added new information in a similar syntax to the existing man page. The committee member's concern would have lead to a TCA to reword syslog.conf(4). Instead, the project updated the specification. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Need for Secure Remote Logging of Structured Data Pro- tocol During the investigation of this project a void was uncovered that Sun could choose to take a leadership role in filling. Specifically, no standard secure protocols were identified for remote logging much less remote logging of structured data. The steering committees are advised to fund a project to create a secure remote logging protocol standard that may be used for recording structured data. Such data might include fault events as well as system level audit data. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2002/150. 1. RFC 3164, The BSD syslog Protocol PSARC/2002/150 Copyright 2002 Sun Microsystems - 5 - File: final.materials/rfc3164.txt 2. Final Specification File: final.materials/* 3. Prototype Contract File: final.materials/contract.proto PSARC/2002/150 Copyright 2002 Sun Microsystems From sacadmin Thu Feb 6 11:16:58 2003 Date: Thu, 6 Feb 2003 11:14:46 -0800 (PST) From: Gary Winiger To: sac-review@sac.eng.sun.com Subject: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Content-Length: 9727 Please review by 13 Feb 2003. There's a PDF in the case directory for your viewing pleasure. Thanks, Gary.. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Secure Remote Audit Log Submitted by: Tony Panero File: PSARC/2002/150/opinion.ms Date: December 4th, 2002 Committee: Ralph Campbell (opinion written by Gary Winiger), James Carlson, Joseph Kowalski, Terrence Miller, Andy Tucker. Steering Committee: Solaris Operating Environment Steering Com- mittee soesc-prodteam@sun.com Operating Systems and Networking Steering Committee onsc@sun.com 1. Summary The project name reflects the original intent of the project and is a misnomer of the project approved. A more appropri- ate name would not include "secure." This project provides a mechanism to send binary audit data to an alternate and / or secondary destination. The current audit mechanism only allows recording the binary audit data in a file. The alternate or secondary destination is pro- vided for by a plug in to the audit mechanism. This project provides a plug in which sends the binary audit data to a file and one which formats the binary audit data as human readable syslog messages and forwards them to syslog(3C) as audit.info messages. Additionally, it defines the LOG_AUDIT facility for Solaris to correspond with the audit facility defined in RFC 3164 [1]. The structure of this project is such that additional plug ins could be supported by a future project. 2. Decision & Precedence Information The project is approved as specified in reference [2]. The project may be delivered in a micro or patch release of Solaris. PSARC/2002/150 Copyright 2002 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |__________________|_________________|____________________| |Interface | Classification | Comments | |__________________|_________________|____________________| |audit(1M) | Evolving | | |auditd(1M) | Evolving | | |audit_warn(1M) | Evolving | new "plugin" | | | | subcommand | |audit_plugin(3BSM)| Contracted Pro-| auditd(1M) SPI | | | ject Private | interface | |audit_binfile(5) | Evolving | auditd(1M) plug | | | | in to implement | | | | the current | | | | binary audit | | | | trail | |audit_syslog(5) | Evolving | auditd(1M) plug | | | | in to write | | | | syslog messages | |audit_control(4) | Evolving | new keywords | |auditd.h | Contracted Pro-| audit_plugin(3BSM)| | | ject Private | header | |__________________|_________________|____________________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |__________________|_________________|__________________| |Interface | Classification | Comments | |__________________|_________________|__________________| |auditsvc(2) | Project Private| PSARC/2002/665 | |audit_plugin(3BSM)| Contracted Pro-| Defined by this | | | ject Private | project and | | | | used to imple- | | | | ment | | | | audit_syslog(5) | | | | and | | | | audit_binfile(5)| |audit_control(4) | Evolving | defines which | | | | audit paths are | | | | active | |syslog(3C) | Standard | | |__________________|_________________|__________________| 4. Opinion PSARC/2002/150 Copyright 2002 Sun Microsystems - 3 - 4.1. Not Secure When this project was initially submitted, it intended to use a secure remote logging protocol. The project could not find an acceptable standard one. It is beyond the scope of the project to create one. Some committee members felt Sun should take a leadership role in defining such a protocol. This led to steering committee advice. Customers requested audit information be available through the syslog protocol. The project investigated the various proposals for "secure" syslog and found a lack of focus and movement toward con- sensus. Combining the customer request for syslog and the goal of remote audit log led to the project as presented. 4.2. Structured syslog Messages The project proposed to use the syslog protocol [1] to directly write structured audit trail data to remote host formatted as XML compatible with PSARC/2002/377 "Audit Trail Translation to XML." The committee found two major faults with this approach: the direct formatting and transmission over UDP of syslog protocol messages and the precedent of creating structured stable data in syslog. The committee felt strongly that even to imply stability for one class of syslog messages would lead to customer calls for stability of all Sun syslog messages. The project removed its use of XML and created human readable syslog message that extract some significant parts of the audit trail data using syslog(3C). 4.3. auditsvc(2) and audit_plugin(3BSM) This project prompted PSARC/2002/665 "Audit Interface Reclassification," which reclassified auditsvc(2) as Project Private. Some committee members expressed concern that the customer(s) who may be using auditsvc would have their applications break. The project team pointed out that PSARC/2002/665 only reclassified auditsvc and that neither project will actually change the implementation in an incom- patible way. auditsvc will be announced to be Project Private in the next micro release and its documentation removed in the next minor release. The known customer(s) reluctantly use auditsvc because there has been no alternative to capture the audit data in real- time for analysis. Use of auditsvc requires replacing auditd(1M). Such replacement is not supported by Sun. This project introduces audit_plugin(3BSM) which is intended to replace the need for customer use of auditsvc with a more efficient and stable interface. Because audit_plugin is a new interface, it is being classified as Contracted Project Private. The project intends to offer contracts [3] to use the audit_plugin interfaces to the known auditsvc users. Once audit_plugin is proven it can be promoted to a public PSARC/2002/150 Copyright 2002 Sun Microsystems - 4 - interface. 4.4. auditconfig(1M) not getopt(3C) Compliant A committee member expressed concern with the lack of con- formance by auditconfig(1M) with getopt(3C). This project does not modify this command, rather it only adds notes to the man page. The command syntax is as it was when integrated in 1992. No ARC case can be found for the audit mechanism integrations. The committee concluded that it was outside the scope of this project to change the command to be getopt compliant. 4.5. syslog.conf(4) Poorly Worded A committee member expressed concern with the use of the word "reserved" in the syslog.conf(4) man page. This pro- ject has added new information in a similar syntax to the existing man page. The committee member's concern would have led to an advisory change to the project to reword syslog.conf. Instead, the project updated the specifica- tion. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Need for Secure Remote Logging of Structured Data Pro- tocol During the investigation of this project a void was uncovered that Sun could choose to take a leadership role in filling. Specifically, no standard secure protocols were identified for remote logging much less remote logging of structured data. The steering committees are advised to fund a project to create a secure remote logging protocol standard that may be used for recording structured data. Such data might include fault events as well as system level audit data. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. PSARC/2002/150 Copyright 2002 Sun Microsystems - 5 - 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2002/150. 1. RFC 3164, The BSD syslog Protocol File: final.materials/rfc3164.txt 2. Final Specification File: final.materials/* 3. Prototype Contract File: final.materials/contract.proto PSARC/2002/150 Copyright 2002 Sun Microsystems From sacadmin Thu Feb 6 11:36:51 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Feb 2003 14:36:00 -0500 From: James Carlson To: Gary Winiger Cc: sac-review@sac.eng.sun.com Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Content-Length: 1788 Gary Winiger writes: > _________________________________________________________ > | Interfaces Imported | > |__________________|_________________|__________________| > |Interface | Classification | Comments | > |__________________|_________________|__________________| > |auditsvc(2) | Project Private| PSARC/2002/665 | How is a Project Private interface from a different project imported by this case? > |audit_plugin(3BSM)| Contracted Pro-| Defined by this | > | | ject Private | project and | I looked, but couldn't find a signed contract -- just an incomplete prototype. If this case is importing this interface from some other project, then a completed contract is needed. If this case is actually exporting this interface (I *think* it's just changing the stability level and not actually depending on the interface), then it might as well be some form of "private" until there's an actual consumer available. If the consumer is known, then the consumer needs to be identified. If not, then the right stability might be Unstable or Obsolete. > During the investigation of this project a void was > uncovered that Sun could choose to take a leadership role in > filling. Specifically, no standard secure protocols were > identified for remote logging much less remote logging of > structured data. I'd disagree with that. There *are* such standards-track protocols, but none are supported in Solaris today. Sun needs to choose one and back it. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Feb 6 12:20:56 2003 Date: Thu, 6 Feb 2003 12:19:30 -0800 (PST) From: Darren J Moffat To: Gary Winiger cc: Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2412 On Thu, 6 Feb 2003, Gary Winiger wrote: > readable syslog messages and forwards them to syslog(3C) as > audit.info messages. Additionally, it defines the LOG_AUDIT > facility for Solaris to correspond with the audit facility > defined in RFC 3164 [1]. I have a few questions/concerns about this. 1) I think it is good that we are updating our syslog to be closer to RFC3164. However adding just one of the missing facilities seems to be be a disservice. We would still be missing the following facitlies from RFC 3164. 9 clock daemon (note 2) 10 security/authorization messages (note 1) 11 FTP daemon 12 NTP subsystem 14 log alert (note 1) I would like one of two things to happen here. Either advice in the opinion for the relevant PAC to fund a project to bring our syslog implementation up to scratch with RFC 3164 or a TCR on this project to fill-in the missing facilities and log bugs for any other missing RFC 3164 functionality. If this isn't done then I don't think it is fair to use RFC 3164 as a reference and justification for adding LOG_AUDIT. Note also that RFC 3164 does not define the C programming interface and thus LOG_AUDIT, just that facility 13 is "log audit". 2) What happens if a system with this functionality configured starts sending LOG_AUDIT messages to an older release of Solaris ? Do the messages get accepted ? Obviously they can't be configured with audit.info in the older syslog.conf. I think this is a key interoperability issue, with older releases of Solaris and other systems (Red Hat Linux 8.0 does not have LOG_AUTH either). A possible workaround (if this is a problem ) would be to have audit as the default facility and add another argument to audit_syslog(5) that allows specifying the facility. 3) final.materials/audit_syslog.5 says messages are logged at audit.notice. The opinion says audit.info. Which is is it ? Is only one priority level used (audit_syslog(5) only mentions .notice). 4) The summary indicates very clearly that the project is no longer delivering a "secure" remote audit log. What is the ARC practice on chaning the name to reflect what the real content of the project is (rather than because of a marketing name change) ? This is more a question for ARC than a comment on the opinion. -- Darren J Moffat From sacadmin Thu Feb 6 12:37:09 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Feb 2003 15:36:08 -0500 From: James Carlson To: Darren J Moffat Cc: Gary Winiger , Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Content-Length: 2721 Darren J Moffat writes: > I have a few questions/concerns about this. > > 1) I think it is good that we are updating our syslog to be closer > to RFC3164. I certainly wouldn't object if someone did that, but I think it's more than a bit out of scope for this project. > 9 clock daemon (note 2) > 10 security/authorization messages (note 1) > 11 FTP daemon > 12 NTP subsystem > 14 log alert (note 1) Note that adding the FTP daemon or NTP facility codes without bothering to update those utilities to *use* those codes would be a greater disservice to customers. I think that represents substantial mission creep for this project. > If this isn't done then I don't think it is fair to use RFC 3164 as a > reference and justification for adding LOG_AUDIT. I don't understand that. Nobody says that you have to implement _all_ of an RFC if it doesn't make sense for your situation. I certainly agree with filing RFEs or passing along SC advice saying that modernizing syslogd(1M) and syslog(3C) would be a good thing. > 2) What happens if a system with this functionality configured starts sending > LOG_AUDIT messages to an older release of Solaris ? Do the messages get > accepted ? Yes. As long as you have a "*" entry, all facility codes (even unknown ones) are accepted and printed. > Obviously they can't be configured with audit.info in the older > syslog.conf. Right. > 4) The summary indicates very clearly that the project is no longer delivering > a "secure" remote audit log. What is the ARC practice on chaning the name > to reflect what the real content of the project is (rather than because of > a marketing name change) ? This is more a question for ARC than a > comment on the opinion. I'd rather avoid changing the name unless there's a clear reason to do so. The "secure" part of this project is that the log host is a separate system from the one being audited. Obviously, we might well have serious concerns about whether this is really "secure *enough*," but I don't think that's a good rationale for changing the project name. The man pages don't refer to this as a "secure" mechanism, and that's the documentation given to customers. ARC materials are Sun xxxxxxxxxxx and xxxxxxxxxxxx. (I'm pretty sure the issue about the word "secure" in the title came up at one point during review, and the general consensus was, "nah, don't bother.") -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Thu Feb 6 15:44:25 2003 Date: Thu, 6 Feb 2003 15:42:10 -0800 (PST) From: Gary Winiger To: Gary.Winiger@eng.sun.com, Darren.Moffat@Sun.COM Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Cc: sac-review@sac.eng.sun.com Content-Length: 988 Darren, > I have a few questions/concerns about this. Thanks for your comments. > 1) I think it is good that we are updating our syslog to be closer > reference and justification for adding LOG_AUDIT. As Jim said. I believe this is outside the scope of the audit project. Please feel free to initiate a project to make Solaris syslog RFC 3164 compliant. ABICT this project would not impede such a project. > 2) What happens if a system with this functionality configured starts sending Again, I believe Jim has answered this. > 3) final.materials/audit_syslog.5 says messages are logged at audit.notice. > The opinion says audit.info. Which is is it ? Is only one priority level > used (audit_syslog(5) only mentions .notice). Thanks for noticing this. It is audit.notice. I'll correct the opinion before sending to sac-opinion. > 4) The summary indicates very clearly that the project is no longer delivering Yet again, I believe Jim has answered this. Gary.. From sacadmin Thu Feb 6 17:33:23 2003 Date: Thu, 6 Feb 2003 17:31:08 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, james.d.carlson@east.sun.com Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Cc: sac-review@sac.eng.sun.com Content-Length: 4227 Jim, > Gary Winiger writes: Thanks for your prompt response during sac review. I'd hoped that PSARC members would have raised their technical issues during the extended (2 weeks) of psarc review because of spec updates. > > _________________________________________________________ > > | Interfaces Imported | > > |__________________|_________________|__________________| > > |Interface | Classification | Comments | > > |__________________|_________________|__________________| > > |auditsvc(2) | Project Private| PSARC/2002/665 | > > How is a Project Private interface from a different project imported > by this case? This was discussed in the 2002/665 fast track and in remarks during this cases review. auditsvc(2) was improperly exposed outside the "Solaris Audit" project (the present case is a component of the Solaris Audit project). As the Solaris Audit project was introduced into SunOS 5.3 without ARC review, I've been slowly trying to clean up the interfaces as they come to ARC. I guess the point you're making is that a project private interface cannot span multiple ARC cases. This seems odd to me when a project, such as the Solaris Audit project will have multiple ARC cases (as it evolves). As discussed, this case modifies auditd(1M) which consumes auditsvc(2) in such a way as to extend the funcitonality of auditsvc for auditd to import. How do you propose specifying this? The reference to 2002/665 is to clarify the taxonomy of auditsvc which could have been, previously, implied as Stable. > > |audit_plugin(3BSM)| Contracted Pro-| Defined by this | > > | | ject Private | project and | > > I looked, but couldn't find a signed contract -- just an incomplete > prototype. If this case is importing this interface from some other > project, then a completed contract is needed. If this case is It's not, See the line from the Exported interface table as well. |audit_plugin(3BSM)| Contracted Pro-| auditd(1M) SPI | | | ject Private | interface | Would you propose a change there as well and to what? > actually exporting this interface (I *think* it's just changing the > stability level and not actually depending on the interface), then it This case is delivering this interface. It did not exist before and is part of this case. > might as well be some form of "private" until there's an actual > consumer available. If the consumer is known, then the consumer needs > to be identified. If not, then the right stability might be Unstable > or Obsolete. I recall this also being discussed with this case. These interfaces are Project Private with the intent of sharing them with the small set of customers who replace auditd and consume auditsvc. When the code is done we can share it with the customers and sign contracts. The prototype contract is there so the committee can judge if it's appropriate before the contract letting actually talks place. Both unstable and obsolete seem completely wrong to me. It is introduced by this project and has never been exposed. The project does not want it used and exposed to general customers and has no intention of documenting it beyond the header file delivered with Solaris except to (external) contract consumers (PARTNERs). > > During the investigation of this project a void was > > uncovered that Sun could choose to take a leadership role in > > filling. Specifically, no standard secure protocols were > > identified for remote logging much less remote logging of > > structured data. > > I'd disagree with that. There *are* such standards-track protocols, > but none are supported in Solaris today. Sun needs to choose one and > back it. Gosh, I remember you being in agreement during the conference call where this all took place and even one of those recommending that Sun step into the void. Please point the project team to the currently agreed upon secure protocol for doing remote structured data logging, there is still a desire to not invent a new one and to create a project to live up to this project's title. Gary.. From sacadmin Thu Feb 6 17:51:58 2003 Date: Thu, 6 Feb 2003 17:53:30 -0800 (PST) From: "Joseph E. Kowalski III" Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log To: gww@marduk.eng.sun.com, james.d.carlson@east.sun.com, Gary.Winiger@eng.sun.com Cc: sac-review@sac.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oBKpfsJIXtxxg5TEDrJZoA== Content-Length: 507 > I guess the point you're > making is that a project private interface cannot span multiple ARC > cases. This seems odd to me when a project, such as the Solaris > Audit project will have multiple ARC cases (as it evolves). Project private interfaces certainly can span multiple ARC cases. A guess the relevant question here is, what is the project and what is its bounds. Project is perhaps a misnomer. Its really subcomponent. For example, ufs is generally considered a project. - jek3 From sacadmin Thu Feb 6 18:32:09 2003 Date: Thu, 6 Feb 2003 18:29:54 -0800 (PST) From: Gary Winiger To: gww@marduk.eng.sun.com, james.d.carlson@east.sun.com, Gary.Winiger@eng.sun.com, Joseph.Kowalski@eng.sun.com Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Cc: sac-review@sac.eng.sun.com Content-Length: 754 > > I guess the point you're > > making is that a project private interface cannot span multiple ARC > > cases. This seems odd to me when a project, such as the Solaris > > Audit project will have multiple ARC cases (as it evolves). > > Project private interfaces certainly can span multiple ARC cases. > > A guess the relevant question here is, what is the project and what is > its bounds. > > Project is perhaps a misnomer. Its really subcomponent. For example, ufs > is generally considered a project. I've tried to view Solaris Audit as a project that has a number of subcomponents (this case being one). Unfortunately much of Solaris Audit was never ARCed, viz the question about getopt compliance of auditconfig(1M). Gary.. From sacadmin Thu Feb 6 18:37:31 2003 Date: Thu, 06 Feb 2003 18:36:40 -0800 From: John Plocher X-Accept-Language: en MIME-Version: 1.0 To: Gary Winiger CC: sac-review@sac.eng.sun.com Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1774 Gary Winiger wrote: > I guess the point you're > making is that a project private interface cannot span multiple ARC > cases. This seems odd to me when a project, such as the Solaris > Audit project will have multiple ARC cases (as it evolves). I think we are tripping over glossary misunderstandings here: What do you call the "thing" that is putback into the source base as the result of an approved arc project? The life cycle of an "ARC Project" is complete at the point the putback integration is accepted into the source tree; the artifact that remains is not, by definition an "ARC Project". But, we still call that artifact a project, because there is usually an obvious relationship between the first such arc project and the element that it creates: All of the following refer to a project called "perl": PSARC 1999/192 Including Perl 5 with Solaris PSARC 2001/145 Update of Perl shipped with Solaris to version 5.6.1 PSARC 2001/714 Removal of Perl 5.005_03 from Solaris 10 I have taken to calling that artifact an "element" and not a "project" simply to avoid having this problem. Using this definition, the "Project Private" taxonomy is better understood as being "Element private", and not "ARC Case private". (It is only in the degenerate case of the very first ARC case where the two are exactly synonymous - which is also why the current taxonomy is worded the way it is instead of saying "Element Private" :-) Thus, the rule is really A project private interface cannot span multiple elements, An element can not span consolidations, A consolidation consists of 1 or more elements, and As it evolves over time, an element is expected to have several ARC cases associated with it. -John From sacadmin Fri Feb 7 05:32:42 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 7 Feb 2003 08:31:50 -0500 From: James Carlson To: Gary Winiger Cc: sac-review@sac.eng.sun.com Subject: Re: Opinion for Review: PSARC/2002/150 Secure Remote Audit Log Content-Length: 4604 Gary Winiger writes: > This was discussed in the 2002/665 fast track and in remarks during > this cases review. auditsvc(2) was improperly exposed outside the > "Solaris Audit" project (the present case is a component of the > Solaris Audit project). As the Solaris Audit project was introduced > into SunOS 5.3 without ARC review, I've been slowly trying to clean > up the interfaces as they come to ARC. I guess the point you're > making is that a project private interface cannot span multiple ARC > cases. No. > This seems odd to me when a project, such as the Solaris > Audit project will have multiple ARC cases (as it evolves). As > discussed, this case modifies auditd(1M) which consumes auditsvc(2) > in such a way as to extend the funcitonality of auditsvc for auditd > to import. How do you propose specifying this? The reference to > 2002/665 is to clarify the taxonomy of auditsvc which could have > been, previously, implied as Stable. In that case, I'd just move it to the exported interface list, or at least describe what's going on in the discussion. This is a comment on the opinion text, not on the decision itself. > > I looked, but couldn't find a signed contract -- just an incomplete > > prototype. If this case is importing this interface from some other > > project, then a completed contract is needed. If this case is > > It's not, See the line from the Exported interface table as > well. > |audit_plugin(3BSM)| Contracted Pro-| auditd(1M) SPI | > | | ject Private | interface | > > Would you propose a change there as well and to what? Neither one makes sense to me. When the ARC approves a contract, it's approving both the scope and the impact of the contract. For Partner relationships, the actual partner must be named in order for it to be a valid contract. If there aren't any such contract users, and we don't have a signed contract, then this should remain as Project Private. > > might as well be some form of "private" until there's an actual > > consumer available. If the consumer is known, then the consumer needs > > to be identified. If not, then the right stability might be Unstable > > or Obsolete. > > I recall this also being discussed with this case. These interfaces > are Project Private with the intent of sharing them with the small > set of customers who replace auditd and consume auditsvc. If we don't actually know who the customers are, and the extent of the usage, I don't see how we could approve a contract. When this was discussed during the review, I asked about this and was told that the contract just hadn't been written yet. I'm noting that I still don't see a contract here. I'm fairly uncomfortable with setting a precedent that allows unspecified prospective contracts. This is in direct conflict with "Contracted Stability Levels" (PSARC 2001/421), which requires that the Partner(s) be named. I see a risk of misuse of such contracts where a more stable interface might be the right answer. > > I'd disagree with that. There *are* such standards-track protocols, > > but none are supported in Solaris today. Sun needs to choose one and > > back it. > > Gosh, I remember you being in agreement during the conference call > where this all took place and even one of those recommending that > Sun step into the void. Please point the project team to the > currently agreed upon secure protocol for doing remote structured > data logging, there is still a desire to not invent a new one and > to create a project to live up to this project's title. There are such standards-track protocols -- RFC 3195 "reliable syslog" uses BEEP with TLS and is Proposed Standard. I certainly agree that the *marketplace* hasn't agreed on one, nor even agreed that one is necessary at all, but that's not the same thing as saying that there is no such standard protocol. Yes, I recommended a step into the void. If such a standard protocol is indeed necessary, I think it would be extremely foolish for Sun to sit around and wait for its competition to decide on a protocol to use. Those other folks have little incentive to choose something that works well for us. Perhaps we're just disagreeing on the meaning of the word "standard." I can't tell. I do not see where I might have said that there are no such protocols. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Fri Apr 4 10:04:25 2003 Date: Fri, 4 Apr 2003 10:02:30 -0800 (PST) From: Gary Winiger To: psarc@sac.eng.sun.com Subject: 2002/150 project private interface update Cc: tony.panero@sun.com Content-Length: 1368 During code review of this project, the project private audit_plugin(3BSM) interface has changes slightly from what was approved. The approved interface provided for optional packing of the "raw" audit records sent to the plugins. The theory of the packing was that by sending 8K blocks, disk I/O could be improved because the blocks would be on disk page boundaries. However, that can never happen since audit records also need to be flushed to "permanent" storage before the first disk page could be filled. (An audit requirement to minimize loss of audit records due to system failure.) The system booted audit record (only a few bytes) is always flushed before there is significent enough audit activity to fill 8K. This packing made the code in both auditd and the plugin more complex in what was hoped to be a performance gain. No such gain could be measured. In fact, it appears that the current auditing code could have been made more maintainable if it had not attempted similar packing, as the hoped for performance gain can never be realized. This interface has not been integrated, nor exposed outside the project. The opinion is unchanged. I've renamed the approved man page and added the new man page in the case materials. I don't believe this change warrents discussion. If others do, the project team is happy to run a fast track. Gary.. From sacadmin Mon Apr 7 16:42:30 2003 Date: Mon, 7 Apr 2003 16:40:31 -0700 (PDT) From: Gary Winiger To: sac-review@sac.eng.sun.com Subject: Opinion for re-Review: PSARC/2002/150 Secure Remote Audit Log Content-Length: 9751 To resolve the issues from the initial SAC review, the opinion/project has been changed in the following ways: audit_plugin(3BSM)/auditd.h are Project Private, section 4.3 was also changed to reflect this interface classification change audit_plugin is no longer listed as both an imported and exported interface; it is only exported the SC advice section 6.1 has been reworded. For your viewing pleasure, pdf of the opinion is in the case directory. Please review by 14 April 2003. Thanks, Gary.. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Secure Remote Audit Log Submitted by: Tony Panero File: PSARC/2002/150/opinion.ms Date: December 4th, 2002 Committee: Ralph Campbell (opinion written by Gary Winiger), James Carlson, Joseph Kowalski, Terrence Miller, Andy Tucker. Steering Committee: Solaris Operating Environment Steering Com- mittee soesc-prodteam@sun.com Operating Systems and Networking Steering Committee onsc@sun.com 1. Summary The project name reflects the original intent of the project and is a misnomer of the project approved. A more appropri- ate name would not include "secure." This project provides a mechanism to send binary audit data to an alternate and / or secondary destination. The current audit mechanism only allows recording the binary audit data in a file. The alternate or secondary destination is pro- vided for by a plug in to the audit mechanism. This project provides a plug in which sends the binary audit data to a file and one which formats the binary audit data as human readable syslog messages and forwards them to syslog(3C) as audit.notice messages. Additionally, it defines the LOG_AUDIT facility for Solaris to correspond with the audit facility defined in RFC 3164 [1]. The structure of this project is such that additional plug ins could be supported by a future project. 2. Decision & Precedence Information The project is approved as specified in reference [2]. The project may be delivered in a micro or patch release of Solaris. PSARC/2002/150 Copyright 2002 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |__________________|_________________|____________________| |Interface | Classification | Comments | |__________________|_________________|____________________| |audit(1M) | Evolving | | |auditd(1M) | Evolving | | |audit_warn(1M) | Evolving | new "plugin" | | | | subcommand | |audit_plugin(3BSM)| Project Private| auditd(1M) SPI | | | | interface | |audit_binfile(5) | Evolving | auditd(1M) plug | | | | in to implement | | | | the current | | | | binary audit | | | | trail | |audit_syslog(5) | Evolving | auditd(1M) plug | | | | in to write | | | | syslog messages | |audit_control(4) | Evolving | new keywords | |auditd.h | Project Private| audit_plugin(3BSM)| | | | header | |__________________|_________________|____________________| The project imports the following interfaces. ______________________________________________________ | Interfaces Imported | |________________|_________________|_________________| |Interface | Classification | Comments | |________________|_________________|_________________| |auditsvc(2) | Project Private| See 4.3 | |audit_control(4)| Evolving | defines which | | | | audit paths are| | | | active | |syslog(3C) | Standard | | |________________|_________________|_________________| 4. Opinion 4.1. Not Secure When this project was initially submitted, it intended to use a secure remote logging protocol. The project could not find an acceptable standard one. It is beyond the scope of the project to create one. Some committee members felt Sun should take a leadership role in defining such a protocol. PSARC/2002/150 Copyright 2002 Sun Microsystems - 3 - This led to steering committee advice. Customers requested audit information be available through the syslog protocol. The project investigated the various proposals for "secure" syslog and found a lack of focus and movement toward con- sensus. Combining the customer request for syslog and the goal of remote audit log led to the project as presented. 4.2. Structured syslog Messages The project proposed to use the syslog protocol [1] to directly write structured audit trail data to remote host formatted as XML compatible with PSARC/2002/377 "Audit Trail Translation to XML." The committee found two major faults with this approach: the direct formatting and transmission over UDP of syslog protocol messages and the precedent of creating structured stable data in syslog. The committee felt strongly that even to imply stability for one class of syslog messages would lead to customer calls for stability of all Sun syslog messages. The project removed its use of XML and created human readable syslog message that extract some significant parts of the audit trail data using syslog(3C). 4.3. auditsvc(2) and audit_plugin(3BSM) This project prompted PSARC/2002/665 "Audit Interface Reclassification," which reclassified auditsvc(2) as Project Private. Some committee members expressed concern that the customer(s) who may be using auditsvc would have their applications break. The project team pointed out that PSARC/2002/665 only reclassified auditsvc and that neither project will actually change the implementation in an incom- patible way. auditsvc will be announced to be Project Private in the next micro release and its documentation removed in the next minor release. The known customer(s) reluctantly use auditsvc because there has been no alternative to capture the audit data in real- time for analysis. Use of auditsvc requires replacing auditd(1M). Such replacement is not supported by Sun. This project introduces audit_plugin(3BSM) which is intended to replace the need for customer use of auditsvc with a more efficient and stable interface. Because audit_plugin is a new interface, it is being classified as Project Private. The project intends to offer contracts [3] to use the audit_plugin interfaces to the known auditsvc users. At the time of a contract is tendered, audit_plugin and auditd.h will become Contracted Project Private. Once audit_plugin is proven it is expected to be promoted to a public inter- face. 4.4. auditconfig(1M) not getopt(3C) Compliant A committee member expressed concern with the lack of PSARC/2002/150 Copyright 2002 Sun Microsystems - 4 - conformance by auditconfig(1M) with getopt(3C). This pro- ject does not modify this command, rather it only adds notes to the man page. The command syntax is as it was when integrated in 1992. No ARC case can be found for the audit mechanism integrations. The committee concluded that it was outside the scope of this project to change the command to be getopt compliant. 4.5. syslog.conf(4) Poorly Worded A committee member expressed concern with the use of the word "reserved" in the syslog.conf(4) man page. This pro- ject has added new information in a similar syntax to the existing man page. The committee member's concern would have led to an advisory change to the project to reword syslog.conf. Instead, the project updated the specifica- tion. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Need for Secure Remote Logging of Structured Data Pro- tocol During the investigation of this project, a void was uncovered in the Solaris product line. No secure remote logging protocol is provided in Solaris. The steering com- mittees are advised to fund a project to add to Solaris sup- port for a suitable secure remote logging protocol standard that may be used for recording structured data. Such data might include fault events as well as system level audit data. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2002/150. 1. RFC 3164, The BSD syslog Protocol File: final.materials/rfc3164.txt PSARC/2002/150 Copyright 2002 Sun Microsystems - 5 - 2. Final Specification File: final.materials/* 3. Prototype Contract File: final.materials/contract.proto PSARC/2002/150 Copyright 2002 Sun Microsystems