Date: Mon, 28 Jul 1997 15:29:43 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: security@FreeBSD.ORG Cc: Adam Shostack <adam@homeport.org>, "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>, dholland@eecs.harvard.edu Subject: Re: secure logging (was: Re: security hole in FreeBSD) Message-ID: <Pine.BSF.3.95q.970728151940.3342I-100000@cyrus.watson.org> In-Reply-To: <Pine.BSF.3.95q.970728123328.3342D-100000@cyrus.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, Robert Watson wrote: > Perhaps we should add another field that has bits to define the > requirement that a given log message be transmitted using authenticity, > confidentiality, and whether it is worth being stored. In any situation > where there was significant doubt, the message would be discarded for > security reasons, or logged locally and a message passed later to indicate > the problem. Also, should authenticity by against a global name space > (DNSsec), and then permission to store messages from a given identity by > defined against that name space, or should it be for transaction-level > only? I'd almost be tempted to define a wrapper packaging for syslog > messages like so: > > u_int16_t sl_flags > u_int8_t sl_prot_type > u_int8_t sl_entity_len > u_int8_t sl_entity[] > u_int32_t sl_timesigned > u_int16_t sl_type > u_int16_t sl_priority > u_int16_t sl_msglen > u_int8_t sl_message[] > u_int8_t sl_signature_len > u_int8_t sl_signature[] > > Where the signature is over all values present except for the > signature+length itself. Type of protection used would be in the > protection type field. This would allow storage of complete log entry > entities, including the signing identity, signature that proves it signed > the data, priority, etc. This would not provide for guarunteed delivery- > -- that would be the responsibility of the transport mechanism used by > syslog. This could actually by the stored log entry used on syslog > servers. To prevent replay (if not provided by the transport), perhaps a > sl_log_id (u_int16_t?) could be provided, which would also indicate jumps > in the sequence, etc. Having thought about this a little more, I'd be tempted to go for a more variable data section to this. Probably in the form of a u_int8_t num_records variable, and then a number of strings representing those records, each with variable length. Also, possibly priority. Clustering similar log messages for the sakes of reducing transmissions and number of signing operations is probably a good idea, but retaining order is important too. Has anyone looked statistically at the distribution of log messages on a standard web server or user server (whatever that means?) to see whether messages cluster by source, priority, type, etc? Is there any concensus on the use of DNSsec in the network community, as it has not yet been made widely available (or at least, it is available, but not largely used.) The key namespace here could be used however one desired, nor necessarily in a DNS-style way. The entity-name, whatever that is, simply suggests which key/algorithm should be used, a server could be configured to pull that information from DNSsec, or from an internal key-file (or both.) Also, if we make a move to TCP, how should connection-management be worked? Presumably, one must make a connection fairly quickly on receiving to send, assuming that it passes any local authenticity requirements (e.g., a log-message must come from a key in *.my.domain to be forwarded), and then put in a queue for delivery when the transport is available. If the TCP connection is already open, and a new message doesn't arrive quickly, it should be delivered. If the TCP connection is not open, then the forwarder (or source) should wait for a certain time-out (something short) for more messages, or until the queue reaches a threshhold before opening the connection. Some delay is acceptable in log delivery, I think, but not too much. Opening the connection will involve a delay -- a T/TCP startup is probably a good idea, as data is immediately ready to send when the connection is opened, or it would not be opening. An ACK message has already been stated as desirable -- would a simple signature over the last packet (or header + signature) using the shared secret, entity public key, or whatever, back on the TCP connection suffice? Maybe something lighter-weight? Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@tis.com http://www.watson.org/~robert/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970728151940.3342I-100000>