File System Access

I l @ ve RuBoard

Remote file system access is a common service for networked computers. Many proprietary systems developed elaborate file-sharing protocols. Remote file sharing creates a significant security problem. Access and authorization must be uniformly enforced across a number of remote systems. This requires a consistent administration of systems and users. However, the use of these remote file system protocols does not require the enforcement of this level of homogenous administration. So there are many security issues with the use of remote file systems.

NFS

NFS streamlines file sharing 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 a specified list of machines. Once a file system is put into /etc/exports , the information is potentially available to anyone who can do an NFS mount. Thus, the NFS client user can access a server file system without having logged into the server system.

• Server Vulnerability ” Server security is maintained by setting restrictive permissions on the file /etc/exports . 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 to server files by the client 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. Never export any file system to a node on which privilege is granted more leniently than from 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 for the /dev inode containing the major and minor numbers of a client-mounted device 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, by accessing the device via the file and inode number found on the server side.

  Although lacking permission to make a device file on the client side, a system violator wanting to sabotage the client can create an undermining device 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 the client side, but with the following permissions: crw-rw-rw-.

  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 file and use it for devious means ” to wipe out kernel memory on the server, read the contents of everyone's processes, or other mischief.

Common Internet File System

The Common Internet File System, CIFS, is the Windows specification for remote file access. CIFS had its beginnings in the networking protocols, sometimes called Server Message Block (SMB) protocols, that were developed in the late 1980s for PCs to share files over the then nascent Local Area Network technologies (e.g., Ethernet). SMB is the native file-sharing protocol in the Microsoft operating systems and the standard way that millions of PC users share files across corporate intranets .

CIFS is simply a renaming of SMB, and CIFS and SMB are, for all practical purposes, one and the same. (Microsoft now emphasizes the use of CIFS, although references to SMB still occur.) CIFS is also widely available on UNIX systems, VMS ^¢ , Macintosh, and other platforms.

Despite its name , CIFS is not actually a file system unto itself. More accurately, CIFS is a remote file access protocol; it provides access to files on remote systems. It sits on top of and works with the file systems of its host systems. CIFS defines both a server and a client: the CIFS client is used to access files on a CIFS server.

Samba, the Linux implementation of SMB, is supplied as part of the standard package on most Linux implementations and on HP-UX.

The HP-UX implementation of CIFS is CIFS/9000. It enables directories from HP-UX servers to be mounted onto Windows machines and vice versa. The HP CIFS/9000 server product consists of Samba source code which has been enhanced with ACL (Access Control List) mapping features. These mapping features allow you to change UNIX permission bits and ACLs from an NT client through the NT ACL graphical interface on NT clients .

SMB is a very noisy protocol. Servers announce their presence and identify their shared file systems to anyone who asks. This allows the "network neighborhood" functions to be "user friendly." Servers can be configured to not broadcast their existence, but anonymous access to share names is available to anyone who knows the server name.

UUCP

UNIX to UNIX Copy (UUCP) is a utility that is designed to facilitate transferring files, executing commands on remote systems, and sending mail over serial dial-up lines. There are two versions of UUCP: Version 2 that was written in 1977 at Bell Laboratories and is running on some older systems and the more common HoneyDanBer UUCP which was released in 1983 with UNIX System V Release 3. It is easy to tell which it is by looking in the UUCP directory, /usr/lib/uucp . If there is a file named Permissions, then it is HoneyDanBer; if there is a file named USERFILE, then it is Version 2.

The security of both versions of UUCP can be increased by creating different accounts with their own unique user names and passwords for each system that will be calling your system. Each account will have to have the same user ID as the uucp account. This gives you more accountability. You can tell when each system logs in and out and you can disable a specific machine by disabling the account.

There are a number of configuration files that identify with which other computers to communicate and what permissions those computers have on your system. These files must contain appropriate configuration information and be properly protected.

The Systems file ( L.sys in Version 2) contains the system name, phone number, uucp login name, and password for systems that the system calls. Even if the permissions are set correctly on this file, a hacker can get into this file by using the uuname command to get a list of systems that are called by this system, and using the debug option of cu or uucico to determine the phone numbers and uucp logins and passwords.

The Systems file should be owned by the account "uucp" and be readable only by uucp. The debug options for cu and uucico should be disabled if possible; otherwise , the command uucp should be executable only by the account "uucp," and cu removed from the system, unless needed.

In Version 2, the L.cmds file contains a list of commands that can be executed by the specified remote system. All unnecessary commands should be removed.

The USERFILE is used to set local access permissions. It identifies for each system what directories that system has access to. It also will indicate if dial-back is to be utilized for the system.

The directories that can be accessed should be restricted. You should not allow access to any user's home directory or any directory that contains configuration information. Altering this information could compromise your system.

The HoneyDanBer system combines the functionality of these two files into one file, the Permissions file. The Permissions file is made up of a number of name/value pairs. Each line will define the accessible directories and available commands for a MACHINE that your system calls or a LOGNAME for a system that calls your system.

A hacker may try UUCP access to the system. If your system supports anonymous UUCP, this will let him browse. You should try the following hacker trick to make sure your system is secure:

 uucp  target! /etc/passwd /tmp/target.passwd 

If the target system has not limited the scope of the file system access, this will get the password file. A machine that is not properly configured may allow a hacker to update the system's configurations.

Today, most sites have replaced their use of UUCP for point-to-point access with SLIP or PPP, a point-to-point networking protocol. However, most systems still have the UUCP software loaded.

If you have UUCP on your system, whether you use it or not and whether you have modems or not, you must validate that the Permissions file is configured appropriately. An inappropriately configured UUCP can be used to gain privileges on the local system. If you are not using UUCP, remove it from your system.

I l @ ve RuBoard