Date: Tue, 30 Sep 1997 10:07:11 +0200 From: Jeremy Lea <reg@shale.csir.co.za> To: Mike Smith <mike@smith.net.au> Cc: Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <19970930100711.04631@shale.csir.co.za> In-Reply-To: <199709300220.LAA02242@word.smith.net.au>; from Mike Smith on Tue, Sep 30, 1997 at 11:50:17AM %2B0930 References: <19970930011555.61645@grendel.IAEhv.nl> <199709300220.LAA02242@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 30, 1997 at 11:50:17AM +0930, Mike Smith wrote: > > Mike Smith shared with us: > > > Wes: Stop Right Here. > > > > > > If you can come up with a security model that makes this viable on an > > > adequately large scale, I will *happily* abandon almost any other > > > thought I might have of using any other interface and happily work > > > under a browser. > > > > > > If not, and I'm not convinced one way or another, then we have to give > > > this idea the wide berth it will deserve. > > 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. > > At this point in time, I'm not convinced that browser technology is > there yet; I'm merely asking Wes (because his employer is actually > doing things) if he has any good ideas. > > By contrast, implementing the backend is relatively trivial. Easily > the largest hurdle is designing the interface, once you are sure of > your security. 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: 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.). Within a Java application, attached to your administrative web pages via Javascript, 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). The server, running as root@foo.bar, can then verify that the signed magic is from the admin@bar, since it has a copy of admin@bar's public key, and it knows that that public key is real because it has signed it. It can therefore verify that the magic comes from admin@bar, and proceeds to process it and apply it to the config files. 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. You could also get the Java applet to encrypt the magic so that only root@foo.bar could understand it. Also you could have root@foo.bar sign and/or encrypt all communication to admin@bar, preventing people from "administering" masqueraded machines. A little thought says the primary weakness is that root@foo.bar's secret key must be available to it in some open form, along with admin@bar's at various times in the Java applet, and if they can be stolen then you have a hole. But this is a known attack on PGP (and family), and if you are having this kind of data snooped then you have probably already lost the battle. You could also have the machines in a hierarchy, such that they didn't all have to sign the public keys of the admins, but would trust any magic signed by an admin approved by root@bar. I don't know anything about NIS, and not much about the other crypto schemes for network passwords, and how much help they would be in implementing this. Also I'm not sure on the legal issues around the various public key crypto schemes. 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. -Jeremy -- | "I could be anything I wanted to, but one things true --+-- Never gonna be as big as Jesus, never gonna hold the world in my hand | Never gonna be as big as Jesus, never gonna build a promised land | But that's, that's alright, OK with me..." -Audio Adrenaline
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970930100711.04631>