On Wed, Jun 18, 2003 at 03:07:06PM -0400, Derek Martin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Jun 18, 2003 at 01:47:38PM -0400, Mark Komarinski wrote: > > On Wed, Jun 18, 2003 at 01:22:06PM -0400, [EMAIL PROTECTED] wrote: > > > > > > A normal client works exactly the same as a slave server, with the > > > caveat that if the client fails to contact a local slave, you could > > > opt for it to attempt to contact the master as well. > > > > All you've done is reimplement NIS - poorly. > > Not so. Because again, you don't have clients constantly making > remote database queries in order to do pretty much everything. Thus > the biggest problem with NIS (ignoring for the moment the security > aspect), the fact that if the clients can't contact the/a server, > EVERYTHING breaks, is eliminated. They might not have the most recent > updates, but so long as those updates don't affect them directly > (which will be the vast majority of cases), this presents no problem. > Meanwhile, the admins can find/fix the problem without any time > pressure. That depends on the network. Which is why I clarified the statement by saying that networks today are far more reliable/speedier than when NIS was first started.
> With NIS, if your server breaks, everything comes to a screeching > halt. Sure, if you use one NIS server. The same could be said to using one e-mail server. Or just a PDC. > > Nor would your solution solve the most serious issue with NIS: the > > "if you have root on one box, you can take over anyone's account" > > vulnerability. > > This is true, but the ONLY solution to that, where network resources > are provided solely on the basis of RPC authentication (e.g. NFS) is > not give users root access. If your network resources require other > authentication, such as Kerberos, or such as CIFS, then this doesn't > matter. [Unfortunately, AFAIK there is still no Kerberized NFS > implementation for Linux. If someone knows otherwise, please speak > up!] I solve that by turning on root_squash everywhere. But that doesn't prevent su - ; su user_I_hate ; rm -rf * > > > Well, I think this could be handled pretty easily in a couple of > > > different ways. The first, and rather simplistic method is via a Web > > > interface where the user changes their password, shell, whatever. > > > Upon submission and validation of the form, an rdist is kicked off to > > > the slaves and clients. > > > > Already implemented in yppasswd > > Which is irrelevant. And IIRC yppasswd does all its communication in > the clear, just as the shadow map is transmitted in the clear. So > anyone with physical access to the network can get probably 30% of > your network's passwords in about 60 seconds with a tool like John the > Ripper. [The 30% is roughly the percentage of your users whose > passwords are poor enough to be cracked or guessed immediately by any > standard password cracking tool.] I'd normally say "but that's why I said a switched network". But ypcat passwd gets you there just as quickly. > > > There are some obvious concerns with this method, namely, do you want > > > to trust propagating changes to an entire network which were received > > > from a possibly compromised host. However, in certain environments, > > > I can see where this risk is really no worse than running NIS in the > > > first place, since an NIS server is rather easy to compromise even > > > without physical access to it. > > > > Err? > > If you have root access to a Unix machine, physical access to the > network, and knowledge of the name of the YP domain running on it, you > can hijack the whole NIS domain in under a minute. If you don't know > the domain, it will take slightly longer, as you'll have to sniff the > network to get it first... Pfft. There's a zillion ways to do that. Imagine my suprise when I accidentally set a desktop's IP address to be that of the NFS server. Whoops! -Mark
pgp00000.pgp
Description: PGP signature
