Secure NFS

The NFS environment is a powerful and convenient way to share file systems on a network of different computer architectures and operating systems. However, the same features that make sharing file systems through NFS operation convenient also pose some security problems. An NFS server authenticates a file request by authenticating the computer making the request, but not the user when using UNIX authentication. When using UNIX authentication, a client user can run su and impersonate the owner of a file. If DES authentication is used, the NFS server will authenticate the user, making this sort of impersonation much harder.

Given root access and knowledge of network programming, anyone is capable of introducing arbitrary data into the network and picking up any data from the network. The most dangerous attacks are those involving the introduction of data, such as impersonating a user by generating the right packets or

recording "conversations" and replaying them later. These attacks affect data integrity. Attacks involving passive eavesdropping--merely listening to network traffic without impersonating anybody--are not as dangerous, since data integrity is not compromised. Users can protect the privacy of sensitive information by encrypting data that goes over the network.

A common approach to network security problems is to leave the solution to each application. A better approach is to implement a standard authentication system at a level that covers all applications.

The Solaris operating system includes an authentication system at the level of remote procedure call (RPC)--the mechanism on which NFS operation is built. This system, known as Secure RPC, greatly improves the security of network environments and provides additional security to services such as the NFS system. When the NFS system uses the facilities provided by Secure RPC, it is known as Secure NFS.

Secure RPC

Secure RPC is fundamental to Secure NFS. The goal of Secure RPC is to build a system at least as secure as a time-sharing system (one in which all users share a single computer). A time-sharing system authenticates a user through a login password. With Data Encryption Standard (DES) authentication, the same is true. Users can log in on any remote computer just as they can on a local terminal, and their login passwords are their passports to network security. In a time-sharing environment, the system administrator has an ethical obligation not to change a password in order to impersonate someone. In Secure RPC, the network administrator is trusted not to alter entries in a database that stores public keys.

You need to be familiar with two terms to understand an RPC authentication system: credentials and verifiers. Using ID badges as an example, the credential is what identifies a person: a name, address, birthday, and so on. The verifier is the photo attached to the badge: you can be sure the badge has not been stolen by checking the photo on the badge against the person carrying it. In RPC, the client process sends both a credential and a verifier to the server with each RPC request. The server sends back only a verifier because the client already knows the server's credentials.

RPC's authentication is open ended, which means that a variety of authentication systems may be plugged into it. Currently, there are three systems: UNIX, DES, and KERB (for Kerberos Version 4).

When UNIX authentication is used by a network service, the credentials contain the client's hostname, UID, GID, and group-accesslist, but the verifier contains nothing. Because there is no verifier, a superuser could deduce appropriate credentials, using commands such as su. Another problem with UNIX authentication is that it assumes all computers on a network are UNIX computers. UNIX authentication breaks down when applied to other operating systems in a heterogeneous network.

To overcome the problems of UNIX authentication, Secure RPC uses DES authentication--a scheme that employs verifiers, yet allows Secure RPC to be general enough to be used by most operating systems.

DES Authentication

DES authentication uses the Data Encryption Standard (DES) and Diffie-Hellman public-key cryptography to authenticate both users and computers in the network. DES is a standard encryption mechanism; Diffie-Hellman public-key cryptography is a cipher system that involves two keys: one public and one secret. The public and secret keys are stored in the namespace. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These maps contain the public key and secret key for all potential users. See System Administration Guide, Volume I, for more information on how to set up the maps and tables.

The security of DES authentication is based on a sender's ability to encrypt the current time, which the receiver can then decrypt and check against its own clock. The time stamp is encrypted with DES. There are two requirements for this scheme to work:

• The two agents must agree on the current time
• The sender and receiver must be using the same encryption key

If a network runs a time-synchronization program, then the time on the client and the server is synchronized automatically. If a time synchronization program is not available, time stamps can be computed using the server's time instead of the network time. The client asks the server for the time before starting the RPC session, then computes the time difference between its own clock and the server's. This difference is used to offset the client's clock when

computing time stamps. If the client and server clocks get out of sync to the point where the server begins to reject the client's requests, the DES authentication system on the client resynchronizes with the server.

The client and server arrive at the same encryption key by generating a random conversation key, also known as the session key, and then using public-key cryptography to deduce a common key. The common key is a key that only the client and server are capable of deducing. The conversation key is used to encrypt and decrypt the client's time stamp; the common key is used to encrypt and decrypt the conversation key.

KERB Authentication

Kerberos is an authentication system developed at MIT. Encryption in Kerberos is based on DES.

Kerberos works by authenticating the user's login password. A user types the kinit command, which obtains a ticket that is valid for the time of the session (or eight hours, the default session time) from the authentication server. When the user logs out, the ticket may be destroyed using the kdestroy command.

