rpc.gssd(8) | System Manager's Manual | rpc.gssd(8) |
rpc.gssd - RPCSEC_GSS daemon
rpc.gssd [-DfMnlvrHC] [-k keytab] [-p pipefsdir] [-d ccachedir] [-t timeout] [-T timeout] [-U timeout] [-R realm]
The RPCSEC_GSS protocol, defined in RFC 5403, is used to provide strong security for RPC-based protocols such as NFS.
Before exchanging RPC requests using RPCSEC_GSS, an RPC client must establish a GSS security context. A security context is shared state on each end of a network transport that enables GSS-API security services.
Security contexts are established using security credentials. A credential grants temporary access to a secure network service, much as a railway ticket grants temporary access to use a rail service.
A user typically obtains a credential by providing a password to the kinit(1) command, or via a PAM library at login time. A credential acquired with a user principal is known as a user credential (see kerberos(1) for more on principals).
Certain operations require a credential that represents no particular user or represents the host itself. This kind of credential is called a machine credential.
A host establishes its machine credential using a service principal whose encrypted password is stored in a local file known as a keytab. A machine credential remains effective without user intervention as long as the host can renew it.
Once obtained, credentials are typically stored in local temporary files with well-known pathnames.
To establish GSS security contexts using these credential files, the Linux kernel RPC client depends on a userspace daemon called rpc.gssd. The rpc.gssd daemon uses the rpc_pipefs filesystem to communicate with the kernel.
When a user authenticates using a command such as kinit(1), the resulting credential is stored in a file with a well-known name constructed using the user's UID.
To interact with an NFS server on behalf of a particular Kerberos-authenticated user, the Linux kernel RPC client requests that rpc.gssd initialize a security context with the credential in that user's credential file.
Typically, credential files are placed in /tmp. However, rpc.gssd can search for credential files in more than one directory. See the description of the -d option for details.
rpc.gssd searches the default keytab, /etc/krb5.keytab, in the following order for a principal and password to use when establishing the machine credential. For the search, rpc.gssd replaces <hostname> and <REALM> with the local system's hostname and Kerberos realm.
<HOSTNAME>$@<REALM>
root/<hostname>@<REALM>
nfs/<hostname>@<REALM>
host/<hostname>@<REALM>
root/<anyname>@<REALM>
nfs/<anyname>@<REALM>
host/<anyname>@<REALM>
rpc.gssd selects one of the <anyname> entries if it does not find a service principal matching the local hostname, e.g. if DHCP assigns the local hostname dynamically. The <anyname> facility enables the use of the same keytab on multiple systems. However, using the same service principal to establish a machine credential on multiple hosts can create unwanted security exposures and is therefore not recommended.
Note that <HOSTNAME>$@<REALM> is a user principal that enables Kerberized NFS when the local system is joined to an Active Directory domain using Samba. The keytab provides the password for this principal.
You can specify a different keytab by using the -k option if /etc/krb5.keytab does not exist or does not provide one of these principals.
UID 0 is a special case. By default rpc.gssd uses the system's machine credentials for UID 0 accesses that require GSS authentication. This limits the privileges of the root user when accessing network resources that require authentication.
Specify the -n option when starting rpc.gssd if you'd like to force the root user to obtain a user credential rather than use the local system's machine credential.
When -n is specified, the kernel continues to request a GSS context established with a machine credential for NFSv4 operations, such as SETCLIENTID or RENEW, that manage state. If rpc.gssd cannot obtain a machine credential (say, the local system has no keytab), NFSv4 operations that require machine credentials will fail.
A realm administrator can choose to add keys encoded in a number of different encryption types to the local system's keytab. For instance, a host/ principal might have keys for the aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, and arcfour-hmac encryption types. This permits rpc.gssd to choose an appropriate encryption type that the target NFS server supports.
These encryption types are stronger than legacy single-DES encryption types. To interoperate in environments where servers support only weak encryption types, you can restrict your client to use only single-DES encryption types by specifying the -l option when starting rpc.gssd.
If -D is present, a reverse DNS lookup will always be used, even if the server name looks like a canonical name. So it is needed if partially qualified, or non canonical names are regularly used.
Using -D can introduce a security vulnerability, so it is recommended that -D not be used, and that canonical names always be used when requesting services.
If -H is not set, rpc.gssd will use the first match found in /var/kerberos/krb5/user/$EUID/client.keytab and will not use a principal based on host and/or service parameters listed in $HOME/.k5identity.
Many of the options that can be set on the command line can also be controlled through values set in the [gssd] section of the /etc/nfs.conf configuration file. Values recognized include:
In addtion, the following value is recognized from the [general] section:
Dug Song <dugsong@umich.edu>
Andy Adamson <andros@umich.edu>
Marius Aamodt Eriksen <marius@umich.edu>
J. Bruce Fields <bfields@umich.edu>
20 Feb 2013 |