From: sgf@cfm.brown.edu (Sam Fulcomer) Newsgroups: alt.security,comp.unix.admin Subject: Re: NIS and password security Message-ID: <95123@brunix.UUCP> Date: 5 Dec 91 13:46:11 GMT References: <1991Dec4.170052.14839@mp.cs.niu.edu> Organization: Brown University Center for Fluid Mechanics In article prl@iis.ethz.ch (Peter Lamb) writes: >There have been a number of queries and some not completely accurate >information posted on this question. I'll try to summarise the problem and > >The problem is this: ypserv is totally indiscriminate about which machines >it will respond to queries from. Normal NIS maps can be read by anyone > >1) The Sun Party Line. "Don't run ypserv on your gateway and disable > IP forwarding on the gateway". This is commonly known as a Well, the most functional arrangement is to have the ypserv'r set up with static routes limited to the set of ypbind'rs authorized (no default route...). The following may be a little disjointed, since it's just paste-up out of a few of my mbox.out's from the past couple of years. -------------------- The problem is much grosser. ypbind usually uses a non-priv port. Most implementations of the portmapper allow any uid to unregister services on non-priv ports. This means that anyone can register a new ypbind, perhaps pointing to a ypserv with a passwd map entry something like "fooroot" (uid 0). The way to avoid this on Suns is to run ypbind with the "-s" option. This has the undocumented behaviour of running on a privileged port, causing portmap to disallow deregistration by non-root. The way to avoid it on non-suns that aren't fixed is to _REMOVE_ the "+" entry >From the passwd file or run a patched portmap and ypbind (patch the portmap to respect privileged ports and patch ypbind to register on one...). This is a _really_ ugly problem. If the "+" entry is left in the passwd file, even if you're not actually running ypbind, all a user has to do is fire it up. The portmapper is, of course, susceptible to mischief in the form of wholesale deregistration of important services. The smart-money portmapper would only deregister services which were registered by a process with matching credentials. At least it would make things a dependable as the current crud-type. If you want reasonably secure yp... - implement ypexports for ypserv (like /etc/exports). have it use /etc/netgroup - have ypbind always run as root on a reserved port - have portmap respect services on reserved ports - make sure that portmap only accepts map/unmap calls from the local machine -- _/**/Sam_Fulcomer sgf@cfm.brown.edu What, me panic: uba crazy Associate Director for Computing Facilities and Scientific Visualization Brown University Center for Fluid Mechanics, Turbulence and Computation