71 Startup OKWS is started by a launcher process The launcher spawns ok demux

71 startup okws is started by a launcher process the

This preview shows page 8 - 10 out of 14 pages.

7.1 Startup OKWS is started by a launcher process. The launcher spawns ok- demux , site-specific workers requested by the site operator, and two other processes seen in Figure 1, idd and ok-dbproxy . The processes 8
Image of page 8
netd ok-demux idd Worker W 1. u ’s TCP connection 2. Grant u C ? 3. Lookup UN/PW 4. Grant u G ? , u T ? 5. Grant u T ? 6. Grant u C ? , u G ? , Contaminate u T 3 7. Create W [ u ] 8. Grant u W ? ; read/write Figure 5 : OKWS message flow for handling user u ’s Web request. exchange and inherit handles to establish the communication paths seen in the diagram. The ok-demux must be certain that it is communicating with the worker processes that the launcher started and wants to avoid trust- ing workers to identify themselves correctly. Thus, the launcher grants a process-specific verification handle to each process it starts. The ok-demux collects these handle values from the launcher. When a worker identifies itself to the ok-demux , it must provide a verification label V containing its verification handle at level 0 , al- lowing the ok-demux to verify that it speaks for the relevant process. Other designs, such as having the launcher mediate initial commu- nication with the workers, would also be possible. In the current prototype, a process crash would necessitate a restart of the whole process suite, though a more mature version of launcher could restart dead processes (as in OKWS on Unix). 7.2 Basic connection handling We now describe the data path of a simple Web request to OKWS running on Asbestos; Figure 5 shows the steps. When a user u makes an HTTP connection: 1. The user-level network server netd accepts incoming TCP pack- ets from the network. Once netd has accepted u ’s connection, it allocates a new port u C to act as a “socket” to which processes can send READ and WRITE messages. The port label, u C R , is set to { u C 0 , 2 } , so that no process can initially send to it. Sec- tion 7.7 describes netd further. 2. As it started up, ok-demux registered with netd to listen for in- coming TCP connections on the machine’s Web port. Therefore, netd notifies ok-demux of the new connection by granting it u C at level ? . 3. ok-demux reads network data from u over port u C until it can authenticate u . Currently, OKWS uses a simple username and password pair, though more sophisticated handshakes are pos- sible. It sends u ’s username and password to OKWS’s identity server, idd , which is described in Section 7.4. 4. If u provided a valid login, idd grants ok-demux two handles corresponding to u , a taint handle u T and a grant handle u G , both at level ? . These handles function like the similarly-named handles in Section 5. 5. ok-demux grants u T ? to netd , which then raises its receive label to contain u T 3 and raises u C R to { u C 0 , u T 3 , 2 } . These changes allow u T -tainted data to escape over the network, but only via u C . From now on, netd will respond to all messages on u C (such as READs) with replies contaminated with u T 3 .
Image of page 9
Image of page 10

You've reached the end of your free preview.

Want to read all 14 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture