Replacing NIS [was:NIS - "Could not read ypservers map" during "make"]

[Mark Komarinski]

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, pll at lanminds.com 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20030618/3598348e/attachment.bin