Administering the Secure NFS System

To use the Secure NFS system, all the computers that you are responsible for must have a domain name. Typically, a domain is an administrative entity of several computers that is part of a larger network. If you are running a name service, you should also establish the name service for the domain. See System Administration Guide: Naming and Directory Services (NIS+).

Kerberos V5 authentication is supported by the NFS service. Chapter 20, Introduction to the Kerberos Service, in System Administration Guide: Security Services discusses the Kerberos service.

You can also configure the Secure NFS environment to use Diffie-Hellman authentication. Chapter 15, Using Authentication Services (Tasks), in System Administration Guide: Security Services discusses this authentication service.

The following procedure shows you how to use the sharemgr utility to set up a secure NFS environment with DH authentication. The example that follows the procedure shows you how to use the share command to complete the same task.

How to Set Up a Secure NFS Environment With DH Authentication

Starting with the Solaris Express, Developer Edition 2/07 release, you can do the following:

Use the sharemgr utility to share file systems, set property values for the shared file systems, and perform related tasks. For information about sharemgr, including descriptions of subcommands and properties, see the sharemgr(1M) man page and sharemgr Command.
Use the sharectl utility to configure file-sharing protocols, such as NFS. See the sharectl(1M) man page and sharectl Command.

Note - When you use sharemgr, you do not need to use the share, shareall, and unshare commands. Also, you do not need to edit the /etc/dfs/dfstab file.

The following procedure uses the sharemgr utility. If you prefer to use the share utility, see the example that follows this procedure.

Assign your domain a domain name, and make the domain name known to each computer in the domain.
See the System Administration Guide: Naming and Directory Services (NIS+) if you are using NIS+ as your name service.
Establish public keys and secret keys for your clients' users by using the newkey or nisaddcred command. Have each user establish his or her own secure RPC password by 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 keys and secret keys have been generated, the public keys and encrypted secret keys are stored in the publickey database.

Verify that the name service is responding.

For example:

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 2006

Replica server is eng1-replica-replica-58.acme.com.
        Last Update seen was Mon Jun  5 11:16:10 2006

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

Verify that the keyserv daemon of the key server is running.

Type the following command.

# 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 the daemon is not running, start the key server by typing the following:

# /usr/sbin/keyserv

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

Note - You need to run keylogin -r if the root secret key changes or if /etc/.rootkey is lost.
Use the sharemgr utility to set the security mode for the file system to be shared.
For example:
```
# sharemgr set -P nfs -S dh MyShareGroup
```
-P

Use this option to specify a file-system type, such as nfs.

-S

Use this option to specify a security mode, such as sys, dh, or krb5. For more information about security modes, see the nfssec(5) man page.

MyShareGroup

Use the name of the share group that you created. For more information, see the sharemgr(1M) man page or sharemgr Command

Note - You do not need to edit the etc/dfs/dfstab file.
Update the automounter maps for the file system.
Edit the auto_master data to include sec=dh as a mount option in the appropriate entries for Diffie-Hellman authentication:
```
/home    auto_home    -nosuid,sec=dh
```
Note - Releases through Solaris 2.5 have a limitation. If a client does not securely mount a shared file system that is secure, users have access as nobody rather than as themselves. For subsequent releases that use version 2, the NFS server refuses access if the security modes do not match, unless sec=none is included on the share command line. With version 3, the mode is inherited from the NFS server, so clients do not need to specify sec=dh. The users have access to the files as themselves.

When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you do not establish new keys or change the keys for root. If you do delete /etc/.rootkey, you can always type the following:
```
# keylogin -r
```

Example 5-6 How to Use the share Command to Set Up a Secure NFS Environment With DH Authentication

Assign your domain a domain name, and make the domain name known to each computer in the domain.
See the System Administration Guide: Naming and Directory Services (NIS+) if you are using NIS+ as your name service.
Establish public keys and secret keys for your clients' users by using the newkey or nisaddcred command. Have each user establish his or her own secure RPC password by 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 keys and secret keys have been generated, the public keys and encrypted secret keys are stored in the publickey database.

Verify that the name service is responding.

For example:

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 2006

Replica server is eng1-replica-replica-58.acme.com.
        Last Update seen was Mon Jun  5 11:16:10 2006

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

Verify that the keyserv daemon of the key server is running.

Type the following command.

# 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 the daemon is not running, start the key server by typing the following:

# /usr/sbin/keyserv

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

Note - You need to run keylogin -r if the root secret key changes or if /etc/.rootkey is lost.
Update mount options for the file system.
For Diffie-Hellman authentication, edit the /etc/dfs/dfstab file and add the sec=dh option to the appropriate entries.
```
share -F nfs -o sec=dh /export/home
```
See the dfstab(4) man page for a description of /etc/dfs/dfstab.
Update the automounter maps for the file system.
Edit the auto_master data to include sec=dh as a mount option in the appropriate entries for Diffie-Hellman authentication:
```
/home    auto_home    -nosuid,sec=dh
```
Note - Releases through Solaris 2.5 have a limitation. If a client does not securely mount a shared file system that is secure, users have access as nobody rather than as themselves. For subsequent releases that use version 2, the NFS server refuses access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode is inherited from the NFS server, so clients do not need to specify sec=dh. The users have access to the files as themselves.

When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you do not establish new keys or change the keys for root. If you do delete /etc/.rootkey, you can always type the following:
```
# keylogin -r
```