🚀 go-pugleaf

hendrick@ctron.com (Jim Hendrick) writes:

>Hi All,
>	I have a question. Have any of you set up NIS in such a way
>that:
>	- The NIS servers only allow a certain set of clients to bind
>	to them. THis could be a set of network addresses in certain
>	ranges or an explicit list of ethernet addresses, hostnames,
>	or IP addresses.

Difficult to impossible. It is possible to restrict answering NIS
queries to certain clients. This is what Sun's patch 100482-02 does.
It is not possible to prevent clients to bind to a server for their
domain on the same net. The call ``who serves this domain'' is
implemented through broadcast RPC. Broadcast RPC works via the
portmapper and obscures the origin of the call to the server.
But if it's the data you want to guard, Sun's 100482-02 patch does
the yob.

>	- The Clients only allow themselves to bind to this certain set
>	of NIS servers.

That would be a good idea. Modern implementations only allow binding
to servers run by root. They also, by way of their implementation,
will only bind to server on the same net. If you can't trust your net,
there's really nothing you can do: they can present themselves on the
net as the ``trusted'' NIS servers.


>	- The NIS password maps are not generally obtainiable. By
>	this I mean that the client machines use the maps for login
>	authentication, BUT J.Fred.User cannot obtain the encrypted
>	passswords.

You need to be able to get at the user data for things like
ls(1), talk(1), finger(1) etc. You would want to restrict
the distribution of encrypted passwords. Although some NIS shadow
password implementations do exist, none of these will work
in a mixed vendor environment. Personnaly I like the way SUn has
implemented shadow passwords in 4.x (no changes to user code
necessary). The BSD way is also nice: only fill in the encrypted
password in struct passwd when root. Something similar could be
done for NIS: if the query is from a reserverd port, send the encrypted
password, else don't. Not all vendors have added the extra bit of security
that using reserved port in RPC gives.

>	This would need to be implemented on a very diverse set of
>machines. We currently run: Sun SPARCs (under 4.1.x and Solaris),
>DECstations (2100, 3100, 5000 all running 4.2 variations), SGI
>(Indigos and Irises running IRIX 4.0.x), IBM (rs6000 320s, 340s
>running AIX 3.2.x). Note that most of these platforms do NOT use
>a shadow password file. Is this a *very difficult thing to do*
>or not? What hardware/software do you use for the NIS servers?

If you want to protect your maps from the outside world:
use Suns as NIS server (w/ patch 100482-02)

The password thing is much more difficult to impossible. Probably
requires source code of ypserv or `secure map -> shadow file'
daemons on other machines.

SunOS, being the ``reference implementation'' of NIS is always ahead
in protection. The people of SGI are always close behind. Ultrix and AIX
are lagging behind. Suns and Indigos/Irixes can run ypbind -s, which makes
ypbind save from the outside. IRIX 4.x has the added feature of being
able to allow/deny access to the portmapper from the outside. This only
buys you something in conjunction with other measures and doesn't protect
servers (like ypserv) by itself.

AIX still allows anyroot to do a ypset, remotely. DEC is probably even further
behind (they always were, wrt NIS/ Sun RPC)

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl