| Security and Authorization in AFS | ||
|---|---|---|
 � | Chapter�2.�Issues in Cell Configuration and Administration | � |
| Security and Authorization in AFS | ||
|---|---|---|
| � | Chapter�2.�Issues in Cell Configuration and Administration | � |
AFS incorporates several features to ensure that only authorized users gain access to data. This section summarizes the most important of them and suggests methods for improving security in your cell.
ACLs on Directories.�Files in AFS are protected by the access control list (ACL) associated with their parent directory. The ACL defines which users or groups can access the data in the directory, and in what way. See Managing Access Control Lists.
Mutual Authentication Between Client and Server.�When an AFS client and server process communicate, each requires the other to prove its identity during mutual authentication, which involves the exchange of encrypted information that only valid parties can decrypt and respond to. For a detailed description of the mutual authentication process, see A More Detailed Look at Mutual Authentication.
AFS server processes mutually authenticate both with one another and with processes that represent human users. After mutual authentication is complete, the server and client have established an authenticated connection, across which they can communicate repeatedly without having to authenticate again until the connection expires or one of the parties closes it. Authenticated connections have varying lifetimes.
Tokens.�In order to access AFS files, users must prove their identities to the AFS authentication service by providing the correct AFS password. If the password is correct, the authentication service sends the user a token as evidence of authenticated status. See Login and Authentication in AFS.
Servers assign the user identity anonymous to users and processes that do not have a valid token. The anonymous identity has only the access granted to the system:anyuser group on ACLs.
Authorization Checking.�Mutual authentication establishes that two parties communicating with one another are actually who they claim to be. For many functions, AFS server processes also check that the client whose identity they have verified is also authorized to make the request. Different requests require different kinds of privilege. See Three Types of Privilege.
Encrypted Network Communications.�The AFS server processes encrypt particularly sensitive information before sending it back to clients. Even if an unauthorized party is able to eavesdrop on an authenticated connection, they cannot decipher encrypted data without the proper key.
The following AFS commands encrypt data because they involve server encryption keys and passwords:
The bos addkey command, which adds a server encryption key to the /usr/afs/etc/KeyFile file
The bos listkeys command, which lists the server encryption keys from the /usr/afs/etc/KeyFile file
The kpasswd command, which changes a password in the Authentication Database
Most commands in the kas command suite
In addition, the Update Server encrypts sensitive information (such as the contents of KeyFile) when distributing it. Other commands in the bos suite and the commands in the fs, pts and vos suites do not encrypt data before transmitting it.
AFS uses three separate types of privilege for the reasons discussed in The Reason for Separate Privileges.
Membership in the system:administrators group. Members are entitled to issue any pts command and those fs commands that set volume quota. By default, they also implicitly have the a (administer) and l (lookup) permissions on every ACL in the file tree even if the ACL does not include an entry for them.
The ADMIN flag on the
Authentication Database entry. An administrator with this flag
can issue any kas
command.
Inclusion in the /usr/afs/etc/UserList file. An administrator whose username appears in this file can issue any bos, vos, or backup command (although some backup commands require additional privilege as described in Granting Administrative Privilege to Backup Operators).
AFS distinguishes between authentication and authorization checking. Authentication refers to the process of proving identity. Authorization checking refers to the process of verifying that an authenticated identity is allowed to perform a certain action.
AFS implements authentication at the level of connections. Each time two parties establish a new connection, they mutually authenticate. In general, each issue of an AFS command establishes a new connection between AFS server process and client.
AFS implements authorization checking at the level of server machines. If authorization checking is enabled on a server machine, then all of the server processes running on it provide services only to authorized users. If authorization checking is disabled on a server machine, then all of the server processes perform any action for anyone. Obviously, disabling authorization checking is an extreme security exposure. For more information, see Managing Authentication and Authorization Requirements.
You can improve the level of security in your cell by configuring user accounts, server machines, and system administrator accounts in the indicated way.
User Accounts.�
Use an AFS-modified login utility, or include the -setpag flag to the klog command, to associate the credential structure that houses tokens with a PAG rather than a UNIX UID. This prevents users from inheriting someone else's tokens by assuming their UNIX identity. For further discussion, see Identifying AFS Tokens by PAG.
Encourage users to issue the unlog command to destroy their tokens before logging out. This forestalls attempts to access tokens left behind kernel memory. Consider including the unlog command in every user's .logout file or equivalent.
Server Machines.�
Disable authorization checking only in emergencies or for very brief periods of time. It is best to work at the console of the affected machine during this time, to prevent anyone else from accessing the machine through the keyboard.
Change the AFS server encryption key on a frequent and regular schedule. Make it difficult to guess (a long string including nonalphabetic characters, for instance). Unlike user passwords, the password from which the AFS key is derived can be longer than eight characters, because it is never used during login. The kas setpassword command accepts a password hundreds of characters long. For instructions, see Managing Server Encryption Keys.
As much as possible, limit the number of people who can login at a server machine's console or remotely. Imposing this limit is an extra security precaution rather than a necessity. The machine cannot serve as an AFS client in this case.
Particularly limit access to the local superuser root account on a server machine. The local superuser root has free access to important administrative subdirectories of the /usr/afs directory, as described in AFS Files on the Local Disk.
As in any computing environment, server machines must be located in a secured area. Any other security measures are effectively worthless if unauthorized people can access the computer hardware.
System Administrators.�
Limit the number of system administrators in your cell. Limit the use of system administrator accounts on publicly accessible workstations. Such machines are not secure, so unscrupulous users can install programs that try to steal tokens or passwords. If administrators must use publicly accessible workstations at times, they must issue the unlog command before leaving the machine.
Create an administrative account for each administrator separate from the personal account, and assign AFS privileges only to the administrative account. The administrators must authenticate to the administrative accounts to perform duties that require privilege, which provides a useful audit trail as well.
Administrators must not leave a machine unattended while they have valid tokens. Issue the unlog command before leaving.
Use the -lifetime argument to the kas setfields command to set the token lifetime for administrative accounts to a fairly short amount of time. The default lifetime for AFS tokens is 25 hours, but 30 or 60 minutes is possibly a more reasonable lifetime for administrative tokens. The tokens for administrators who initiate AFS Backup System operations must last somewhat longer, because it can take several hours to complete some dump operations, depending on the speed of the tape device and the network connecting it to the file server machines that house the volumes is it accessing.
Limit administrators' use of the telnet program. It sends unencrypted passwords across the network. Similarly, limit use of other remote programs such as rsh and rcp, which send unencrypted tokens across the network.
As in any file system, security is a prime concern in AFS. A file system that makes file sharing easy is not useful if it makes file sharing mandatory, so AFS incorporates several features that prevent unauthorized users from accessing data. Security in a networked environment is difficult because almost all procedures require transmission of information across wires that almost anyone can tap into. Also, many machines on networks are powerful enough that unscrupulous users can monitor transactions or even intercept transmissions and fake the identity of one of the participants.
The most effective precaution against eavesdropping and information theft or fakery is for servers and clients to accept the claimed identity of the other party only with sufficient proof. In other words, the nature of the network forces all parties on the network to assume that the other party in a transaction is not genuine until proven so. Mutual authentication is the means through which parties prove their genuineness.
Because the measures needed to prevent fakery must be quite sophisticated, the implementation of mutual authentication procedures is complex. The underlying concept is simple, however: parties prove their identities by demonstrating knowledge of a shared secret. A shared secret is a piece of information known only to the parties who are mutually authenticating (they can sometimes learn it in the first place from a trusted third party or some other source). The party who originates the transaction presents the shared secret and refuses to accept the other party as valid until it shows that it knows the secret too.
The most common form of shared secret in AFS transactions is the encryption key, also referred to simply as a key. The two parties use their shared key to encrypt the packets of information they send and to decrypt the ones they receive. Encryption using keys actually serves two related purposes. First, it protects messages as they cross the network, preventing anyone who does not know the key from eavesdropping. Second, ability to encrypt and decrypt messages successfully indicates that the parties are using the key (it is their shared secret). If they are using different keys, messages remain scrambled and unintelligible after decryption.
The following sections describe AFS's mutual authentication procedures in more detail. Feel free to skip these sections if you are not interested in the mutual authentication process.
Simple mutual authentication involves only one encryption key and two parties, generally a client and server. The client contacts the server by sending a challenge message encrypted with a key known only to the two of them. The server decrypts the message using its key, which is the same as the client's if they really do share the same secret. The server responds to the challenge and uses its key to encrypt its response. The client uses its key to decrypt the server's response, and if it is correct, then the client can be sure that the server is genuine: only someone who knows the same key as the client can decrypt the challenge and answer it correctly. On its side, the server concludes that the client is genuine because the challenge message made sense when the server decrypted it.
AFS uses simple mutual authentication to verify user identities during the first part of the login procedure. In that case, the key is based on the user's password.
Complex mutual authentication involves three encryption keys and three parties. All secure AFS transactions (except the first part of the login process) employ complex mutual authentication.
When a client wishes to communicate with a server, it first contacts a third party called a ticket-granter. The ticket-granter and the client mutually authenticate using the simple procedure. When they finish, the ticket-granter gives the client a server ticket (or simply ticket) as proof that it (the ticket-granter) has preverified the identity of the client. The ticket-granter encrypts the ticket with the first of the three keys, called the server encryption key because it is known only to the ticket-granter and the server the client wants to contact. The client does not know this key.
The ticket-granter sends several other pieces of information along with the ticket. They enable the client to use the ticket effectively despite being unable to decrypt the ticket itself. Along with the ticket, the items constitute a token:
A session key, which is the second encryption key involved in mutual authentication. The ticket-granter invents the session key at random as the shared secret between client and server. For reasons explained further below, the ticket-granter also puts a copy of the session key inside the ticket. The client and server use the session key to encrypt messages they send to one another during their transactions. The ticket-granter invents a different session key for each connection between a client and a server (there can be several transactions during a single connection).
The name of the server for which the ticket is valid (and so which server encryption key encrypts the ticket itself).
A ticket lifetime indicator. The default lifetime of AFS server tickets is 100 hours. If the client wants to contact the server again after the ticket expires, it must contact the ticket-granter to get a new ticket.
The ticket-granter seals the entire token with the third key involved in complex mutual authentication--the key known only to it (the ticket-granter) and the client. In some cases, this third key is derived from the password of the human user whom the client represents.
Now that the client has a valid server ticket, it is ready to contact the server. It sends the server two things:
The server ticket. This is encrypted with the server encryption key.
Its request message, encrypted with the session key. Encrypting the message protects it as it crosses the network, since only the server/client pair for whom the ticket-granter invented the session key know it.
At this point, the server does not know the session key, because the ticket-granter just created it. However, the ticket-granter put a copy of the session key inside the ticket. The server uses the server encryption key to decrypts the ticket and learns the session key. It then uses the session key to decrypt the client's request message. It generates a response and sends it to the client. It encrypts the response with the session key to protect it as it crosses the network.
This step is the heart of mutual authentication between client and server, because it proves to both parties that they know the same secret:
The server concludes that the client is authorized to make a request because the request message makes sense when the server decrypts it using the session key. If the client uses a different session key than the one the server finds inside the ticket, then the request message remains unintelligible even after decryption. The two copies of the session key (the one inside the ticket and the one the client used) can only be the same if they both came from the ticket-granter. The client cannot fake knowledge of the session key because it cannot look inside the ticket, sealed as it is with the server encryption key known only to the server and the ticket-granter. The server trusts the ticket-granter to give tokens only to clients with whom it (the ticket-granter) has authenticated, so the server decides the client is legitimate.
(Note that there is no direct communication between the ticket-granter and the server, even though their relationship is central to ticket-based mutual authentication. They interact only indirectly, via the client's possession of a ticket sealed with their shared secret.)
The client concludes that the server is genuine and trusts the response it gets back from the server, because the response makes sense after the client decrypts it using the session key. This indicates that the server encrypted the response with the same session key as the client knows. The only way for the server to learn that matching session key is to decrypt the ticket first. The server can only decrypt the ticket because it shares the secret of the server encryption key with the ticket-granter. The client trusts the ticket-granter to give out tickets only for legitimate servers, so the client accepts a server that can decrypt the ticket as genuine, and accepts its response.
| � |  | � |
| Login and Authentication in AFS� |  | �Backing Up AFS Data |