The Kerberos server software is available from MIT Project Athena, and is not part of the SunOS software. SunOS software provides

• Routines used by the client to create, acquire, and verify tickets
• An authentication option to Secure RPC
• A client-side daemon, kerbd

See System Administration Guide, Volume I, for more details.

AUTH_DES Client-Server Session

This section describes the series of transactions in a client-server session using DES authorization (AUTH_DES).

Generating the public and secret keys Sometime prior to a transaction, the administrator runs a program, either newkey or nisaddcred that generates a public key and a secret key. (Each user has a unique public key and secret key.) The public key is stored in a public database; the secret key is stored in encrypted form, in the same database. To change the key pair, use the chkey command.

Running keylogin

Normally, the login password is identical to the secure RPC password. In this case, a keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin explicitly.

The keylogin program prompts the user for a secure RPC password and uses the password to decrypt the secret key. The keylogin program then passes the decrypted secret key to a program called the keyserver. (The keyserver is an RPC service with a local instance on every computer.) The keyserver saves the decrypted secret key and waits for the user to initiate a secure RPC transaction with a server.

If the passwords are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different and the user must always run keylogin, then the keylogin program may be included in the user's environment configuration file, such as ~/.login, ~/.cshrc, or ~/.profile, so that it runs automatically whenever the user logs in.

Generating the Conversation Key When the user initiates a transaction with a server:

1. The keyserver randomly generates a conversation key.

2. The kernel uses the conversation key to encrypt the client's time stamp (among other things).

3. The keyserver looks up the server's public key in the public-key database (see the publickey(4) man page).

4. The keyserver uses the client's secret key and the server's public key to create a common key.

5. The keyserver encrypts the conversation key with the common key.

First Contact with the Server

The transmission including the encrypted time stamp and the encrypted conversation key is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:

• The client's net name
• The conversation key, encrypted with the common key
• A "window," encrypted with the conversation key

The window is the difference the client says should be allowed between the server's clock and the client's time stamp. If the difference between the server's clock and the time stamp is greater than the window, the server would reject the client's request. Under normal circumstances this will not happen because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains:

• The encrypted time stamp
• An encrypted verifier of the specified window, decremented by 1

The window verifier is needed in case somebody wants to impersonate a user and writes a program that, instead of filling in the encrypted fields of the credential and verifier, just stuffs in random bits. The server will decrypt the conversation key into some random key and use it to try to decrypt the window and the time stamp. The result will be random numbers. After a few thousand trials, however, there is a good chance that the random window/time stamp pair will pass the authentication system. The window verifier makes guessing the right credential much more difficult.

Decrypting the Conversation Key

When the server receives the transmission from the client:

1. The keyserver local to the server looks up the client's public key in the publickey database.

2. The keyserver uses the client's public key and the server's secret key to deduce the common key--the same common key computed by the client. (Only the server and the client can calculate the common key because doing so requires knowing one secret key or the other.)

3. The kernel uses the common key to decrypt the conversation key.

4. The kernel calls the keyserver to decrypt the client's time stamp with the decrypted conversation key.

Storing Information on the Server

After the server decrypts the client's time stamp, it stores four items of information in a credential table:

• The client's computer name

• The conversation key
• The window
• The client's time stamp

The server stores the first three items for future use. It stores the time stamp to protect against replays. The server accepts only time stamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected.

---

Note - Implicit in these procedures is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to do this because it would create a deadlock. To solve this problem, the keyserver stores the secret keys by UID and grants requests only to local root processes.

---

Verifier Returned to the Client

The server returns a verifier to the client, which includes:

• The index ID, which the server records in its credential cache
• The client's time stamp minus 1, encrypted by conversation key

The reason for subtracting 1 from the time stamp is to ensure that the time stamp is invalid and cannot be reused as a client verifier.

Client Authenticates the Server The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what time stamp the client sent.

Additional Transactions

With every transaction after the first, the client returns the index ID to the server in its second transaction and sends another encrypted time stamp. The server sends back the client's time stamp minus 1, encrypted by the conversation key.

You should be aware of the following points if you plan to use Secure RPC:

• If a server crashes when no one is around (after a power failure for example), all the secret keys that are stored on the system are wiped out. Now no process is able to access secure network services or mount an NFS

file system. The important processes during a reboot are usually run as root, so things would work if root's secret key were stored away, but nobody is available to type the password that decrypts it. keylogin -r allows root to store the clear secret key in /etc/.rootkey which keyserv reads.

