From owner-freebsd-chat  Tue Sep 30 23:54:08 1997
Return-Path: <owner-freebsd-chat>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA23303
          for chat-outgoing; Tue, 30 Sep 1997 23:54:08 -0700 (PDT)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA23296
          for <chat@freebsd.org>; Tue, 30 Sep 1997 23:54:03 -0700 (PDT)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA00865;
	Wed, 1 Oct 1997 16:20:47 +0930 (CST)
Message-Id: <199710010650.QAA00865@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: softweyr@xmission.com
cc: chat@freebsd.org
Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) 
In-reply-to: Your message of "Wed, 01 Oct 1997 01:38:28 MST."
             <34320C04.5DB5@xmission.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 01 Oct 1997 16:20:47 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-chat@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> OK, I'm working on this.  (Got the old 486sx laptop fired up here in San
> Hoser, and am slaving away on FreeBSD work as we speak.  ;^)

Good to hear. 8)

> I've been developing the prototype for the next generation of my
> embedded
> web server on FreeBSD ;^) where it is working pretty well.  I'm willing
> to throw this in, if I can convince you (all-inclusive you here) that it
> will be sufficiently secure.  I can think of a couple of ways to insure
> this, but it won't be completely painless.

How do you feel about adding source-IP-based access control?  That and 
a local sshd in port-forwarding mode would just about do it.

> I believe most security-enabled broswers support SSL communications for
> "secure" documents.  They also support extended, and *extenable*
> authentication protocols, a number of which might be acceptable in
> conjunction with SSL.

SSL is, AFAIK, subject to certain undesirable licensing conditions (not 
exportable, not available for commercial use, etc.) which may render it
unsuitable.

> The part I'm not certain of is the interaction
> with Lynx, which I feel is a necessity for our situation.  Another
> need is a simple local communications
> path, so we can use Lynx to setup the machine via the console, VGA or 
> serial.  Perhaps a UNIX-domain socket would suffice, or even a FIFO.

What's wrong with an ordinary socket talking to the loopback address?

> Adding "acceptable" users to the UI is quite complex, as well.  You
> would have to start with a default of "allow any local user" to connect, 
> and (hopefully) automagically promote that to "allow this specific local
> user" to connect *very* quickly.

When first started, the system should be in "virgin" mode.  The first 
user to connect to it is granted full access rights.  These can then be 
granted out to new users as they are defined.  Think of the grant model
from SQL.

mike