<html><title>-</title><body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"><H1>Security in Plan 9</H1><DL><DD><I>Russ Cox, MIT LCS<br><br>Eric Grosse, Bell Labs<br><br>Rob Pike, Bell Labs<br><br>Dave Presotto, Avaya Labs and Bell Labs<br><br>Sean Quinlan, Bell Labs<br><br><TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com</TT></I></DL><DL><DD><H4>ABSTRACT</H4>Abstract<DL><DT><DT> <DD>NOTE:<I> To appear, in a slightly different form, inProc. of the 2002 Usenix Security Symposium,San Francisco.</I><DT> <DD></dl><br>The security architecture of the Plan 9(tm)operating system has recently been redesignedto address some technical shortcomings.This redesign provided an opportunity also to make the system moreconvenient to use securely.Plan 9 has thus improved in two ways not usually seen together:it has become more secure<I>and</I>easier to use.<br> <br>The central component of the new architecture is a per-userself-contained agent called<TT>factotum</TT>.<TT>Factotum</TT>securely holds acopy of the user's keys and negotiates authentication protocols, onbehalf of the user, with secure services around the network.Concentrating security code in a single program offers severaladvantages including: ease of update or repair to broken securitysoftware and protocols; the ability to run secure services at a lowerprivilege level; uniform management of keys for all services; and anopportunity to provide single sign on, even to unchanged legacyapplications.<TT>Factotum</TT>has an unusual architecture: it is implementedas a Plan 9 file server.</DL><H4>1 Introduction</H4><br> <br>Secure computing systems face two challenges:first, they must employ sophisticated technology that is difficult to designand prove correct; and second,they must be easy for regular people to use.The question of ease of use is sometimes neglected, but it is essential:weak but easy-to-use security can be more effective than strong butdifficult-to-use security if it is more likely to be used.People lock their front doors when they leave the house, knowingfull well that a burglar is capable of picking the lock (or avoidingthe door altogether); yet few would accept the cost andawkwardness of a bank vault door on thehouse even though that might reduce the probability of a robbery.A related point is that users need a clear model of how the securityoperates (if not how it actually provides security) in order to use itwell; for example, the clarity of a lock icon on a web browseris offset by the confusing and typically insecuresteps for installing X.509 certificates.<br> <br>The security architecture of the Plan 9operating system [Pike95]has recently been redesigned to make it both more secureand easier to use.By<I>security</I>we mean three things:first, the business of authenticating users and services;second, the safe handling, deployment, and use of keysand other secret information; andthird, the use of encryption and integrity checksto safeguard communicationsfrom prying eyes.<br> <br>The old security architecture of Plan 9had several engineering problems in common with other operating systems.First, it had an inadequate notion of security domain.Once a user provided a password to connect to a local file store,the system required that the same password be used to access all the other filestores.That is, the system treated all network services asbelonging to the same security domain. <br> <br>Second, the algorithms and protocols used in authentication,by nature tricky and difficult to get right, were compiled into thevarious applications, kernel modules, and file servers.Changes and fixes to a security protocolrequired that all components using that protocol needed to be recompiled,or at least relinked, and restarted.<br> <br>Third, the file transport protocol, 9P [Pike93],that forms the core ofthe Plan 9 system, had its authentication protocol embedded in its design.This meant that fixing or changing the authentication used by 9Prequired deep changes to the system.If someone were to find a way to break the protocol, the system wouldbe wide open and very hard to fix.<br> <br>These and a number of lesser problems, combined with a desirefor more widespread use of encryption in the system, spurred us torethink the entire security architecture of Plan 9.<br> <br>The centerpiece of the new architecture is an agent,called<TT>factotum</TT>,that handles the user's keys and negotiates all securityinteractions with system services and applications.Like a trusted houseboy with a copy of the owner's keys,<TT>factotum</TT>does all the negotiation for security and authentication.Programs no longer need to be compiled with cryptographiccode; instead they communicate with<TT>factotum</TT>agentsthat represent distinct entities in the cryptographic exchange,such as a user and server of a secure service.If a security protocol needs to be added, deleted, or modified,only<TT>factotum</TT>needs to be updated for all system servicesto be kept secure.<br> <br>Building on<TT>factotum</TT>,we modifiedsecure services in the system to moveuser authentication code into<TT>factotum</TT>;made authentication a separable component of the file server protocol;deployed new security protocols;designed a secure file store,called<TT>secstore</TT>,to protect our keys but make them easy to get when they are needed;designed a new kernel module to support transparent use of Transport Layer Security (TLS)[RFC2246];and began using encryption for all communications within the system.The overall architecture is illustrated in Figure 1a.<DL><DT><DD><TT><PRE><br><img src="-.22122.gif"><br></PRE></TT></DL><br> <br>Figure 1a. Components of the security architecture.Each box is a (typically) separate machine; each ellipse a process.The ellipses labeled <I>F</I><I>X</I>are<TT>factotum</TT>processes; those labeled<I>P</I><I>X</I>are the pieces and proxies of a distributed program.The authentication server is one of several repositories for users' security informationthat<TT>factotum</TT>processes consult as required.<TT>Secstore</TT>is a shared resource for storing private information such as keys;<TT>factotum</TT>consults it for the user during bootstrap.<br> <br><br> <br>Secure protocols and algorithms are well understoodand are usually not the weakest link in a system's security.In practice, most security problems arise from buggy servers,confusing software, or administrative oversights.It is these practical problems that we are addressing.Although this paper describes the algorithms and protocols we are using,they are included mainly for concreteness.Instead, our focus is to present a simple security architecture builtupon a small trusted code base that is easy to verify (whether by manual orautomatic means), easy to understand, and easy to use.<br> <br>Although it is a subjective assessment,we believe we have achieved our goal of ease of use.That we have achievedour goal of improved security is supported by our plan tomove our currently private computing environment onto the Internetoutside the corporate firewall.The rest of this paper explains the architecture and how it is used,to explain why a system that is easy to use securely is also safeenough to run in the open network.<H4>2 An Agent for Security</H4><br> <br>One of the primary reasons for the redesign of the Plan 9security infrastructure was to remove the authenticationmethod both from the applications and from the kernel.Cryptographic codeis large and intricate, so it shouldbe packaged as a separate component that can be repaired ormodified without altering or even relinking applicationsand services that depend on it.If a security protocol is broken, it should be trivial to repair,disable, or replace it on the fly.Similarly, it should be possible for multiple programs to usea common security protocol without embedding it in each program.<br> <br>Some systems use dynamically linked libraries (DLLs) to address these configuration issues.The problem with this approach is that it leavessecurity code in the same address space as the program using it.The interactions between the program and the DLLcan therefore accidentally or deliberately violate the interface,weakening security.Also, a program using a library to implement secure servicesmust run at a privilege level necessary to provide the service;separating the security to a different program makes it possibleto run the services at a weaker privilege level, isolating theprivileged code to a single, more trustworthy component.<br> <br>Following the lead of the SSH agent[Ylon96],we give each useran agent process responsiblefor holding and using the user's keys.The agent program is called<TT>factotum</TT>because of its similarity to the proverbial servant with thepower to act on behalf of his master because he holds thekeys to all the master's possessions. It is essential that<TT>factotum</TT>keep the keys secret and use them only in the owner's interest.Later we'll discuss some changes to the kernel to reduce the possibility of<TT>factotum</TT>leaking information inadvertently.<br> <br><TT>Factotum</TT>is implemented, like most Plan 9 services, as a file server.It is conventionally mounted upon the directory<TT>/mnt/factotum</TT>and the files it serves there are analogous to virtual devices that provide access to,and control of, the services of the<TT>factotum</TT>.The next few sections describe the design of<TT>factotum</TT>and how it operates with the other pieces of Plan 9 to providesecurity services.Logging in<br> <br>To make the discussions that follow more concrete,we begin with a couple of examples showing how thePlan 9 security architecture appears to the user.These examples both involve a user<TT>gre</TT>logging in after booting a local machine.The user may or may not have a secure store in whichall his keys are kept.If he does,<TT>factotum</TT>will prompt him for the password to the secure storeand obtain keys from it, prompting only when a keyisn't found in the store.If not,<TT>factotum</TT>must prompt for each key.<br> <br>In the typescripts,<TT>0</TT>epresents a literal newlinecharacter typed to force a default response.User input is in italics, andlong lines are folded and indented to fit.<br> <br>This first example shows a user logging in withouthelp from the secure store.First,<TT>factotum</TT>prompts for a user name that the local kernelwill use:<DL><DT><DD><TT><PRE>user[none]: gre</PRE></TT></DL>(Default responses appear in square brackets.)The kernel then starts accessing local resourcesand requests, through<TT>factotum</TT>,a user/password pair to do so:<DL><DT><DD><TT><PRE>!Adding key: dom=cs.bell-labs.com proto=p9sk1user[gre]: \npassword: ****</PRE></TT></DL>Now the user is logged in to the local system, andthe mail client starts up:<DL><DT><DD><TT><PRE>!Adding key: proto=apop server=plan9.bell-labs.comuser[gre]: \npassword: ****</PRE></TT></DL><TT>Factotum</TT>is doing all the prompting and the applicationsbeing started are not even touching the keys.Note that it's always clear what key is being requested.<br> <br>Now consider the same login sequence, but in the case where<TT>gre</TT>has a secure store account:<DL><DT><DD><TT><PRE>user[none]: gresecstore password: ******STA PIN+SecurID: ******</PRE></TT></DL>That's the last<TT>gre</TT>will hear from<TT>factotum</TT>unless an attempt is made to contacta system for which no key is kept in the secure store.The factotum<br> <br>Each computer running Plan 9 has one user id that owns all theresources on that system ­ the scheduler, local disks,network interfaces, etc.That user, the<I>host owner</I>,is the closest analogue in Plan 9 to a Unix<TT>root</TT>account (although it is far weaker;rather than having special powers, as its name implies the host owneris just a regular user that happens to own theresources of the local machine).On a single-user system, which we call a terminal,the host owner is the id of the terminal's user.Shared servers such as CPU servers normally have a pseudo-userthat initially owns all resources.By default,<TT>factotum</TT>executes as, and therefore has the privileges of,the host owner.<br> <br>New processes run asthe same user as the process which created them.When a process must take on the identity of a new user,such as to provide a login shellon a shared CPU server,it does so by proving to the host owner's<TT>factotum</TT>that it isauthorized to do so.This is done by running anauthentication protocol with<TT>factotum</TT>toprove that the process has access to secret informationwhich only the new user should possess.For example, consider the setup in Figure 1a.If a user on the terminalwants to log on to the CPU server using thePlan 9<TT>cpu</TT>service [Pike93],then<I>P</I><I>T</I>might be the<TT>cpu</TT>client program and<I>P</I><I>C</I>the<TT>cpu</TT>server.Neither <I>P</I><I>C</I> nor <I>P</I><I>T</I>knows the details of the authentication.Theydo need to be able to shuttle messages back andforth between the two<TT>factotums</TT>,but this isa generic function easily performed withoutknowing, or being able to extract, secrets inthe messages.<I>P</I><I>T</I>will make a network connection to <I>P</I><I>C</I>.<I>P</I><I>T</I>and<I>P</I><I>C</I>will then relay messages betweenthe<TT>factotum</TT>owned by the user, <I>F</I><I>T</I>,and the one owned by the CPU server, <I>F</I><I>C</I>,until mutual authentication has been established.Latersections describe the RPC between<TT>factotum</TT>andapplications and the library functions to support proxy operations.<br> <br>The kernel always uses a single local instance of<TT>factotum</TT>,running as thehost owner, forits authentication purposes, buta regular user may start multiple<TT>factotum</TT>agents.In fact, the<TT>factotum</TT>representing the user need not berunning on the same machine as its client.For instance, it is easy for a user on a CPU server,through standard Plan 9 operations,to replace the<TT>/mnt/factotum</TT>in the user's private file name space on the serverwith a connection to the<TT>factotum</TT>running on the terminal.(The usual file system permissions prevent interlopersfrom doing so maliciously.)This permits secure operations on the CPU server to betransparently validated by the user's own<TT>factotum</TT>,sosecrets need never leave the user's terminal.SSH agent[Ylon96]does much thesame with special SSH protocol messages, butan advantage to making our agent a file systemis that we need no new mechanism to access our remoteagent; remote file access is sufficient.<br> <br>Within<TT>factotum</TT>,each protocol is implemented as a statemachine with a generic interface, so protocols are inessence pluggable modules, easy to add, modify, or drop.Writing a message to and reading a message from<TT>factotum</TT>each require a separate RPC and result ina single state transition.Therefore<TT>factotum</TT>always runs to completion on every RPC and never blockswaiting for input during any authentication.Moreover, the number of simultaneousauthentications is limited only by the amount of memory we'rewilling to dedicate to representing the state machines.<br> <br>Authentication protocols are implemented onlywithin<TT>factotum</TT>,but adding and removingprotocols does require relinking the binary, so<TT>factotum</TT>processes (but no others)need to be restarted in order to take advantage ofnew or repaired protocols.<br> <br>At the time of writing, <TT>factotum</TT>contains authenticationmodules for the Plan 9 shared key protocol (p9sk1), forSSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP,Microsoft PPP's MSCHAP, and VNC's challenge/response. We'rein the process of adding support for TLS handshakes.Local capabilities<br> <br>A capability system, managed by the kernel, is used to empower<TT>factotum</TT>to grant permission to another process to change its user id.Akernel device driverimplements two files,<TT>/dev/caphash</TT>and<TT>/dev/capuse</TT>.The write-only file<TT>/dev/caphash</TT>can be opened only by the host owner, and only once.<TT>Factotum</TT>opens this file immediately after booting.<br> <br>To use the files,<TT>factotum</TT>creates a string of the form<I>userid1<TT>@</TT>userid2<TT>@</TT>random-string</I>,uses SHA1 HMAC to hash<I>userid1<TT>@</TT>userid2</I>with key<I>random-string</I>,and writes that hash to<TT>/dev/caphash</TT>.Lines 1–500 of 2051. Load more
<html> <title> - </title> <body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"> <H1>Security in Plan 9 </H1> <DL><DD><I>Russ Cox, MIT LCS<br> <br> Eric Grosse, Bell Labs<br> <br> Rob Pike, Bell Labs<br> <br> Dave Presotto, Avaya Labs and Bell Labs<br> <br> Sean Quinlan, Bell Labs<br> <br> <TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com</TT> </I></DL> <DL><DD><H4>ABSTRACT</H4> Abstract <DL> <DT><DT> <DD> NOTE:<I> To appear, in a slightly different form, in Proc. of the 2002 Usenix Security Symposium, San Francisco. </I><DT> <DD></dl> <br> The security architecture of the Plan 9(tm) operating system has recently been redesigned to address some technical shortcomings. This redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually seen together: it has become more secure <I>and</I> easier to use. <br> <br> The central component of the new architecture is a per-user self-contained agent called <TT>factotum</TT>. <TT>Factotum</TT> securely holds a copy of the user's keys and negotiates authentication protocols, on behalf of the user, with secure services around the network. Concentrating security code in a single program offers several advantages including: ease of update or repair to broken security software and protocols; the ability to run secure services at a lower privilege level; uniform management of keys for all services; and an opportunity to provide single sign on, even to unchanged legacy applications. <TT>Factotum</TT> has an unusual architecture: it is implemented as a Plan 9 file server. </DL> <H4>1 Introduction </H4> <br> <br> Secure computing systems face two challenges: first, they must employ sophisticated technology that is difficult to design and prove correct; and second, they must be easy for regular people to use. The question of ease of use is sometimes neglected, but it is essential: weak but easy-to-use security can be more effective than strong but difficult-to-use security if it is more likely to be used. People lock their front doors when they leave the house, knowing full well that a burglar is capable of picking the lock (or avoiding the door altogether); yet few would accept the cost and awkwardness of a bank vault door on the house even though that might reduce the probability of a robbery. A related point is that users need a clear model of how the security operates (if not how it actually provides security) in order to use it well; for example, the clarity of a lock icon on a web browser is offset by the confusing and typically insecure steps for installing X.509 certificates. <br> <br> The security architecture of the Plan 9 operating system [Pike95] has recently been redesigned to make it both more secure and easier to use. By <I>security</I> we mean three things: first, the business of authenticating users and services; second, the safe handling, deployment, and use of keys and other secret information; and third, the use of encryption and integrity checks to safeguard communications from prying eyes. <br> <br> The old security architecture of Plan 9 had several engineering problems in common with other operating systems. First, it had an inadequate notion of security domain. Once a user provided a password to connect to a local file store, the system required that the same password be used to access all the other file stores. That is, the system treated all network services as belonging to the same security domain. <br> <br> Second, the algorithms and protocols used in authentication, by nature tricky and difficult to get right, were compiled into the various applications, kernel modules, and file servers. Changes and fixes to a security protocol required that all components using that protocol needed to be recompiled, or at least relinked, and restarted. <br> <br> Third, the file transport protocol, 9P [Pike93], that forms the core of the Plan 9 system, had its authentication protocol embedded in its design. This meant that fixing or changing the authentication used by 9P required deep changes to the system. If someone were to find a way to break the protocol, the system would be wide open and very hard to fix. <br> <br> These and a number of lesser problems, combined with a desire for more widespread use of encryption in the system, spurred us to rethink the entire security architecture of Plan 9. <br> <br> The centerpiece of the new architecture is an agent, called <TT>factotum</TT>, that handles the user's keys and negotiates all security interactions with system services and applications. Like a trusted houseboy with a copy of the owner's keys, <TT>factotum</TT> does all the negotiation for security and authentication. Programs no longer need to be compiled with cryptographic code; instead they communicate with <TT>factotum</TT> agents that represent distinct entities in the cryptographic exchange, such as a user and server of a secure service. If a security protocol needs to be added, deleted, or modified, only <TT>factotum</TT> needs to be updated for all system services to be kept secure. <br> <br> Building on <TT>factotum</TT>, we modified secure services in the system to move user authentication code into <TT>factotum</TT>; made authentication a separable component of the file server protocol; deployed new security protocols; designed a secure file store, called <TT>secstore</TT>, to protect our keys but make them easy to get when they are needed; designed a new kernel module to support transparent use of Transport Layer Security (TLS) [RFC2246]; and began using encryption for all communications within the system. The overall architecture is illustrated in Figure 1a. <DL><DT><DD><TT><PRE> <br><img src="-.22122.gif"><br> </PRE></TT></DL> <br> <br> Figure 1a. Components of the security architecture. Each box is a (typically) separate machine; each ellipse a process. The ellipses labeled <I>F</I><I>X</I> are <TT>factotum</TT> processes; those labeled <I>P</I><I>X</I> are the pieces and proxies of a distributed program. The authentication server is one of several repositories for users' security information that <TT>factotum</TT> processes consult as required. <TT>Secstore</TT> is a shared resource for storing private information such as keys; <TT>factotum</TT> consults it for the user during bootstrap. <br> <br> <br> <br> Secure protocols and algorithms are well understood and are usually not the weakest link in a system's security. In practice, most security problems arise from buggy servers, confusing software, or administrative oversights. It is these practical problems that we are addressing. Although this paper describes the algorithms and protocols we are using, they are included mainly for concreteness. Instead, our focus is to present a simple security architecture built upon a small trusted code base that is easy to verify (whether by manual or automatic means), easy to understand, and easy to use. <br> <br> Although it is a subjective assessment, we believe we have achieved our goal of ease of use. That we have achieved our goal of improved security is supported by our plan to move our currently private computing environment onto the Internet outside the corporate firewall. The rest of this paper explains the architecture and how it is used, to explain why a system that is easy to use securely is also safe enough to run in the open network. <H4>2 An Agent for Security </H4> <br> <br> One of the primary reasons for the redesign of the Plan 9 security infrastructure was to remove the authentication method both from the applications and from the kernel. Cryptographic code is large and intricate, so it should be packaged as a separate component that can be repaired or modified without altering or even relinking applications and services that depend on it. If a security protocol is broken, it should be trivial to repair, disable, or replace it on the fly. Similarly, it should be possible for multiple programs to use a common security protocol without embedding it in each program. <br> <br> Some systems use dynamically linked libraries (DLLs) to address these configuration issues. The problem with this approach is that it leaves security code in the same address space as the program using it. The interactions between the program and the DLL can therefore accidentally or deliberately violate the interface, weakening security. Also, a program using a library to implement secure services must run at a privilege level necessary to provide the service; separating the security to a different program makes it possible to run the services at a weaker privilege level, isolating the privileged code to a single, more trustworthy component. <br> <br> Following the lead of the SSH agent [Ylon96], we give each user an agent process responsible for holding and using the user's keys. The agent program is called <TT>factotum</TT> because of its similarity to the proverbial servant with the power to act on behalf of his master because he holds the keys to all the master's possessions. It is essential that <TT>factotum</TT> keep the keys secret and use them only in the owner's interest. Later we'll discuss some changes to the kernel to reduce the possibility of <TT>factotum</TT> leaking information inadvertently. <br> <br> <TT>Factotum</TT> is implemented, like most Plan 9 services, as a file server. It is conventionally mounted upon the directory <TT>/mnt/factotum</TT> and the files it serves there are analogous to virtual devices that provide access to, and control of, the services of the <TT>factotum</TT>. The next few sections describe the design of <TT>factotum</TT> and how it operates with the other pieces of Plan 9 to provide security services. Logging in <br> <br> To make the discussions that follow more concrete, we begin with a couple of examples showing how the Plan 9 security architecture appears to the user. These examples both involve a user <TT>gre</TT> logging in after booting a local machine. The user may or may not have a secure store in which all his keys are kept. If he does, <TT>factotum</TT> will prompt him for the password to the secure store and obtain keys from it, prompting only when a key isn't found in the store. If not, <TT>factotum</TT> must prompt for each key. <br> <br> In the typescripts, <TT>0</TT> epresents a literal newline character typed to force a default response. User input is in italics, and long lines are folded and indented to fit. <br> <br> This first example shows a user logging in without help from the secure store. First, <TT>factotum</TT> prompts for a user name that the local kernel will use: <DL><DT><DD><TT><PRE> user[none]: gre </PRE></TT></DL> (Default responses appear in square brackets.) The kernel then starts accessing local resources and requests, through <TT>factotum</TT>, a user/password pair to do so: <DL><DT><DD><TT><PRE> !Adding key: dom=cs.bell-labs.com proto=p9sk1 user[gre]: \n password: **** </PRE></TT></DL> Now the user is logged in to the local system, and the mail client starts up: <DL><DT><DD><TT><PRE> !Adding key: proto=apop server=plan9.bell-labs.com user[gre]: \n password: **** </PRE></TT></DL> <TT>Factotum</TT> is doing all the prompting and the applications being started are not even touching the keys. Note that it's always clear what key is being requested. <br> <br> Now consider the same login sequence, but in the case where <TT>gre</TT> has a secure store account: <DL><DT><DD><TT><PRE> user[none]: gre secstore password: ****** STA PIN+SecurID: ****** </PRE></TT></DL> That's the last <TT>gre</TT> will hear from <TT>factotum</TT> unless an attempt is made to contact a system for which no key is kept in the secure store. The factotum <br> <br> Each computer running Plan 9 has one user id that owns all the resources on that system ­ the scheduler, local disks, network interfaces, etc. That user, the <I>host owner</I>, is the closest analogue in Plan 9 to a Unix <TT>root</TT> account (although it is far weaker; rather than having special powers, as its name implies the host owner is just a regular user that happens to own the resources of the local machine). On a single-user system, which we call a terminal, the host owner is the id of the terminal's user. Shared servers such as CPU servers normally have a pseudo-user that initially owns all resources. By default, <TT>factotum</TT> executes as, and therefore has the privileges of, the host owner. <br> <br> New processes run as the same user as the process which created them. When a process must take on the identity of a new user, such as to provide a login shell on a shared CPU server, it does so by proving to the host owner's <TT>factotum</TT> that it is authorized to do so. This is done by running an authentication protocol with <TT>factotum</TT> to prove that the process has access to secret information which only the new user should possess. For example, consider the setup in Figure 1a. If a user on the terminal wants to log on to the CPU server using the Plan 9 <TT>cpu</TT> service [Pike93], then <I>P</I><I>T</I> might be the <TT>cpu</TT> client program and <I>P</I><I>C</I> the <TT>cpu</TT> server. Neither <I>P</I><I>C</I> nor <I>P</I><I>T</I> knows the details of the authentication. They do need to be able to shuttle messages back and forth between the two <TT>factotums</TT>, but this is a generic function easily performed without knowing, or being able to extract, secrets in the messages. <I>P</I><I>T</I> will make a network connection to <I>P</I><I>C</I>. <I>P</I><I>T</I> and <I>P</I><I>C</I> will then relay messages between the <TT>factotum</TT> owned by the user, <I>F</I><I>T</I>, and the one owned by the CPU server, <I>F</I><I>C</I>, until mutual authentication has been established. Later sections describe the RPC between <TT>factotum</TT> and applications and the library functions to support proxy operations. <br> <br> The kernel always uses a single local instance of <TT>factotum</TT>, running as the host owner, for its authentication purposes, but a regular user may start multiple <TT>factotum</TT> agents. In fact, the <TT>factotum</TT> representing the user need not be running on the same machine as its client. For instance, it is easy for a user on a CPU server, through standard Plan 9 operations, to replace the <TT>/mnt/factotum</TT> in the user's private file name space on the server with a connection to the <TT>factotum</TT> running on the terminal. (The usual file system permissions prevent interlopers from doing so maliciously.) This permits secure operations on the CPU server to be transparently validated by the user's own <TT>factotum</TT>, so secrets need never leave the user's terminal. SSH agent [Ylon96] does much the same with special SSH protocol messages, but an advantage to making our agent a file system is that we need no new mechanism to access our remote agent; remote file access is sufficient. <br> <br> Within <TT>factotum</TT>, each protocol is implemented as a state machine with a generic interface, so protocols are in essence pluggable modules, easy to add, modify, or drop. Writing a message to and reading a message from <TT>factotum</TT> each require a separate RPC and result in a single state transition. Therefore <TT>factotum</TT> always runs to completion on every RPC and never blocks waiting for input during any authentication. Moreover, the number of simultaneous authentications is limited only by the amount of memory we're willing to dedicate to representing the state machines. <br> <br> Authentication protocols are implemented only within <TT>factotum</TT>, but adding and removing protocols does require relinking the binary, so <TT>factotum</TT> processes (but no others) need to be restarted in order to take advantage of new or repaired protocols. <br> <br> At the time of writing, <TT>factotum</TT> contains authentication modules for the Plan 9 shared key protocol (p9sk1), for SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP, Microsoft PPP's MSCHAP, and VNC's challenge/response. We're in the process of adding support for TLS handshakes. Local capabilities <br> <br> A capability system, managed by the kernel, is used to empower <TT>factotum</TT> to grant permission to another process to change its user id. A kernel device driver implements two files, <TT>/dev/caphash</TT> and <TT>/dev/capuse</TT>. The write-only file <TT>/dev/caphash</TT> can be opened only by the host owner, and only once. <TT>Factotum</TT> opens this file immediately after booting. <br> <br> To use the files, <TT>factotum</TT> creates a string of the form <I>userid1<TT>@</TT>userid2<TT>@</TT>random-string</I>, uses SHA1 HMAC to hash <I>userid1<TT>@</TT>userid2</I> with key <I>random-string</I>, and writes that hash to <TT>/dev/caphash</TT>.