.HTML "Security in Plan 9.de SS.NH 2...EQdelim $#.EN.TLSecurity in Plan 9.AURuss Cox, MIT LCS.brEric Grosse, Bell Labs.brRob Pike, Bell Labs.brDave Presotto, Avaya Labs and Bell Labs.brSean Quinlan, Bell Labs.br.CW {rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com.ABThe security architecture of the Plan 9™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 andeasier to use..LPThe central component of the new architecture is a per-userself-contained agent called.CW factotum ..CW Factotumsecurely 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..CW Factotumhas an unusual architecture: it is implementedas a Plan 9 file server..FSAppeared, in a slightly different form, in.IProc. of the 2002 Usenix Security Symposium,.RSan Francisco..FE.AE.NH 1Introduction.LPSecure 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..LPThe security architecture of the Plan 9operating system[Pike95]has recently been redesigned to make it both more secureand easier to use.By.I securitywe 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..LPThe 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. .LPSecond, 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..LPThird, 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..LPThese 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..LPThe centerpiece of the new architecture is an agent,called.CW factotum ,that handles the user's keys and negotiates all securityinteractions with system services and applications.Like a trusted assistant with a copy of the owner's keys,.CW factotumdoes all the negotiation for security and authentication.Programs no longer need to be compiled with cryptographiccode; instead they communicate with.CW factotumagentsthat 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.CW factotumneeds to be updated for all system servicesto be kept secure..LPBuilding on.CW factotum ,we modifiedsecure services in the system to moveuser authentication code into.CW factotum ;made authentication a separable component of the file server protocol;deployed new security protocols;designed a secure file store,called.CW secstore ,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..if h .B1 10 60.KF.EQgsize 9.EN.PS 3i # SecstoreSec: box "Secstore" wid 1.3i ht .5i # TerminalTerm0: box invis ht .1i with .e at Sec.e + (-1.1i, -.5i)Term: box wid 1.1i ht 1i with .nw at Term0.neTermlab: "\s-2Terminal\s+2" at Term.s + (0, -.15i)FT: ellipse "$ F sub T#" wid .40i ht .30i with .ne at Term.ne + (-.1i, -.1i)PT: ellipse "$ P sub T#" wid .6i ht .45i with .sw at Term.sw + (.2i, .2i) # CPUCpu0: box invis ht .1i with .w at Term0.w + (3i, 0)Cpu: box wid 1.1i ht 1i with .nw at Cpu0.neCpulab: "\s-2CPU Server\s+2" at Cpu.s + (0, -.15i)FC: ellipse "$ F sub C#" wid .40 ht .30i with .nw at Cpu.nw + (.1i, -.1i)PC: ellipse "$ P sub C#" wid .6i ht .45i with .se at Cpu.se + (-.2i, .2i) # Authentication ServerAuth: box dashed "Auth Server" wid 1.3i ht .5i with .e at Sec.e + (0, -2.3i) # File ServerFile0: box invis ht .1i with .w at Cpu0.w + (0, -1.5i)File: box wid 1.1i ht 1i with .nw at File0.neFilelab: "\s-2File Server\s+2" at File.s + (0, -.15i)FF: ellipse "$ F sub F#" wid .40i ht .30i with .nw at File.nw + (.1i, -.1i)PF: ellipse "$ P sub F#" wid .6i ht .45i with .se at File.se + (-.2i, .2i) # Connectionsline from PT.e + (0, +0.05i) to PC.w + (0, +0.05i)spline from PT.e + (0, -0.05i) right 1i then down 1.5i right .5i then right to PF.w + (0, -0.05i)spline from PC.w + (0, -0.05i) left 1.1i then down 1.4i then right to PF.w + (0, 0.05i)line <-> from FC.se to PC.nwline <-> from FT.sw to PT.neline <-> from FF.se to PF.nwspline <-> from Sec.e right .5i then down .655i then left to FT.e#spline from Auth.e + (0, 0.05i) right .5i then up 1i then to FT.se#spline from Auth.e + (0, 0.00i) right .7i then up 1i then to FC.sw#spline from Auth.e + (0, -0.05i) right .5i then to FF.w.PE.LP.ps 9.vs 10Figure 1a. Components of the security architecture.Each box is a (typically) separate machine; each ellipse a process.The ellipses labeled $F sub X#are.CW factotumprocesses; those labeled$P sub X#are the pieces and proxies of a distributed program.The authentication server is one of several repositories for users' security informationthat.CW factotumprocesses consult as required..CW Secstoreis a shared resource for storing private information such as keys;.CW factotumconsults it for the user during bootstrap..sp.KE.if h .B2.EQgsize 11.EN.LPSecure 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.Our main intent 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..LPAlthough 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..NH 1An Agent for Security.LPOne 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..LPSome 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..LPFollowing 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.CW factotumbecause 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.CW factotumkeep 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.CW factotumleaking information inadvertently..LP.CW Factotumis implemented, like most Plan 9 services, as a file server.It is conventionally mounted upon the directory.CW /mnt/factotum ,and the files it serves there are analogous to virtual devices that provide access to,and control of, the services of the.CW factotum .The next few sections describe the design of.CW factotumand how it operates with the other pieces of Plan 9 to providesecurity services..SSLogging in.LPTo 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.CW grelogging 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,.CW factotumwill prompt him for the password to the secure storeand obtain keys from it, prompting only when a keyisn't found in the store.Otherwise,.CW factotummust prompt for each key..LPIn the typescripts, \f6\s9\en\s0\fPrepresents a literal newlinecharacter typed to force a default response.User input is in italics, andlong lines are folded and indented to fit..LPThis first example shows a user logging in withouthelp from the secure store.First,.CW factotumprompts for a user name that the local kernelwill use:.P1user[none]: \f6\s9gre\s0\fP.P2(Default responses appear in square brackets.)The kernel then starts accessing local resourcesand requests, through.CW factotum ,a user/password pair to do so:.P1!Adding key: dom=cs.bell-labs.com proto=p9sk1user[gre]: \f6\s9\en\s0\fPpassword: \f6****\fP.P2Now the user is logged in to the local system, andthe mail client starts up:.P1!Adding key: proto=apop server=plan9.bell-labs.comuser[gre]: \f6\s9\en\s0\fPpassword: \f6****\fP.P2.CW Factotumis doing all the prompting and the applicationsbeing started are not even touching the keys.Note that it's always clear which key is being requested..LPNow consider the same login sequence, but in the case where.CW grehas a secure store account:.P1user[none]: \f6\s9gre\s0\fPsecstore password: \f6*********\fPSTA PIN+SecurID: \f6*********\fP.P2That's the last.CW grewill hear from.CW factotumunless an attempt is made to contacta system for which no key is kept in the secure store..SSThe factotum.LPEach computer running Plan 9 has one user id that owns all theresources on that system \(em the scheduler, local disks,network interfaces, etc.That user, the.I "host owner" ,is the closest analogue in Plan 9 to a Unix.CW rootaccount (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.At boot time, the Plan 9 kernel starts a.CW factotumexecuting as, and therefore with the privileges of,the host owner..LPNew 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.CW factotumthat it isauthorized to do so.This is done by running anauthentication protocol with.CW factotumtoprove 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 in to the CPU server using thePlan 9.CW cpuservice[Pike93],then$P sub T#might be the.CW cpuclient program and$P sub C#the.CW cpuserver.Neither $P sub C# nor $P sub T#knows the details of the authentication.Theydo need to be able to shuttle messages back andforth between the two.CW factotums ,but this isa generic function easily performed withoutknowing, or being able to extract, secrets inthe messages.$P sub T#will make a network connection to $P sub C#.$P sub T#and$P sub C#will then relay messages betweenthe.CW factotumowned by the user, $F sub T#,and the one owned by the CPU server, $F sub C#,until mutual authentication has been established.Latersections describe the RPC between.CW factotumandapplications and the library functions to support proxy operations..LPThe kernel always uses a single local instance of.CW factotum ,running as thehost owner, forits authentication purposes, buta regular user may start other.CW factotumagents.In fact, the.CW factotumrepresenting 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.CW /mnt/factotumin the user's private file name space on the serverwith a connection to the.CW factotumrunning 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.CW factotum ,sosecrets need never leave the user's terminal.The 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..LPWithin.CW factotum ,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 fromLines 1–500 of 2147. Load more
.HTML "Security in Plan 9 .de SS .NH 2 .. .EQ delim $# .EN .TL Security in Plan 9 .AU Russ Cox, MIT LCS .br Eric Grosse, Bell Labs .br Rob Pike, Bell Labs .br Dave Presotto, Avaya Labs and Bell Labs .br Sean Quinlan, Bell Labs .br .CW {rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com .AB The security architecture of the Plan 9™ 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 easier to use. .LP The central component of the new architecture is a per-user self-contained agent called .CW factotum . .CW Factotum 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. .CW Factotum has an unusual architecture: it is implemented as a Plan 9 file server. .FS Appeared, in a slightly different form, in .I Proc. of the 2002 Usenix Security Symposium, .R San Francisco. .FE .AE .NH 1 Introduction .LP 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. .LP 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 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. .LP 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. .LP 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. .LP 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. .LP 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. .LP The centerpiece of the new architecture is an agent, called .CW factotum , that handles the user's keys and negotiates all security interactions with system services and applications. Like a trusted assistant with a copy of the owner's keys, .CW factotum does all the negotiation for security and authentication. Programs no longer need to be compiled with cryptographic code; instead they communicate with .CW factotum 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 .CW factotum needs to be updated for all system services to be kept secure. .LP Building on .CW factotum , we modified secure services in the system to move user authentication code into .CW factotum ; made authentication a separable component of the file server protocol; deployed new security protocols; designed a secure file store, called .CW secstore , 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. .if h .B1 10 60 .KF .EQ gsize 9 .EN .PS 3i # Secstore Sec: box "Secstore" wid 1.3i ht .5i # Terminal Term0: box invis ht .1i with .e at Sec.e + (-1.1i, -.5i) Term: box wid 1.1i ht 1i with .nw at Term0.ne Termlab: "\s-2Terminal\s+2" at Term.s + (0, -.15i) FT: ellipse "$ F sub T#" wid .40i ht .30i with .ne at Term.ne + (-.1i, -.1i) PT: ellipse "$ P sub T#" wid .6i ht .45i with .sw at Term.sw + (.2i, .2i) # CPU Cpu0: box invis ht .1i with .w at Term0.w + (3i, 0) Cpu: box wid 1.1i ht 1i with .nw at Cpu0.ne Cpulab: "\s-2CPU Server\s+2" at Cpu.s + (0, -.15i) FC: ellipse "$ F sub C#" wid .40 ht .30i with .nw at Cpu.nw + (.1i, -.1i) PC: ellipse "$ P sub C#" wid .6i ht .45i with .se at Cpu.se + (-.2i, .2i) # Authentication Server Auth: box dashed "Auth Server" wid 1.3i ht .5i with .e at Sec.e + (0, -2.3i) # File Server File0: box invis ht .1i with .w at Cpu0.w + (0, -1.5i) File: box wid 1.1i ht 1i with .nw at File0.ne Filelab: "\s-2File Server\s+2" at File.s + (0, -.15i) FF: ellipse "$ F sub F#" wid .40i ht .30i with .nw at File.nw + (.1i, -.1i) PF: ellipse "$ P sub F#" wid .6i ht .45i with .se at File.se + (-.2i, .2i) # Connections line from PT.e + (0, +0.05i) to PC.w + (0, +0.05i) spline from PT.e + (0, -0.05i) right 1i then down 1.5i right .5i then right to PF.w + (0, -0.05i) spline from PC.w + (0, -0.05i) left 1.1i then down 1.4i then right to PF.w + (0, 0.05i) line <-> from FC.se to PC.nw line <-> from FT.sw to PT.ne line <-> from FF.se to PF.nw spline <-> from Sec.e right .5i then down .655i then left to FT.e #spline from Auth.e + (0, 0.05i) right .5i then up 1i then to FT.se #spline from Auth.e + (0, 0.00i) right .7i then up 1i then to FC.sw #spline from Auth.e + (0, -0.05i) right .5i then to FF.w .PE .LP .ps 9 .vs 10 Figure 1a. Components of the security architecture. Each box is a (typically) separate machine; each ellipse a process. The ellipses labeled $F sub X# are .CW factotum processes; those labeled $P sub X# are the pieces and proxies of a distributed program. The authentication server is one of several repositories for users' security information that .CW factotum processes consult as required. .CW Secstore is a shared resource for storing private information such as keys; .CW factotum consults it for the user during bootstrap. .sp .KE .if h .B2 .EQ gsize 11 .EN .LP 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. Our main intent 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. .LP 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. .NH 1 An Agent for Security .LP 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. .LP 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. .LP 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 .CW factotum 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 .CW factotum 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 .CW factotum leaking information inadvertently. .LP .CW Factotum is implemented, like most Plan 9 services, as a file server. It is conventionally mounted upon the directory .CW /mnt/factotum , and the files it serves there are analogous to virtual devices that provide access to, and control of, the services of the .CW factotum . The next few sections describe the design of .CW factotum and how it operates with the other pieces of Plan 9 to provide security services. .SS Logging in .LP 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 .CW gre 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, .CW factotum 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. Otherwise, .CW factotum must prompt for each key. .LP In the typescripts, \f6\s9\en\s0\fP represents a literal newline character typed to force a default response. User input is in italics, and long lines are folded and indented to fit. .LP This first example shows a user logging in without help from the secure store. First, .CW factotum prompts for a user name that the local kernel will use: .P1 user[none]: \f6\s9gre\s0\fP .P2 (Default responses appear in square brackets.) The kernel then starts accessing local resources and requests, through .CW factotum , a user/password pair to do so: .P1 !Adding key: dom=cs.bell-labs.com proto=p9sk1 user[gre]: \f6\s9\en\s0\fP password: \f6****\fP .P2 Now the user is logged in to the local system, and the mail client starts up: .P1 !Adding key: proto=apop server=plan9.bell-labs.com user[gre]: \f6\s9\en\s0\fP password: \f6****\fP .P2 .CW Factotum is doing all the prompting and the applications being started are not even touching the keys. Note that it's always clear which key is being requested. .LP Now consider the same login sequence, but in the case where .CW gre has a secure store account: .P1 user[none]: \f6\s9gre\s0\fP secstore password: \f6*********\fP STA PIN+SecurID: \f6*********\fP .P2 That's the last .CW gre will hear from .CW factotum unless an attempt is made to contact a system for which no key is kept in the secure store. .SS The factotum .LP Each computer running Plan 9 has one user id that owns all the resources on that system \(em the scheduler, local disks, network interfaces, etc. That user, the .I "host owner" , is the closest analogue in Plan 9 to a Unix .CW root 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. At boot time, the Plan 9 kernel starts a .CW factotum executing as, and therefore with the privileges of, the host owner. .LP 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 .CW factotum that it is authorized to do so. This is done by running an authentication protocol with .CW factotum 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 in to the CPU server using the Plan 9 .CW cpu service [Pike93], then $P sub T# might be the .CW cpu client program and $P sub C# the .CW cpu server. Neither $P sub C# nor $P sub T# knows the details of the authentication. They do need to be able to shuttle messages back and forth between the two .CW factotums , but this is a generic function easily performed without knowing, or being able to extract, secrets in the messages. $P sub T# will make a network connection to $P sub C#. $P sub T# and $P sub C# will then relay messages between the .CW factotum owned by the user, $F sub T#, and the one owned by the CPU server, $F sub C#, until mutual authentication has been established. Later sections describe the RPC between .CW factotum and applications and the library functions to support proxy operations. .LP The kernel always uses a single local instance of .CW factotum , running as the host owner, for its authentication purposes, but a regular user may start other .CW factotum agents. In fact, the .CW factotum 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 .CW /mnt/factotum in the user's private file name space on the server with a connection to the .CW factotum 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 .CW factotum , so secrets need never leave the user's terminal. The 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. .LP Within .CW factotum , 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