Managing NFS and NIS

Managing NFS and NIS

3.7 4
by Mike Eisler, Ricardo Labiaga, Hal Stern
     
 

View All Available Formats & Editions

A modern computer system that's not part of a network is even more of an anomaly today than it was when we published the first edition of this book in 1991. But however widespread networks have become, managing a network and getting it to perform well can still be a problem.Managing NFS and NIS, in a new edition based on Solaris 8, is a guide to two tools

Overview

A modern computer system that's not part of a network is even more of an anomaly today than it was when we published the first edition of this book in 1991. But however widespread networks have become, managing a network and getting it to perform well can still be a problem.Managing NFS and NIS, in a new edition based on Solaris 8, is a guide to two tools that are absolutely essential to distributed computing environments: the Network Filesystem (NFS) and the Network Information System (formerly called the "yellow pages" or YP).The Network Filesystem, developed by Sun Microsystems, is fundamental to most Unix networks. It lets systems ranging from PCs and Unix workstations to large mainframes access each other's files transparently, and is the standard method for sharing files between different computer systems.As popular as NFS is, it's a "black box" for most users and administrators. Updated for NFS Version 3, Managing NFS and NIS offers detailed access to what's inside, including:

  • How to plan, set up, and debug an NFS network
  • Using the NFS automounter
  • Diskless workstations
  • PC/NFS
  • A new transport protocol for NFS (TCP/IP)
  • New security options (IPSec and Kerberos V5)
  • Diagnostic tools and utilities
  • NFS client and server tuning
NFS isn't really complete without its companion, NIS, a distributed database service for managing the most important administrative files, such as the passwd file and the hosts file. NIS centralizes administration of commonly replicated files, allowing a single change to the database rather than requiring changes on every system on the network.If you are managing a network of Unix systems, or are thinking of setting up a Unix network, you can't afford to overlook this book.

Product Details

ISBN-13:
9781565925106
Publisher:
O'Reilly Media, Incorporated
Publication date:
07/18/2001
Edition description:
Second Edition
Pages:
512
Product dimensions:
7.10(w) x 9.14(h) x 1.03(d)

Read an Excerpt


Chapter 8: Network Security

NFS Security

Filesystem security has two aspects: controlling access to and operations on files, and limiting exposure of the contents of the files. Controlling access to remote files involves mapping UNIX file operation semantics into the NFS system, so that certain operations are disallowed if the remote user fails to provide the proper credentials. To avoid giving superuser permissions across the network, additional constraints are put in place for access to files by root. Even more stringent NFS security requires proving that the UNIX-style credentials contained in each NFS request are valid; that is, the server must know that the NFS client's request was made by a valid user and not an imposter on the network.

Limiting disclosure of data in a file is more difficult, as it usually involves encrypting the contents of the file. The client application may choose to enforce its own data encryption and store the file on the server in encrypted form. In this case, the client's NFS requests going over the network contain blocks of encrypted data. However, if the file is stored and used in clear text form, NFS requests to read or write the file will contain clear text as well. Sending parts of files over a network is subject to some data exposure concerns. In general, if security would be comprised by any part of a file being disclosed, then the file should not be placed on an NFS-mounted filesystem. You can prevent damage to files by restricting write permissions and enforcing user authentication, but there are few safeguards against someone eavesdropping on your network. NFS has some simple security mechanisms in place today, and the Secure RPC mechanisms described in this chapter ensure that user authentication is made secure as well. "Ibis section presents ways of restricing access based on the user credentials presented in NFS requests, and then looks at validating the credentials themselves using Secure RPC.

NFS RPC Authentication

Every NFS request, including mount requests, contains a set of user credentials with a UID and a list of group IDs (GIDs) to which the UID belongs. NFS credentials are the same as those used for accessing local files, that is, if you belong to five groups, your NFS credentials contain your UID and five GIDs. On the NFS server, these credentials are used to perform the permission checks that are part of UNIX file accesses-verifying write permission to remove a file, or execute permission to search directories. There are three areas in which NFS credentials may not match the user's local credential structure: the user is the superuser, the user is in too many groups, or no credentials were supplied (an "anonymous" request). Mapping of root and anonymous users is covered in the next section.

Problems with "too many" groups depend upon the implementation of NFS used by the client and the server, and may be an issue only if they are different (including different revisions of the same operating system). Every NFS implementation has a limit on the number of groups that ran be passed in a credentials structure for an NFS RPC. Ibis number usually agrees with the maximum number of groups to which a user may belong, but it may be smaller. Typically, the limit on the number of groups is either 8 or 16. If the client's group limit is larger than the server's, and a user is in more groups than the server allows, then the server's attempt to parse and verify the credential structure will fail, yielding error messages like:

RPC: Authentication error

Authentication errors may occur when trying to mount a filesystem, in which case the superuser is in too many groups. Errors may also occur when a particular user tries to access files on the NFS server; these errors result from any NFS RPC operation. Pay particular attention to the group file in a heterogeneous environment, where the Nis-managed group map may be appended to a local file with several entries for common users like root and bin. The only solution is to restrict the number of groups to the smallest value allowed by all systems that are running NFS.

Superuser Mapping

