Too Large an NIS Group

Let us suppose an intruder has built a fake NIS server in your network. This server is not in the ypservers map, but this map only restricts pushing of the data from the master server toward slave servers. The fake server has fake maps, sufficient to break into the client host. Once the intruder gains control of the real client host, the rest of the job becomes much easier. It should not be easy to build a fake server in the network that you administer. Regular checkups should prevent such attempts. But to prevent something you must first be aware of such a possibility, and that was the purpose of this text.

17.3.5 A Few NIS Stories

17.3.5.1 Too Large an NIS Group

NIS domains cover several dozen UNIX servers and more than a thousand users. Each user has login access to each host, but the access to certain data, i.e., certain files, is restricted and based on the files group ownership. Users belong to multiple secondary groups and accordingly can use the needed data. The master NIS server is Solaris 2.6 box, and NIS load is properly spread over several slave servers. The problem appeared when the size of certain secondary groups hit NIS limits. Each secondary group is specified as a single line in the etcgroup file on the master server in the usual UNIX way. However, NIS cannot swallow the lines longer than 1K characters; once the group hits the limit, the conversion into ndbm format fails. The addition of new users into the groups and the growth of the group entries soon caused the problem — the system could not create a group map properly. How is this inherent NIS restriction overcome? The first idea was to make smaller secondary groups and then merge them into one larger group. However, UNIX does not allow specifying a group as a member of another group; only users can be members of the group. So this idea did not work. • Another idea was to decrease the size of the secondary groups by changing the users primary group in a way to match our needs. This worked, but only for a while. Despite the required tedious work to modify two configuration files —etcpasswd and etcgroup — this painful situation soon became unmanageable. We had to look for another solution. • Could we try with netgroup? At least we could combine multiple groups together without restriction. But the netgroup is just a pointer, it does not own any resource. It can work for some other situation, but not in this case. • It seems that the only workable solution is to create multiple smaller secondary groups with the same GID group ID number. UNIX does not care about group name, it looks only for GIDs. So users that belong to groups with different group names can access the same files that are owned by the same GID; obviously it works. • The author is not delighted with this solution, but it seems to be the only one that works. In UNIX multiple names associated with the same ID number whether these are groups or users are technically feasible, but this is not a healthy approach. Under certain conditions it could be quite confusing when data are displayed. 421 The NIS domain was in production for quite some time. In the meantime, several slave servers had been added and removed from NIS. Everything appeared to be properly done. Suddenly, users started complaining that they could not log in to one of the most important production hosts. The funny side of this story is that some other users could log in to the same host, and they could do their jobs without any problem. What has caused the problem? After some investigation on the host, the administrator realized that the bound slave NIS server was one of the obsolete machines that used to be a slave server in the past, but had been removed from NIS a long time ago. What happened suddenly and why was NIS service only partially provided now? The happy ending of this story is quite simple. When this obsolete slave server was removed from NIS, the cleaning job was not properly and completely done. The NIS server daemon ypserv had been stopped and the machine really ceased to provide NIS service. The server map ypservers was also properly cleaned from the old slave server entry, so everything seemed to be OK. This machine continued to be an NIS client. However, the NIS database in the directory varyp domainname had never been removed; database contents corresponded to the time when the slave server was stopped and had not been updated afterward. Everything was OK up to the next machine booting. Once the machine was rebooted it recognized itself as the slave server in this NIS domain to understand why please check the rc startup script and started to provide NIS service from its obsolete database. At that moment, our host found this machine to be the most convenient NIS server and started to use its data to, among other things, authenticate users that tried to log in. Old users that had not changed their authentication data in the meantime did not have any problem; new users and users that had changed passwords could not log in to the host. So the mystery was solved — every job, including the shutdown of the NIS server, must be completely done; otherwise…

17.3.5.3 Change of the NIS Domain Name