Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 6 File System Security

Controlling File Security on a Network


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

From the perspective of security, networked systems are more vulnerable than standalone systems. Networking increases system accessibility, but also adds greater risk of security violations.

Although you cannot completely control security over the network, you can control the security of each node on the network to limit penetration risk without reducing the usefulness of the system or user productivity.

Ensure that all network administration programs are owned by a protected, network-specific account, such as uucp, nso, or daemon, rather than by root.

Check Permission Settings on Network Control Files

Modes, owners, and groups on all system files are set carefully. Check these files regularly for any changes. Note and correct any changes from the original values.

Pay particular attention to the network control files in the /etc directory. These files are of notable interest to those attempting to gain unauthorized access, because they provide access to the network itself. Network control files should never be writable by the public. These files include:


List of file systems being exported to NFS clients


Network hosts and their addresses


Remote hosts allowed access equivalent to the local host


Internet configuration file


List of networkwide groups


Network names and their addresses


Protocol name database


Services name database

Files Mounted in an NFS Environment

A Network File System (NFS) provides the following conveniences:

  • Saves file space.

  • Maintains consistent file usage.

  • Provides a lean cooperative user environment.

NFS streamlines filesharing between server and client systems by controlling access via the /etc/exports file. Entries in /etc/exports provide permission to mount a file system existing on the server onto any client machine or specified list of machines. When a file system is put into /etc/exports, the information is available to anyone who can do an NFS mount. Thus, the NFS client user can access a server file system without having logged in to the server system. See exports(4) for information on controlling access to exported file systems and see Section  for security guidelines.

Server Vulnerability

Maintain server security by setting restrictive permissions on the /etc/exports file. Root privileges are not maintained across NFS. Thus, having root privileges on a client system does not provide you with special access to the server.

The server performs the same permission checking remotely for the client as it does locally for its own users. The server side controls access by the client to server files by comparing the user ID and group ID of the client, which it receives via the network, with the user ID and group ID of the server file. Checking occurs within the kernel.

A user with privileges on an NFS client can exploit that privilege to obtain unlimited access to an NFS server.

NOTE: Never export any file system to a node on which privilege is granted more leniently than in your own node's policy.

Client Vulnerability

In earlier releases of NFS for workstations, the /dev inode had to reside on the client's disk. NFS now allows the /dev inode containing the major and minor numbers of a client-mounted device special file to exist on the server side. This opens the possibility for someone to create a Trojan horse that overrides permissions set on the client's mounted device special file, by accessing the device special file through the file and inode number found on the server side.

Although lacking permission to make a device special file on the client side, a system violator can create a device special file, such as /dev/kmem, using root permissions on the server side. The new /dev file is created with the same major and minor number as that of the target device on client side, but with the following permissions:


The violator can then go to the client, log in as an ordinary user, and, using NFS, open up the newly created server-side device special file and use it for devious means.

How to Safeguard NFS-Mounted Files

Following are suggestions to safeguard NFS-mounted files:

  • If possible, make sure that the same person administers both client and server systems.

  • Maintain uniformity of user ID and group ID for server and client systems.

  • Routinely check the /dev files in the file systems exported from server.

  • Restrict who can have write access to the /etc/passwd client files.

  • For strictest control, audit every host that is accessible through the network.

  • Consider using the fstab nosuid command to protect the system against setuid programs that can run as root and damage the system. The default mount option is suid, which allows mounted programs with setuid permission to run with the permissions of their owners, regardless of who starts them. Therefore, if a program with setuid permission is owned by root, it will run with root permissions, regardless of who starts it.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.