The superuser is not given normal file access permissions to NFS-mounted files. The motivation behind this restriction is that root access should be granted on a per-machine basis. A user who is capable of becoming root on one machine should not necessarily have permission to modify files on a file server. Similarly, a setuid program that assumes root privileges may not function properly or as expected if it is allowed to operate on remote files.

To enforce restrictions on superuser access, the roof s UID is mapped to the anonymous user nobody in the NFS RPC credential structure. The superuser frequently has fewer permissions than a non-privileged user for NFS-mounted filesystems, since nobody's group usually includes no other users. in the password file, nobody has a UID of -2, and the group nogroup also has a GID of -2. On systems that require non-negative user and group ID values, nobody and nogroup use a 16-bit unsigned representation of -2. When an executable that 65534, which is is setuid runs, its effective user ID is root, which gets mapped to nobody. The executable still has permissions on the local system, but it cannot get to remote files unless they have been explicitly exported with root access enabled.

Some implementations of NFS allow the root UID mapping to be defeated by changing the UID used for nobody in the server's kernel. Changing the UID for nobody from -2 to 0 allows the superuser to access all files exported from the server, which may be less restrictive than desired. The mapping may be changed by simply modifying the UD and GID of the nobody user in the server's password file:

nobody:*:0:0:Anonymous user::

Changing nobody's UID affects every filesystem exported from the server, and should be considered as much an invitation for trouble as providing the root password to users that mount filesystems from the server.

Most NFS servers grant root permission on an exported filesystem on a per-host basis using the root=export option. The server exporting a filesystem grants root access to a host or list of hosts by including them in the /etc/exports file:

/home/work -root=bitatron:corvette

superuser on hosts bitatron and corvette is given normal root filesystem privileges on the server's /home/work directory. The name of a netgroup may be substituted for a hostname; all of the hosts in the netgroup are granted root access.

Root permissions on a remote filesystem should be extended only when absolutely necessary. While privileged users may find it annoying to have to log into the server owning a filesystem in order to modify something owned by root, this restriction also eliminates many common mistakes. If a system administrator wants to purge /usr/local on one host (to rebuild it, for example), executing rm -rf * will have disastrous consequences if there is an NFS-mounted filesystem with root permission under /usr/local. If /usr/local/bin is NFS mounted, then it is possible to wipe out the server's copy of this directory from a client when root permissions are extended over the network.

The only clear-cut case where root permissions should be extended on an NFS filesystem is for the root and swap partitions of a diskless client, where they are mandatory. One other possible scenario in which root permissions are useful is...

Meet the Author

Mike Eisler graduated from the University of Central Florida with a master's degree in computer science in 1985. His first exposure to NFS and NIS came while working for Lachman Associates, Inc., where he was responsible for porting NFS and NIS to System V platforms. He later joined Sun Microsystems, Inc., responsible for projects such as NFS server performance, NFS/TCP, WebNFS, NFS secured with Kerberos V5, NFS Version 4, and JavaCard security. Mike has authored or coauthored several Request For Comments documents for the Internet Engineering Task Force, relating to NFS and security. He is currently a Technical Director at Network Appliance, Inc.

Ricardo Labiaga is a staff engineer at Sun Microsystems, Inc., where he concentrates on networking and wireless technologies. Ricardo spent 8 years in the Solaris NFS group at Sun, where he worked on a variety of development projects with a primary focus on automounting and the NFS server. Ricardo is responsible for implementing significant functionality and performance enhancements to the automounter, as well as leading the NFS Server Logging design team. He holds a master of science degree in computer engineering from The University of Texas at El Paso.

Hal Stern is a technical consultant with Sun Microsystems, where he specializes in networking, performance tuning, and kernel hacking. Hal earned a Bachelor of Science degree from Princeton University in 1984. Before joining Sun, Hal was a member of the technical staff at Polygen Corporation, developing UNIX-based molecular modelling and chemical information system products. Hal also worked on the Massive Memory Machine project as a member of the Research Staff in Princeton University's Department of Computer Science. His interests include large installation system administration, virtual memory management systems, performance, local and wide-area networking, interactive graphics, applications in financial services, cosmology, and the history of science. Hal is active in the Sun User's Group and has served on the advisory trustee board of the Princeton Broadcasting Service for seven years. Hal and his wife Toby live in Burlington, Massachusetts. At home, Hal enjoys carpentry, jazz music, cooking, and watching the stock market.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >

Managing NFS and NIS 4 out of 5 based on 0 ratings. 2 reviews.
Anonymous More than 1 year ago
T.T
Anonymous More than 1 year ago
Welcome agent to S.H.E.I.L.D. I can not tell you what Sheild stands for but I can tell you what we do. We serve and protect our country when all else fails. We are our county's sheild when superheroes and the army are occupied. We are a secret agency who has protected many things (( even alien )) from the public. We have encountered aliems to mythical beings like Thor. Well...that' s all the time I have left. I have included a map and a list of rules below. I hope you join and I can't wait to see you. <p> Map: Res1- Map / Res2- NewComers Room / Res3- Lounge / Res4- Briefing room / Res5- Jumbo jet / Res7- Weaponry / Res8- The Freezer / the rest of the res vary. <p> RULES: - NO auto killz / NO godmodding / NO moving up ranks unless consulting with the leader of Sheild / No making up missions .