Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!uunet!mcsun!ukc!strath-cs!baird!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: comp.protocols.nfs Subject: Re: group permissions when root Message-ID: Date: 27 Jun 91 16:52:25 GMT References: <7958@spdcc.SPDCC.COM> <15542@exodus.Eng.Sun.COM> <15886@exodus.Eng.Sun.COM> Sender: jim@cs.strath.ac.uk Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland. Lines: 29 In-reply-to: db@argon.Eng.Sun.COM's message of 27 Jun 91 05:36:59 GMT In article <15886@exodus.Eng.Sun.COM> db@argon.Eng.Sun.COM (David Brownell) writes: Recently, jim@cs.strath.ac.uk (Jim Reid) flamed "Secure NFS". It's not perfect (is anything?), but some of his comments were off base: > It has a better authentication system, but not much better. For one > thing, NIS (Yellow Pages) is used to distribute the keys. You might as > well announce those keys on peak-time TV for all the "security" NIS > offers. Of course, that's the virtue of a public key encryption system: you can distribute the public keys freely, like on a CD-ROM (or even on TV! :-), and it doesn't matter. This isn't a valid criticism. Ask sci.crypt how exponential key exchange works. I do understand how public key encryption works. What you have overlooked is that secure NFS uses NIS to store the secret keys as well as the public keys (at least that's what TFM says.....). What's to stop me from firing NIS lookup requests at the genuine server and taking the replies away for cryptanalysis? [Let's assume that someone has had the sense to make /etc/publickey world unreadable.] What's to stop me from firing bogus NIS keyserv updates at the NIS server from somewhere that I've improperly obtained root privileges? If that sounds too much like hard work, what if I set up a bogus NIS server somewhere on the net and use ypset to direct all NIS lookups at my bogus host? Jim