формат fstab и параметры для файловых систем nfs (fstab format and options for the nfs file systems)
SECURITY CONSIDERATIONS
NFS servers control access to file data, but they depend on their
RPC implementation to provide authentication of NFS requests.
Traditional NFS access control mimics the standard mode bit
access control provided in local file systems. Traditional RPC
authentication uses a number to represent each user (usually the
user's own uid), a number to represent the user's group (the
user's gid), and a set of up to 16 auxiliary group numbers to
represent other groups of which the user may be a member.
Typically, file data and user ID values appear unencrypted (i.e.
"in the clear") on the network. Moreover, NFS versions 2 and 3
use separate sideband protocols for mounting, locking and
unlocking files, and reporting system status of clients and
servers. These auxiliary protocols use no authentication.
In addition to combining these sideband protocols with the main
NFS protocol, NFS version 4 introduces more advanced forms of
access control, authentication, and in-transit data protection.
The NFS version 4 specification mandates support for strong
authentication and security flavors that provide per-RPC
integrity checking and encryption. Because NFS version 4
combines the function of the sideband protocols into the main NFS
protocol, the new security features apply to all NFS version 4
operations including mounting, file locking, and so on. RPCGSS
authentication can also be used with NFS versions 2 and 3, but it
does not protect their sideband protocols.
The sec mount option specifies the security flavor used for
operations on behalf of users on that NFS mount point.
Specifying sec=krb5 provides cryptographic proof of a user's
identity in each RPC request. This provides strong verification
of the identity of users accessing data on the server. Note that
additional configuration besides adding this mount option is
required in order to enable Kerberos security. Refer to the
rpc.gssd(8) man page for details.
Two additional flavors of Kerberos security are supported: krb5i
and krb5p. The krb5i security flavor provides a
cryptographically strong guarantee that the data in each RPC
request has not been tampered with. The krb5p security flavor
encrypts every RPC request to prevent data exposure during
network transit; however, expect some performance impact when
using integrity checking or encryption. Similar support for
other forms of cryptographic security is also available.
NFS version 4 filesystem crossing
The NFS version 4 protocol allows a client to renegotiate the
security flavor when the client crosses into a new filesystem on
the server. The newly negotiated flavor effects only accesses of
the new filesystem.
Such negotiation typically occurs when a client crosses from a
server's pseudo-fs into one of the server's exported physical
filesystems, which often have more restrictive security settings
than the pseudo-fs.
NFS version 4 Leases
In NFS version 4, a lease is a period during which a server
irrevocably grants a client file locks. Once the lease expires,
the server may revoke those locks. Clients periodically renew
their leases to prevent lock revocation.
After an NFS version 4 server reboots, each client tells the
server about existing file open and lock state under its lease
before operation can continue. If a client reboots, the server
frees all open and lock state associated with that client's
lease.
When establishing a lease, therefore, a client must identify
itself to a server. Each client presents an arbitrary string to
distinguish itself from other clients. The client administrator
can supplement the default identity string using the
nfs4.nfs4_unique_id module parameter to avoid collisions with
other client identity strings.
A client also uses a unique security flavor and principal when it
establishes its lease. If two clients present the same identity
string, a server can use client principals to distinguish between
them, thus securely preventing one client from interfering with
the other's lease.
The Linux NFS client establishes one lease on each NFS version 4
server. Lease management operations, such as lease renewal, are
not done on behalf of a particular file, lock, user, or mount
point, but on behalf of the client that owns that lease. A
client uses a consistent identity string, security flavor, and
principal across client reboots to ensure that the server can
promptly reap expired lease state.
When Kerberos is configured on a Linux NFS client (i.e., there is
a /etc/krb5.keytab on that client), the client attempts to use a
Kerberos security flavor for its lease management operations.
Kerberos provides secure authentication of each client. By
default, the client uses the host/ or nfs/ service principal in
its /etc/krb5.keytab for this purpose, as described in
rpc.gssd(8).
If the client has Kerberos configured, but the server does not,
or if the client does not have a keytab or the requisite service
principals, the client uses AUTH_SYS and UID 0 for lease
management.
Using non-privileged source ports
NFS clients usually communicate with NFS servers via network
sockets. Each end of a socket is assigned a port value, which is
simply a number between 1 and 65535 that distinguishes socket
endpoints at the same IP address. A socket is uniquely defined
by a tuple that includes the transport protocol (TCP or UDP) and
the port values and IP addresses of both endpoints.
The NFS client can choose any source port value for its sockets,
but usually chooses a privileged port. A privileged port is a
port value less than 1024. Only a process with root privileges
may create a socket with a privileged source port.
The exact range of privileged source ports that can be chosen is
set by a pair of sysctls to avoid choosing a well-known port,
such as the port used by ssh. This means the number of source
ports available for the NFS client, and therefore the number of
socket connections that can be used at the same time, is
practically limited to only a few hundred.
As described above, the traditional default NFS authentication
scheme, known as AUTH_SYS, relies on sending local UID and GID
numbers to identify users making NFS requests. An NFS server
assumes that if a connection comes from a privileged port, the
UID and GID numbers in the NFS requests on this connection have
been verified by the client's kernel or some other local
authority. This is an easy system to spoof, but on a trusted
physical network between trusted hosts, it is entirely adequate.
Roughly speaking, one socket is used for each NFS mount point.
If a client could use non-privileged source ports as well, the
number of sockets allowed, and thus the maximum number of
concurrent mount points, would be much larger.
Using non-privileged source ports may compromise server security
somewhat, since any user on AUTH_SYS mount points can now pretend
to be any other when making NFS requests. Thus NFS servers do
not support this by default. They explicitly allow it usually
via an export option.
To retain good security while allowing as many mount points as
possible, it is best to allow non-privileged client connections
only if the server and client both require strong authentication,
such as Kerberos.
Mounting through a firewall
A firewall may reside between an NFS client and server, or the
client or server may block some of its own ports via IP filter
rules. It is still possible to mount an NFS server through a
firewall, though some of the mount(8) command's automatic service
endpoint discovery mechanisms may not work; this requires you to
provide specific endpoint details via NFS mount options.
NFS servers normally run a portmapper or rpcbind daemon to
advertise their service endpoints to clients. Clients use the
rpcbind daemon to determine:
What network port each RPC-based service is using
What transport protocols each RPC-based service supports
The rpcbind daemon uses a well-known port number (111) to help
clients find a service endpoint. Although NFS often uses a
standard port number (2049), auxiliary services such as the NLM
service can choose any unused port number at random.
Common firewall configurations block the well-known rpcbind port.
In the absense of an rpcbind service, the server administrator
fixes the port number of NFS-related services so that the
firewall can allow access to specific NFS service ports. Client
administrators then specify the port number for the mountd
service via the mount(8) command's mountport option. It may also
be necessary to enforce the use of TCP or UDP if the firewall
blocks one of those transports.
NFS Access Control Lists
Solaris allows NFS version 3 clients direct access to POSIX
Access Control Lists stored in its local file systems. This
proprietary sideband protocol, known as NFSACL, provides richer
access control than mode bits. Linux implements this protocol
for compatibility with the Solaris NFS implementation. The
NFSACL protocol never became a standard part of the NFS version 3
specification, however.
The NFS version 4 specification mandates a new version of Access
Control Lists that are semantically richer than POSIX ACLs. NFS
version 4 ACLs are not fully compatible with POSIX ACLs; as such,
some translation between the two is required in an environment
that mixes POSIX ACLs and NFS version 4.
