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.
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-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
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 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.