From owner-freebsd-security  Mon Jul 28 08:56:12 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA14280
          for security-outgoing; Mon, 28 Jul 1997 08:56:12 -0700 (PDT)
Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA14272
          for <security@FreeBSD.ORG>; Mon, 28 Jul 1997 08:56:06 -0700 (PDT)
Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id IAA17841; Mon, 28 Jul 1997 08:55:23 -0700 (PDT)
From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>
Message-Id: <199707281555.IAA17841@GndRsh.aac.dev.com>
Subject: Re: secure logging (was: Re: security hole in FreeBSD)
In-Reply-To: <199707281340.JAA03478@homeport.org> from Adam Shostack at "Jul 28, 97 09:40:14 am"
To: adam@homeport.org (Adam Shostack)
Date: Mon, 28 Jul 1997 08:55:23 -0700 (PDT)
Cc: dholland@eecs.harvard.edu, robert@cyrus.watson.org, security@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL25 (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

> | I don't know of any; if you run across one or are thinking about
> | designing one, please post or mail... absent any other readily
> | available secure mechanism probably the best bet is to carry log data
> | over ssh. Of course, this doesn't solve the denial of service issue as
> | anyone with a login can spam the local syslog.
> 
> I've been working on a draft set of requirements--very drafty, but
> since the subject came up, I'll share & ask for feedback.
> 
> 
> Requirements
> 
>       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??

>             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.

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

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation, Inc.                   Reliable computers for FreeBSD