From owner-freebsd-chat Tue Sep 30 06:11:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA24425 for chat-outgoing; Tue, 30 Sep 1997 06:11:40 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA24418 for ; Tue, 30 Sep 1997 06:11:27 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id WAA00501; Tue, 30 Sep 1997 22:37:18 +0930 (CST) Message-Id: <199709301307.WAA00501@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jeremy Lea cc: Mike Smith , Peter Korsten , chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) In-reply-to: Your message of "Tue, 30 Sep 1997 10:07:11 +0200." <19970930100711.04631@shale.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Sep 1997 22:37:16 +0930 From: Mike Smith Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What has to exist is an adequately secure channel whereby the > > administrator can connect to the system(s) in question without risking > > compromise. This has to include geek-in-the-middle attacks, password/ > > cookie sniffing, spoofing etc. ... > How about something like this... I've haven't put much thought into it, but > it's based on some ideas I've had for a large distributed database that I'm > currently working on: [... rampant over-the-top all-singing-and-dancing Java-PGP monstrosity elided ...] Heck, I think that says it all. Look; all these ideas have great technical merit, but no commonsense. Stop and think for a few seconds about what actually has to be achieved in order to make this model work. Visualise how your design would be used in a few different situations, eg. : - Single user at home. - Server in busy ISP application. - Development workstation. - Large corp/tertiary network. Also consider that whatever the interface, it has to work with a textmode browser (ie. lynx). > Use signature signing in PGP (or similar). You (root@foo.bar) generate a set > of PGP keys for foo, and then proceed to sign the public keys of say > joe@foo.bar (your own account) and admin@bar. These are your trusted > administrators (you could implement a hierarchy and groups and access rights > etc. to various services etc.). Too complicated to be the only security model. What's PGP? "Fred the new admin needs to to XYZ, how do we give him permission?" > Within a Java application, attached to your administrative web pages via > Javascript, How do we do this? Why does it have to be (ack, spit) Java? > admin@bar could communicate with the server on foo.bar, asking > for it's configuration options etc. which it then present in the browser. > The admin changes these options, and they are passed back to the Java applet > which generates the necessary magic to sent back to the server, and signs it > with the admin@bar's secret key (which must be on the browsers machine). So you can't just use a vanilla browser anyway; it has to have Java and enough security holes to run PGP on the local system? I don't buy it. > This also has the advantage that it doesn't require a network connection. > You could design things in such a way that the communication occurred over > e-mail, by sending a request for, say, a DNS host add form, which is mailed > back, and then mail the reply. This is nice, but basically mandates Netscape for forms-enabled email. > Just a sketch, I hope that I managed to get this across. Obviously there are > a lot of details which would have to be sorted out. As you said, the > interface and the server details are the hard parts. TBH, even a not-terribly-wonderful encrypted channel between the browser and server would be the *only* way that I would accept a browser as an adequate interface. By contrast, the proposed Tcl application method wins in that : - It can use any stream encryption for client/server comms (eg. ssh) - Tcl is portable to most *nixlike systems, Win32 and the Mac. - Client-side processing and dynamic interaction are implicit. On the downside, it's a lot more work. So if we can avoid it, that'd be Just Wonderful. Keep brainstorming. If you can get past these sort of objections, we all win. mike