Security is built into the system from the beginning
Legion is a software infrastructure that unites large collections of heterogeneous computing resources into single, coherent systems. With Legion, users can access scattered resources easily, share data and computing power, and build new meta-applications running across the network. While these possibilities are attractive, users will only adopt Legion if they feel confident that it will protect the privacy and integrity of their existing resources as well as the new resources they create within Legion. Without security, Legion systems can offer some limited uses. But for the full Legion vision of large-scale metacomputers to become a reality, security is essential.
Recognizing this fact, we have made security a part of the Legion design from the beginning. There are five main requirements that must be satisfied:
The security model for Legion differs significantly from that of conventional systems. A Legion "system" is really a federation of resources from multiple administrative domains, each with its own separately evaluated and enforced security policies. As such, there is no central kernel or trusted code base that can monitor and control all interactions between users and resources. Nor is there the concept of a superuser--no one person or entity controls all of the resources in a Legion system.
Legion programs and objects run on top of host operating systems, in user space. They are thus subject to the policies and administrative control of the local OS, and the Legion objects running on a particular host must trust that host. However, there is no requirement for Legion objects to trust other Legion objects. A critical aspect of Legion security is that the security of the overall system does rely on every host being trustworthy. A large Legion system will include multiple trust domains, and even within one trust domain, some of the hosts may be compromised or may even be malicious. For example, two organizations might use Legion to share certain resources in specifically constrained ways. Such sharing would clearly not be acceptable if one organization could subvert the other's objects through its ownership of some part of a Legion system.
These aspects of Legion allow for considerable flexibility in the security policies associated with various Legion objects, which in turn provides the foundation for satisfying the first two security requirements. For example, local policy may require Kerberos authentication, audit logs, resource usage accounting, encapsulation of critical security functionality in small, easily vetted programs, etc. Any of these features can be implemented without departing from the overall model and the minimal assumptions that are made between Legion objects.
Access control for Legion objects first requires that the user determine the security policy for an object by defining the object's rights and the method calls they allow. Access control is then supported via a special member function called MayI present in every object. MayI is Legion's traffic cop: All method calls to an object must first pass through MayI before the target member function is invoked. Only if the caller has the appropriate rights for the target method will MayI allow that method invocation to proceed. The figure below shows a call from object A to object B.
To make rights available to a potential caller, the owner of an object gives it an unforgeable credential that lists the rights granted. When the caller invokes a method on the object, it presents the appropriate credential to MayI, which then checks the scope and authenticity of the credential. Alternatively, the owner of an object can semipermanently assign a set of rights to a particular caller or group. MayI's responsibility is then to confirm the identity of the caller and its membership in one of the allowed groups, followed by comparing the rights authorized with the rights required for the method call.
The means for establishing identity in Legion also address the requirement for protecting communications between objects. Every Legion object has a public key pair; the public key is part of the object's name. Objects can use the public key of a target object to encrypt their communications to it. Likewise, an object's private key can be used to sign messages, providing authentication and nonrepudiation. The integration of public keys into object names allows Legion to avoid the need for a certification authority (although such an authority is still useful for establishing user identities). If an intruder tries to tamper with the public key of a known object, it will create a new name that is unknown.
The combined components of the security model encourage the creation of a large-scale Legion system with multiple overlapping trust domains. Each domain can be separately defined and controlled by the users it affects. When difficult problems arise such as merging two trust domains, Legion provides a common and flexible context in which they can be resolved.
[Testbeds] [Et Cetera] [Map/Search]
This work partially supported by DOE grant DE-FG02-96ER25290, Logicon (for the DoD HPCMOD/PET program) DAHC 94-96-C-0008, DOE D459000-16-3C, DARPA (GA) SC H607305A, NSF-NGS EIA-9974968, NSF-NPACI ASC-96-10920, and a grant from NASA-IPG.