Accessing a Remote File

In this section, we demonstrate how the privileges associated with a CRISIS security domain are used to access a remotely stored file. While our techniques are general, we restrict our discussion to our specific implementation environment. We have built a global file system, WebFS [Vahdat et al. 1997] that allows read/write access to files stored across the wide area. WebFS is implemented at the vnode level [Kleiman 1986], similar to other distributed file systems such as NFS [Walsh et al. 1985] or AFS [Howard et al. 1988].

  

Figure 5: This figure describes the sequence of operations in accessing a remotely stored file through WebFS, a global file system.

To illustrate the protocol for secure file access, we consider the scenario where a process running on Node A attempts access to a file located on Node B. The example is described in Figure 5, with the individuals steps detailed below:

1.

A user process performs an open system call on a WebFS file stored on node B (currently WebFS employs a URL-like hierarchy for naming, e.g., /http/B/foo specifies a file foo stored on node B). The kernel translates this call into a NodeAccess operation in the Vnode layer.

2.

The Vnode layer makes an upcall to a user-level WebFS server to carry out the access request (mode of WebFS functionality is implemented at user-level for ease of debugging and implementation).

3.

The WebFS server contacts the local security manager with the requesting uid/pid pair to ascertain the privileges associated with the process attempting access to the remote file. For UNIX, The security manager maintains mappings between uid/pid pairs and security domains which in turn map to a set of transfer certificates describing the process's privileges.

4.

The WebFS server on node A establishes an SSL connection with the WebFS server on node B, transmitting its own credentials and the credentials of the process requesting file access.

5.

The WebFS server on node B contacts its local security manager to validate the transmitted certificates and to establish any necessary paths of trust to the potentially remote administrative domain containing node A.

6.

Local file ACLs are consulted to determine if the requesting process possesses the request access privileges (e.g. read, write, or execute).

In steps 7-9, the result of the ACL check is returned through the WebFS server on node A, the vnode layer, and finally as the return value to the original open system call.

One concern with any system that allows file access from potentially untrusted machines is that local operating systems must be trusted with the contents of the file. That is, a corrupted operating system (or the local CRISIS security manager for that matter) could allow access to unauthorized users on the same host. Worse, if a machine is compromised after a user logs out, sensitive data could still be lost by inspecting the file/virtual memory cache. CRISIS employs two techniques to address these concerns. First, the CRISIS log out process discards the cache of any user accessed files through a WebFS system call. Next, for remote access to highly sensitive data, CRISIS allows the use of trusted portable computers running CRISIS software supporting mobile login. Using this technique, files are transmitted encrypted end-to-end until they reach the portable, at which point they can be decrypted and cached locally with a higher degree of security.