Check out the new USENIX Web site. next up previous
Next: Technical Approaches Up: Enclaves Design Previous: System Architecture

Design Rationale

Enclaves follows a design paradigm based on the following observations. First, user-level groups have different characteristics from process-level groups (such as in Isis [3] and Rampart [14]) and require different system-support mechanisms. In particular, group members have common interests but do not normally engage in identical activities.

Second, the object of sharing among group members should be the target of an application rather than the method or the medium used for the application. This is in contrast with many existing groupware systems [5], where sharing typically occurs too far away from the applications. For example, through simple replication, users may share a common text editor or the same X-window display. Sharing at such low levels has a number of problems. A major problem is security. To share a reasonably powerful editor (such as Emacs) or an X window where one can start a Unix shell, all users become one in terms of access privileges and must be totally and mutually trustworthy. This is clearly not an secure or desirable way of sharing. Another problem is undesirable interference. Suppose an Emacs editor is shared among three users, and one user starts a search for a word. Because the editor is shared, the windows used by the other two users will be affected even though they have no interest in looking for this word (e.g., the other users could not type from their keyboards without having interference from the search command that is in effect).

Moreover, user groups need to be flexible in their security controls and must be able to be dynamically formed and dispersed. In today's commonly available technology, to let a user (who might work for a competing company) be part of a group requires setting up a user account and granting the user more access than he is entitled to, sometimes with serious security implications. In Enclaves, users can be admitted to or barred from a group by a simple control mechanism, and group members share exactly those resources that have been explicitly introduced into the group for sharing, not more and not less.

Enclaves runs completely in user space without needing root privilege, and does not need much infrastructural support (such as a multicast kernel).


next up previous
Next: Technical Approaches Up: Enclaves Design Previous: System Architecture

Li Gong
Fri May 17 15:07:56 PDT 1996
?Need help? Use our Contacts page.

Last changed: 1 May 2002 aw
Conference Index
USENIX home