From owner-freebsd-security  Mon Jul 28 09:09:13 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA14889
          for security-outgoing; Mon, 28 Jul 1997 09:09:13 -0700 (PDT)
Received: from homeport.org (lighthouse.homeport.org [205.136.65.198])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA14881
          for <security@FreeBSD.ORG>; Mon, 28 Jul 1997 09:09:04 -0700 (PDT)
Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id MAA04611; Mon, 28 Jul 1997 12:04:52 -0400 (EDT)
From: Adam Shostack <adam@homeport.org>
Message-Id: <199707281604.MAA04611@homeport.org>
Subject: Re: secure logging (was: Re: security hole in FreeBSD)
In-Reply-To: <199707281555.IAA17841@GndRsh.aac.dev.com> from "Rodney W. Grimes" at "Jul 28, 97 08:55:23 am"
To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes)
Date: Mon, 28 Jul 1997 12:04:52 -0400 (EDT)
Cc: adam@homeport.org, dholland@eecs.harvard.edu, robert@cyrus.watson.org,
        security@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL27 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Rodney W. Grimes wrote:
| >       Reliability: The system must make substantial efforts to not
| > 	lose information.  
| > 
| >             Network Requirements 
| >             TCP based 
| >             Application sequencing with explicit ack before sender deletes 
| 
| How are you going to handle the log server going away and coming back??

	The client will have to queue messages.  Its possible that TCP
message queueing will handle this, its also possible that the
application will need some retransmit smarts, which would be
unfortunate, since it adds a good deal of complexity.

	Should there be a capability for multiple log servers (like
mail?)

| >             Application Reliability 
| >             NO data discarding 
| >             Solid message handling locally-messages kept until discard
| >             Repeated message management (?) 
| > 
| >       Portability 
| >       External Alerting 
| >       External Intrusion Detection linking 
| 
| 	Security: The data over the network must be unreadable
| 	unless a secret is known.  Syslog data can contain
| 	confidential information.

	Is confidentiality or authenticity important?  For my
purposes, its authentication.  Should we simply allow the use of IPsec
or SSH port forwarding for confidentiality and authentication?  It
cuts complexity substantially.

| How about just converting syslog/syslogd to handle a kerberized
| t/tcp connection??

Syslog still discards data when its local daemon cache gets too full.
It discards data when forwarding messages from host a via host B to
host C.  (Yes, real case.)  It loses priority and type when putting
messages into files

Not that kerberizing a TCP based syslog would be bad, I just don't
think its sufficient.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume