|
|
United States-English | |
|
|
 |
|
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 6 File System Security
Controlling File Security on a Network |
|
|
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. 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:
A Network File System (NFS) provides the following conveniences: 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. 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.
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. Following are suggestions to safeguard NFS-mounted files:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
