Re: Obtaining NIS domainname from Gatorbox

[npc () minotaur jpl nasa gov (npc () minotaur jpl nasa gov)]

Dave Horsfall said:
> On Wed, 12 Apr 1995, der Mouse wrote:
> > > Maybe a good reason to join the crowd and not run NIS?
> >
> > I wish.  It's clear to me that NIS is a big problem.  But what else is
> > out there?  We have a definite need to share passwd databases across
> > many machines, from multiple vendors, none of which we have source code
> > to.  How close to a solution can we get?
>
> A wild idea, straight off the top of my head: what about using the DNS
> mechanisms?  Apologies if this has been suggested and flamed before...

A couple of points.  First, in some sense, this has been implemented
(successfully) before.  Find information on Project Athena's Hessiod
service.  NIS like information was added to DNS in the form of 
Hessiod records.  

The problem is that DNS isn't very secure either, plus that's a lot
more for DNS to handle, so, in general, I don't think it's a great
design idea, although it's convenient to use a mechanism that's already
in place.

I'm surprised nobody's mentioned NIS+, although it's not available 
everywhere yet (and I know of no freely distributable implementation).
Still, I'm not sure it's all it's cracked up to be.

I must admit to being firmly in the anti-NIS camp, but mostly because
I don't think it's all that useful.  What does it buy you, really?
It gives you a mechanism for distributing files among systems based
on a master copy.  Of course, since probably all the files (except
passwd and possibly the shadow password file) can be modified only
by System Administrators, who can distribute the files on modification
via just about any means (rcp, rdist (patched!), NFS, whatever, although
each has it's own share of security vulnerabilities).

As I see it, NIS has three actual advantages over the "rcp" approach.
First, real time password synchronization.  This is nice, although it
wouldn't be too hard to write a "front end" for the passwd program
that makes the change and then informs (via public key encryption,
perhaps) the "master password server" of the change and that information
is propogated.  Second, it's easy to maintain some seperate accounts
or passwords on different machines within the same NIS domain.  Third,
one can have seperate SA groups working over the same NIS zones, and
it's hard for one group to access another's machines and claim it
was an accident (although it's certainly easy for them to get that
access).  With any method that requires .rhost trust, rlogin is just
too easy.

If you don't *need* any of these three features, I believe there is
no good reason to run NIS.  Also, the first feature would be fairly
easy to replace in a considerably more secure fashion.

As a footnote, in case anyone wants to point out how insecure .rhosts
based access is, there are ways to make it reasonably secure.  
Using tcp-wrappers to restrict access to only trusted hosts and 
a mechanism like resolv+ or nsswitch one can have all the trusted
machines in the host file which is consulted before DNS for name 
lookups.  This is even immune to DNS based attacks, although raw IP
spoofing is still possible, although difficult.  In any case, it's
considerably more secure, IMHO, than NIS.

Nick Christenson
npc () minotaur jpl nasa gov