| Security Policy Examples Although Legion's flexibility allows the implementation of a wide variety of security mechanisms, application developers and site administrators typically have higher-level policy specifications in mind when using software. The particular underlying mechanisms are less important, as long as the user can be assured that high-level policy requirements are being met. In this section, we consider illustrative examples of how the Legion system architecture and existing Legion tools can be organized to meet site and application policies. Site Isolation A Legion system may consist of multiple domains, each possibly in a different organization or trust. System administrators contributing their resources to a metasystem will typically require certain site-isolation properties. For example, a site that makes its resources available to Legion and is managed by Admin, the local Legion administrator, might decide that no intruder should be able to invoke methods on local Legion resources disguised as Admin, regardless of any subversion in the larger Legion system's external sites. Such a policy is clearly desirable, since Admin is likely to have administrative control over critical local resources--who can use which machine, and for how long, who can access which locally stored OPRs, etc. The ability to invoke methods as Admin would be tantamount to complete control of the local Legion software. The desired isolation policy can be achieved through a number of straightforward safeguards enabled by the Legion framework. First and foremost, all of the core objects managing the local site should be started and configured by Admin. This isolated domain startup avoids any external trust dependencies on outside systems. Then the local domain is connected to some set of external Legion domains, to achieve the desired functionality of a metacomputer. While linked to the external (and untrusted) system, Admin must ensure that no messages containing his credentials are sent to off-site objects, since a subverted or malicious external site could then use Admin's credentials to break the isolation policy. We would like automated enforcement of this safety measure, since Admin might make a simple mistake that could break the policy. This is easy in Legion: Admin simply uses a version of the Legion Runtime Library (LRTL) in which the protocol stack is configured with an extra event handler for the message-send event. If a message containing Admin credentials is inadvertently directed off-site, the message is blocked and the event handler raises an exception. With this simple modification to Admin's Legion environment, he can be assured that his credentials will not be dispersed to untrustworthy off-site objects. Ensuring that Admin does not communicate with off-site objects has a desirable secondary effect: since Admin cannot communicate with external, untrustworthy sites, he cannot place critical objects on resources at these sites. This benefit extends to an array of potentially critical, but not necessarily obvious, resources. For example, suppose that Admin maintains a local Group Object, listing the set of users that are allowed to start objects on local resources. If this object were allowed to execute on an untrustworthy site, its contents could be modified by a malicious resource owner and the local site resource usage policy could be broken. The two mechanisms described above, in combination with carefully configured access control for local core objects (such as Hosts, Vaults, and critical Class Managers), ensure that the desired isolation policy will be met. Off-site objects will be able to neither generate nor steal the local Admin's credentials. External callers will be prevented from invoking unauthorized methods on local critical resources, ensuring that local access control is not tampered with, local resource usage policies are not modified, and that security failures in other domains do not have serious consequences for the local site. Site-Wide Required Access Control The Legion access control model, as presented in the Section entitled "Legion Runtime Library", is based on the assumption that users will configure access control for their own objects. This concept adds a extra level of flexibility to the system: it makes arbitrary resource access policies possible, for example. On the other hand, it initially appears to relinquish a system administrator's ability to set site-wide policies about access control for user objects. For example, the default Legion access control configuration does not grant a Legion domain's administrator access to other users' objects within the domain---there is no root user who can read any file or use any program in the domain. The inability to configure global, site-wide, mandatory access control policies may be unacceptable at some sites. However, the flexibility of the Legion architecture allows us to address this issue in a straightforward fashion using existing tools. As an example of a site-wide required access control policy, consider the problem of strictly limiting access to files by outside users. The Legion system defines a basic File Object that can be used to represent a file in the system. Access control for the normal Legion File Object is based on the default Legion ACL MayI mechanism, which places no restrictions on which LOIDs (i.e., which users) may be placed on access control lists. However, consider a site whose policy says files may not be accessed by outside users. Effectively, we want a way to control which LOIDs may be placed on the access control list for local file objects. We can achieve this by using the local Host Objects' power to control access to local resources. The Host Objects at the site (which are owned and controlled by the local administrator) are a point of resource access policy---they define which types of objects may run at that site. Using this feature, the site administrator can strictly limit the classes of objects that may run at the site. In particular, the allowable set of classes can be limited to those that are approved by the system administrator. The list of allowable classes can be configured to include only file objects with an alternate MayI layer---an extended version of the default access control list mechanism that verifies that the allowed LOIDs are in a well-known group containing only local site users. Given this simple configuration, the site administrator can ensure that local files are not inadvertently exported to outside users through Legion. This approach generalizes to other site-wide access control restrictions, and other similar site-wide policy enforcement problems. Firewalls Firewalls are a simple fact of life at many security-conscious institutions. While firewalls are not explicitly addressed in the Legion model, Legion architecture is flexible enough to accommodate firewalls. A proxy on the firewall host is the natural solution, as is typical in firewall situations. Here, though, the ability to use custom versions of the Legion core objects and the flexible protocol stack model of the LRTL allow proxy-based solutions to be employed in Legion in an especially straightforward, user-transparent way. Objects started on hosts behind a firewall are automatically assigned a Proxy Object on the firewall host by their Host Object (in some cases, each user might desire his or her own proxy object, in other cases a shared proxy object is acceptable--either model is simple to support). If a newly activated object is behind a firewall, its Proxy Object's object address is reported to the new object's Class Manager as the object's address. When callers execute the binding process on the new object, they will be given the Proxy Object's address. The Proxy Object acts as a simple reflector, forwarding any received messages to their intended destinations behind the firewall. Using the Proxy Object to forward outbound messages from callers behind the firewall is automated by a transparent add-in event handler in the LRTL protocol stack. Resource Selection Policy In principle, a metacomputer user shouldn't need to care which resources execute his jobs. In practice, however, the trustworthiness of the resources selected for certain applications is of critical interest. Policies regarding which resources may be used to execute objects are logically localized within the Class Managers of a user's object classes: in principle any site selection policy can be encoded in a user's Class Manager Objects, giving the user total control over selection and use of trustworthy sites. Although this problem is cleanly solved at the architectural level in Legion, we deemed the issue important enough to warrant special features in the default Class Manager Object reference implementations. All default Class Managers in the Legion implementation check for certain implicit parameters that can be used to limit resource selection. By setting these implicit parameters in the Legion environment (with a provided tool), a user can configure a resource selection policy that will propagate to all "create instance" methods called on Class Manager objects on the user's behalf. Of course, the architectural principle that users can encode any resource selection policy they wish in their own Class Manager implementations still holds; a convenient model for such customization is in fact supported by the default Class Manager's ability to be configured to use an external Scheduler Object with a well-known interface. However, in the common case, where a user generates a list of sites that he deems trustworthy and indicates this in his environment, the default implementation provides the needed mechanism to implement a basic, effective resource selection policy.
|
| Link | Description |
 | |
| Introduction | Introduction to the Legion security model |
| Architecture | The fundamental elements of Legion architecture |
| Policy Examples | Meeting site and application needs |
| Conclusions | Summary |
| References | List of references |
