Date: Tue, 30 Sep 1997 22:37:16 +0930 From: Mike Smith <mike@smith.net.au> To: Jeremy Lea <reg@shale.csir.co.za> Cc: Mike Smith <mike@smith.net.au>, Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199709301307.WAA00501@word.smith.net.au> In-Reply-To: Your message of "Tue, 30 Sep 1997 10:07:11 %2B0200." <19970930100711.04631@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709301307.WAA00501>