Improving Cell Security
| Chapter 2. Installing the First AFS Machine |

## Improving Cell Security

This section discusses ways to improve the security of AFS data in your cell. Also see the chapter in the OpenAFS Administration Guide about configuration and administration issues.

### Controlling root Access

As on any machine, it is important to prevent unauthorized users from logging onto an AFS server or client machine as the local superuser root. Take care to keep the root password secret.

The local root superuser does not have special access to AFS data through the Cache Manager (as members of the system:administrators group do), but it does have the following privileges:

- On client machines, the ability to issue commands from the fs suite that affect AFS performance

- On server machines, the ability to disable authorization checking, or to install rogue process binaries

### Controlling System Administrator Access

Following are suggestions for managing AFS administrative privilege:

- Create an administrative account for each administrator named something like `username`.admin. Administrators authenticate under these identities only when performing administrative tasks, and destroy the administrative tokens immediately after finishing the task (either by issuing the unlog command, or the kinit and aklog commands to adopt their regular identity).

- Set a short ticket lifetime for administrator accounts (for example, 20 minutes) by using the facilities of your KDC. For instance, with a MIT Kerberos KDC, this can be performed using the --max-ticket-life argument to the kadmin modify_principal command. Do not however, use a short lifetime for users who issue long-running backup commands.

- Limit the number of system administrators in your cell, especially those who belong to the system:administrators group. By default they have all ACL rights on all directories in the local AFS filespace, and therefore must be trusted not to examine private files.

- Limit the use of system administrator accounts on machines in public areas. It is especially important not to leave such machines unattended without first destroying the administrative tokens.

- Limit the use by administrators of standard UNIX commands that make connections to remote machines (such as the telnet utility). Many of these programs send passwords across the network without encrypting them.

### Protecting Sensitive AFS Directories

Some subdirectories of the /usr/afs directory contain files crucial to cell security. Unauthorized users must not read or write to these files because of the potential for misuse of the information they contain.

As the BOS Server initializes for the first time on a server machine, it creates several files and directories (as mentioned in Starting the BOS Server). It sets their owner to the local superuser root and sets their mode bits to enable writing by the owner only; in some cases, it also restricts reading.

At each subsequent restart, the BOS Server checks that the owner and mode bits on these files are still set appropriately. If they are not, it write the following message to the /usr/afs/logs/BosLog file:

       Bosserver reports inappropriate access on server directories

The BOS Server does not reset the mode bits, which enables you to set alternate values if you wish.

The following charts lists the expected mode bit settings. A question mark indicates that the BOS Server does not check that mode bit.

/usr/afs | `drwxr`?`xr-x`
/usr/afs/backup | `drwx`???`---`
/usr/afs/bin | `drwxr`?`xr-x`
/usr/afs/db | `drwx`???`---`
/usr/afs/etc | `drwxr`?`xr-x`
/usr/afs/etc/KeyFile | `-rw`????`---`
/usr/afs/etc/UserList | `-rw`?????`--`
/usr/afs/local | `drwx`???`---`
/usr/afs/logs | `drwxr`?`xr-x`

Enabling Access to Foreign Cells |  | Removing Client Functionality