• Some systems boot in single-user mode, with a root login shell on the console and no password prompt. Physical security is imperative in such cases.
• Diskless computer booting is not totally secure. Somebody could impersonate the boot server and boot a devious kernel that, for example, makes a record of your secret key on a remote computer. Secure NFS provides protection only after the kernel and the keyserver are running. Before that, there is no way to authenticate the replies given by the boot server. This could be a serious problem, but it requires a sophisticated attack, using kernel source code. Also, the crime would have evidence. If you polled the network for bootservers, you would discover the devious bootserver's location.
• Most setuid programs are owned by root; if root's secret key is stored in /etc/.rootkey, these programs behave as they always have. If a setuid program is owned by a user, however, it may not always work. For example, if a setuid program is owned by dave and dave has not logged into the computer since it booted, then the program would not be able to access secure network services.
• If you log in to a remote computer (using login, rlogin, or telnet) and use keylogin to gain access, you give away access to your account. This is because your secret key gets passed to that computer's keyserver, which then stores it. This is only a concern if you don't trust the remote computer. If you have doubts, however, don't log in to a remote computer if it requires a password. Instead, use the NFS environment to mount file systems shared by the remote computer. As an alternative, you can use keylogout to delete the secret key from the keyserver.
• If a home directory is shared with the -o secure or -o kerberos options, then remote logins can be a problem. If the /etc/hosts.equiv or ~/.rhosts files are set to not prompt for a password, the login will succeed, but the user will not be able to access their home directory since no authentication has occurred locally. If the user is prompted for a password, then as long as the password matches the network password, the user will have access to their home directory.

Administering Secure NFS

To use Secure NFS, all the computers you are responsible for must have a domain name. A domain is an administrative entity, typically consisting of several computers, that joins a larger network. If you are running NIS+, you should also establish the NIS+ name service for the domain. See NIS+ and DNS Setup and Configuration Guide.

With UNIX authentication a universal flat name space is assumed. UIDs are normally unique within a domain but may not be unique across domains. A problem with this scheme is that UIDs clash when domains are linked across the network. Another problem with UNIX authentication has to do with superusers; with UNIX authentication, the superuser ID (UID 0) is in effect assigned one per computer, not one per domain. Therefore, a domain can have multiple superusers--all with the same UNIX UID.

DES authentication corrects these problems by using netnames. A netname is a string of printable characters created by concatenating the name of the operating system, a user ID, and a domain name. For example, a UNIX system user with a user ID of 508 in the domain eng.acme.com would be assigned the following netname unix.508@eng.acme.com. Because user IDs must be unique within a domain and because domain names must be unique on a network, this scheme produces a unique netname for every user.

To overcome the problem of multiple superusers per domain, netnames are assigned to computers as well as to users. A computer's netname is formed much like a user's--by concatenating the name of the operating system and the computer name with the domain name. The root user on a UNIX computer named hal in the domain eng.acme.com would have the netname unix.hal@eng.acme.com.

· How to Set Up Secure NFS

1. Assign your domain a domain name, and make the domain name known to each computer in the domain.

   See the NIS+ and FNS Administration Guide if you are using NIS+ as your name service.

2. Establish public keys and secret keys for your clients' users using the

   newkey or nisaddcred command, and have each user establish his or her own secure RPC password using the chkey command.

---

Note - For information about these commands, see the newkey(1M), the nisaddcred(1M), and the chkey(1) man pages.

---

When public and secret keys have been generated, the public and encrypted secret keys are stored in the publickey database.

3. Verify that the name service is responding. If you are running NIS+, type the following:

# nisping -u Last updates for directory eng.acme.com. : Master server is eng-master.acme.com. Last update occurred at Mon Jun 5 11:16:10 1995 Replica server is eng1-replica-replica-58.acme.com. Last Update seen was Mon Jun 5 11:16:10 1995

If you are running NIS, verify that the ypbind daemon is running.

4. Verify that the keyserv daemon (the keyserver) is running, type the following:

# ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv

If it isn't running, to start the keyserver, type the following:

# /usr/sbin/keyserv

5. Run keylogin to decrypt and store the secret key. Usually, the login password is identical to the network password. In this case, keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin. You still need to use the keylogin -r command as root to store the decrypted secret key in /etc/.rootkey.

---

Note - keylogin -r will only need to be run if the root secret key changes or /etc/.rootkey is lost.

---

6. Edit the /etc/dfs/dfstab file and add the secure option to the appropriate entries (for DES authentication).

# share -F nfs -o secure /export/home

For KERB authentication, add the kerberos option.

# share -F nfs -o kerberos /export/home

7. Edit the auto_master data to include secure as a mount option in the appropriate entries (for DES authentication):

/home auto_home -nosuid,secure

For KERB authentication, add the kerberos option.

/home auto_home -nosuid,kerberos

---

Note - With Version 2 NFS software, if a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves. With Version 3, the secure flag will be inherited from the NFS server, so there is no need for the clients to specify kerberos or secure. The users will have access to the files as themselves.

---

When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you don't establish new keys or change them for root. If you do delete /etc/.rootkey, you can always type:

# keylogin -r