O'Reilly - Practical UNIX & Internet Sec... 7015KB

[Chapter 20] 20.4 Improving NFS Security
only to the hosts named in the union of the two lists. There is no -access option in SVR4.
20.4.2 Export Read-only
Many filesystems contain information that is only read, never (or rarely) written. These filesystems can be exported read-only.
Exporting the filesystems read-only adds to both security and reliability: it prevents the filesystems from being modified by NFS
clients, limiting the damage that can be done by attackers, ignorant users, and buggy software.
Many kinds of filesystems are candidates for read-only export:
●
●
●
Filesystems containing applications
Organizational reference matter, such as policies and documents
Netnews (if you do not read news with NNTP)
If you have programs or other files that must be exported read-write, you can improve your system's overall performance, reliability,
and security by placing these items on their own filesystem that is separately exported.
To export a filesystem read-only, specify the ro=clients option in either your exports file or your dfstab file (depending on which
version of UNIX you are using). In the following example, the /LocalLibrary directory is exported read-only:
share -F nfs -o ro=clients /LocalLibrary
20.4.3 Use Root Ownership
Because the NFS server maps root to nobody, you can protect files and directories on your server by setting their owner to root and
their protection mode to 755 (in the case of programs and directories) or 644 (in the case of data files). This setup will prevent the
contents of the files from being modified by a client machine.
If you have information on an NFS server that should not be accessible to NFS clients, you can use the file protection mode 700 (in
the case of programs and directories) or 600 (in the case of data files). However, a better strategy is not to place the files on the NFS
server in the first place.
Remember, this system protects only files on the server that are owned by root. Also, this technique does not work if you have
patched your kernel to set the value of nobody to 0, or if you export the filesystems to a particular host with the -root= option.
NOTE: Protecting an executable file to be execute-only will not work as you expect in an NFS environment. Because
you must read a file into memory before it can be executed, any file marked executable can also be read from a server
using NFS commands (although it may not be possible to do so using standard calls through a client). The server has no
way of knowing if the requests to be read are a prelude to execution or not. Thus, putting execute-only files on an
exported partition may allow them to be examined or copied from a client machine.
20.4.4 Remove Group-write Permission for Files and Directories
If you are using standard AUTH_UNIX authentication with NFS, then users can effectively place themselves in any group. Thus, to
protect files and directories that are owned by root, they must not be group-writable.
20.4.5 Do Not Export Server Executables
If your server is running the same operating system on the same CPU architecture as your client computers, then you might be
tempted to have the server export its own executables (such as the programs stored in /bin, /usr/bin, /etc.) for use by the clients. Don't
do so without careful thought about the consequences.
At first, exporting a server's own executables seems like a good way to save disk space: this way, you only need to have one copy of
each program, which is then shared between the clients and the servers, rather than two copies.
But exporting your server's executables poses several security problems:
●
●
It allows an attacker to easily determine which version of each executable your server is running, which enables the attacker to
probe for weak spots with greater ease.
If there is an error in your system's configuration, you may be exporting the binaries on a writable filesystem. An attacker
file:///C|/Oreilly Unix etc/O'Reilly Reference Library/networking/puis/ch20_04.htm (3 of 6) [2002-04-12 10:45:41]