Security is built into the system from the beginning
Philosophy
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:
- Do no harm. The installation of Legion at a site should not compromise that site's security policies and goals. In general, Legion must not allow unauthorized access to system resources, where resources can be broadly defined to range from user files to root privileges.
- Adapt to local policies. In concert with the first requirement, Legion must be configurable to the security needs of different organizations. Of course, more stringent security constraints generally exact a price in performance and ease of use.
- Provide an access control framework. All local resources are represented in Legion as objects, and the fundamental Legion resource is the ability to call a method on an object. Objects must have flexible access control mechanisms for authorizing and denying method calls.
- Maintain and protect identities. Objects and users have identities that can be used to independently authenticate and authorize one another. These identities are represented through private keys and signed credentials of various types. In a distributed object system, it is often necessary to delegate authority to other objects. Legion should not only protect identities from theft and spoofing, but also minimize the dispersion of authority that delegation causes.
- Protect communication. A Legion system may span public or semi-public networks. Objects must be able to communicate with guaranteed integrity and privacy as needed. Message replay must be detected and prevented.
Model
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.
Security Features
- Public-key cryptography based on RSAREF 2.0.
- Three message-layer security modes: private (encrypted communication), protected (fast digested communication with unforgeable secrets to ensure authentic replies to message calls), and no security.
- Caching secret-keys for faster encryption of multiple messages between communicating parties.
- Auto-encrypted bearer credentials with free-form rights. Propagation of security modes and certificates through calling trees (e.g., if a caller demands encryption, all downstream calls will use it automatically).
- Drop-in addition of MayI functionality to existing objects.
- Persistent authentication objects that serve as the representation for users in a trust domain.
- Secure legion shell to allow users to login to their authentication objects and obtain associated credentials and environment information.
- Isolation and protection of objects using local OS accounts.
- Easily checked Process Control Daemon for granting limited OS privileges to Legion Host Objects.
- Context space configured with access control for multiple users.
Link Description 
Overview A general look at Legion Objectives and constraints Legion's design objectives and restrictions Applications Adapting and running Legion applications Architecture Legion system architecture High-performance computing Using Legion to get high-performance computing Scheduling Scheduling and resource management Security Legion's security philosophy and model
