A Flexible Security System for Metacomputing Environments

1
A Flexible Security System for Metacomputing
Environments

• A Presentation by
• Kunal Vaishnav
• USC

2
Outline

• Introduction
• Architecture
• Implementation
• Policy Examples
• Related Work
• Conclusion

3
Introduction

• What is a metacomputing environment?
• Why is security needed?
• To protect high-level resources and services
  from one another and from underlying(corrupted)
  resources.
• To protect security policies of the underlying
  resources against attacks from metacomputer
  level.

4
Overview of Legion

• A distributed computing platform.
• Provides a single,coherent environment for a
  collection of independently administered
  machines.
• It provides the means to pull scattered
  components into a single, object-based
  metacomputer.
• High flexibility and site autonomy.

5
Security concerns in Legion

• At the metacomputer level.
• Preserve policy of underlying resources.
• User concern.
• Administrator concern.
• Legion addresses security concerns from earliest
  design phases as incorporating security late can
  be problematic.

6
Design Goals

• Flexibility- the framework must be adaptable to
  different security policies and allow multiple
  policies to co-exist.
• Autonomy-selection and enforcement of security
  policies must be independent.
• Breadth-framework must enable a rich set of
  security policy features.

7
Security Features

• Isolation
• Access Control
• Identity
• Detection and recovery
• Communication privacy and integrity
• Standards.

8
To wrap up Introduction.

• Legion is really a federation of meta- and
  lower-level resources from multiple domains, each
  having its own security policy.
• No central kernel or trusted code base that can
  monitor all interactions b/w users and resources.
• No concept of superuser.

9
Architecture

• Object Model
• Independent,active objects- all entities of
  interest are represented by objects.
• Objects communicate via asynchronous method
  invocations supported by underlying message
  passing system.
• Each method invocation has explicit and an
  optional set of implicit parameters.
• Using data-flow information encoded in in Legion
  method invocations, results are forwarded to
  where they are needed, rather than back to the
  caller.

10
Object Model(contd)

• Legion objects are persistent and are defined in
  one of the two states active or inert.
• When an object is active, it is hosted within a
  running process and can service method
  invocations.
• When an object is inert, its state(OPR-Object
  Persistent Representation) is stored on a
  persistent storage device managed within the
  system.
• Objects implement internal methods to store and
  recover their dynamic state.

11
The concept of LOID

• Each object is identified by a unique,
  location-independent Legion Object Identifier
  (LOID).
• Contains a variable number of variable-length
  binary fields.
• Some fields reserved for system-level
  identification purposes(e.g. Objects class,
  instance no. of the object).
• Additional fields contain information like
  location hints or security information such as
  objects public key.

12
Core Objects

• Legion defines interfaces to a set of basic
  classes that are fundamental to the op. of the
  system, and that support the implementation of
  object model itself.
• Host Objects
• Vault objects
• Class Manager objects.

13
Host and Vault Objects

• Host Objects represent processing resources.
• When a Legion object is activated, it is a host
  object which creates a process to contain the
  newly activated object.
• It controls access to its processing resources
  and can enforce local policies.
• Vault objects represent stable storage for
  containing OPRs.
• Vault objects managers of inert Legion objects
  e.g. they are the point of access control to
  storage resources, and can enforce policies such
  as file system allocation.

14
Class Manager Objects

• They encapsulate the interfaces provided by hosts
  and vaults for processing and storage resources.
• Responsible for managing the placement,activation
  and deactivation of a set of objects of a given
  class.
• Provides a central mechanism for specifying
  policy for a set of like objects(e.g.which
  implementations are valid for instances, which
  hosts are suitable for execution of instances,
  which users may create new instances).
• Serve as a location authority for instances.
• Managed by Meta-Class managers.

15
(No Transcript)
16
Legion Runtime Library

• Supports implementation of Legion objects.
• Provides services analogous to ORB,defining the
  interfaces to services like message passing,
  object control, dynamic invocation control,
  distributed exception handling and so on.
• Flexible, configurable protocol stack.
• All processing on object-caller side and receipt
  side is configured using a flexible event-based
  model.
• Flexibility for drop-in protocol layers for
  object-implementations

17
Security Principles

• Provide a framework for implementing widest
  possible range of application-level and
  resource-level security mechanisms and policies.
• Enable sites to expose their resources to Legion
  in a manner complaint with their local policies.
• Provide s/w which is easy to use for both
  administrators and users.
• Embeds simple,conservative default policies for
  this, which can be overridden.

18
Implementation

• Identity
• Based on LOIDs.
• Public key of the object is an integral part of
  objects name.
• Eliminates public-key tampering as if the key is
  changed a new LOID is created which is not
  recognized by Class Manager objects.
• Drawback- no mechanism for revoking an objects
  key and issuing a new one as this would imply a
  complete change of the objects name.

19
Identity(contd.)

• Object gets its LOID from Class Manager when
  created.
• Class manager assigns a new instance number to
  the object and creates its keys. These are
  communicated to the Host Object where the object
  will run.
• Once object is up,Host object will pass its LOID
  and keys to it so that it can start communication
  with other objects.
• LOIDs cant be easily manipulated as the same
  service object will have diff. LOIDs in diff.
  Legion systems.

20
Context Space

• Context space maps string names to LOIDs.
• Contains string entries which may be linked to
  any kind of Legion object.
• Makes it much easier to identify services and
  objects in a Legion system.
• Risks- focus of the attacker can be the context
  space itself. If the context is compromised, he
  can replace the LOIDs of valid objects with his
  own.

21
X.509 certificates

• The security field of a LOID is actually an X.509
  certificate that contains the RSA public key.
• Signed by CA.
• In case of user not recognizing the CA, it can
  recursively find the recognized CA or the objects
  can have their own policies for handling method
  calls that include certificates they cant
  validate.
• Main use of these certificates is to encode
  public keys in a standard way.

22
Credentials

• Helps the resource in identifying the identity of
  the caller for granting an access request.
• In a distributed object system, users access
  resources indirectly, objects perform action on
  his behalf via a Class Manager.
• The intermediate objects cant be given users
  private key-so the resource needs to call-back
  the user or his trusted proxy when they receive
  the request.
• Drawbacks to this approach-performance,scale,cost.
  
• Solution is to issue credentials to objects.

23
Credentials(contd.)

• Contains a list of rights granted by credentials
  maker,period of validity and who is allowed to
  use the credential.(Default-all)
• When an object requests a resource, it presents
  credentials to gain access.
• Two types of credential- delegated and bearer.
• Delegated credential specifies exactly who is
  granted the listed rights.
• Bearer grants all the rights within it to the
  possessor of the credential.

24
Recovery strategies

• If the long-lived bearer credential is stolen,
  then recovery strategy is to create a new LOID
  for the user.
• The new LOID has a different instance number but
  reuses the users official X.509 certificate for
  its security field.
• The resource providers must then modify
  appropriate system groups and replace users old
  LOID with new one.

25
Credential Refresh

• Conflicting goals in Legion b/w limiting the
  duration of credentials and the valid objects not
  being able to use them for a long time.
• Solution is to expire credential quickly, but
  then the holder can get a fresh one by contacting
  a special Credential Refresh Object owned by the
  user.
• It provides a single pt. of policy for handling
  credential revocation.
• A refresh object needs the ability to sign
  credentials on behalf of the user.However, it is
  risky to give it the users private X.509 key.

26
Credential Refresh(contd)

• What is done is to generate a special public key
  pair when setting up a new Legion user for first
  time.
• The user then signs a special proxy credential
  using his private key.
• This specifies that credentials created with the
  new key pair are same as credential created by
  user.
• The key pair is called proxy keys.
• The Request Object generates a fresh credential
  using the proxy keys. It is sent back along with
  the proxy credential.
• Riskproxy keys can be stolen.

27
Authentication Credentials

• It will authenticate the object with the target
  object, to use the delegated credential it holds.
• It is the LOID of the target and is signed by
  object.
• Sent directly to target .
• Protected from theft en route .
• Necessary as anyone is possession of
  authentication and delegated credential can
  access the target.
• The targets object cant itself misuse the
  authentication credential as the credential holds
  the targets LOID.

28
Key Sharing

• Done to avoid the expense of generating public
  key pairs.
• The LOIDs are still distinct as they have
  different instance numbers, but the security
  fields are the same.
• Drawback- if the private key of one object is
  stolen, all of its partners are immediately
  compromised.
• This risk can be reduced by sharing a key within
  applications or for an interactive session.

29
Access Control

• The ability to call a method on an object.
• Not centralized in any one part of Legion system.
• Each object has its own access control policy.
• Each method call received at an object passes
  through a MayI layer before being serviced.
• MayI is an event in the configurable protocol
  stack.
• It decides whether to grant access according to
  whatever policy it implements.
• On denial, it will respond with appropriate
  exception.

30
Implementation of MayI layer

• The trivial MayI layer can allow all access.
• LRTL provides for a more sophisticated MayI that
  implements ACLs and credential checking.
• ACLs specified for each method in an object-two
  lists for each method Allow and Deny.
• The entries in the lists are LOIDs of callers as
  well as of Group objects.
• The default library MayI is configured when an
  objects starts up.
• The configuration information is passed to it by
  its Class Manager, which in turn may have
  inherited the information from the user.
• MayI is easy to extend using LRTL.

31
Communication

• Legion objects communicate via messages using
  data-flow invocation method.
• A message can be sent in either private mode
  or protected mode.
• In both, certain key elements are encrypted.
• The difference is how the rest of the message is
  encrypted. In private it is encrypted, in
  protected only a digest is generated to provide
  an integrity assurance(default).
• Encryption used to protect bearer credentials.
• These modes also encrypt a computation tag
  contained in every Legion msg.

32
Communication(contd.)

• Tag used to assemble incoming messages from
  multiple objects into a single method call and to
  identify the return value for a call made
  earlier.
• Risk if the attacker knows the computation tag,
  he can forge complete messages.
• Private mode uses the recipients public key to
  encrypt the message.
• Uses DES in CBC mode so that message cant be
  broken in pieces and then recombined again.
• Performance improvement done by DES key caching.

33
Contd

• In protected mode, a digest is calculated and
  then just the credentials and computation tag in
  the message are encrypted for the recipient.
• Faster than private mode.
• The security layer does not provide for mutual
  authentication.
• The sender is assured of the identity of
  recipient as only the desired recipient can read
  the encrypted parts.
• The receiver doesnt care who the actual sender
  is-decision is based on the credentials that
  arrive.

34
Replay

• To prevent replay, each message includes a large
  random number and a timestamp.
• The message timestamps allows coarse-grained
  detection of replays, while random-numbers
  provides the fine grain.

35
Object Management

• Two security concerns.
• Host Objects Vault objects.
• User Admin needs.
• Process Control Daemon.
• One strategy of isolating Legion objects is to
  run them in separate accounts on the host system.
• For users who have accounts on the local system,
  objects can run on their normal user accounts.
• For other, there is a pool of generic resources
  that are assigned for Legion use.

36
Contd.

• Before starting an actual process for the new
  object in the allocated account, the Host needs
  to change the ownership from Vault user-id to
  newly allocated user-id.
• To spawn the actual process that will execute the
  object and to change ownership of the objects
  persistent state the Host needs root permission.
• Access to this is encapsulated in Process Control
  Daemon(PCD).
• PCD is a small program running with root
  permissions on the host, providing services to
  the Host Object.

37
PCD(contd.) and Non-Legion Authentication

• Functions- changing directory ownership and to
  create new processes on a designated account.
• As PCD starts the object running, the Host logs
  an audit trail using the X.509 information.
• Management of object is then done by Host object
  via PCD.
• Non-Legion authentication done via Kerberos.
• Clients obtain specially marked TGTs that can be
  forwarded to proxies for use. Sent in the
  implicit parameters during object creation
  request.

38
Contd.

• Host Object uses the TGT to request a new TGT
  from local Kerberos server.If failed, new TGT not
  recvd.
• The new TGT grants access to a Kerberized version
  of PCD.Host makes an object creation request
  using the local TGT and the name of users local
  account.
• TGTs expire rapidly to support continued
  management of local objects, the PCD will perform
  certain limited actions on behalf of Host without
  TGT.

39
Policy Examples

• Site-local policy examples.
• Site isolation- means no matter how subverted
  any external sites in legion system might be, no
  intruder can invoke methods on local legion
  resources as admin.
• Site-wide required access control- done by
  placing LOIDs on ACL for local file objects.

40
Application Policy Examples

• Resource Selection Policy-done by setting certain
  implicit parameters checked by default Class
  managers.
• Customized Access Control Policies-usually having
  allow and deny lists in ACLs suffices, but if
  they are inadequate then we can introduce a new
  MayI event handler to enforce the desired policy.

41
Related Work

• Globus- a bag of services model for
  metacomputing, in contrast to Legions integrated
  environment approach.
• Legion is fundamentally built into architecture
  of the system, whereas Globus security services
  are provided as add-on modules.
• CRISIS, a security architecture for WebOS
  provides a single,traditional file system and a
  fixed interface for authenticated remote process
  creation.
• No means for adding new mechanisms as they are
  added to WebOS.Also,no modification of existing
  policies is supported.

42
Contd

• Two other projects are Java and Corba.
• JAVA differs from Legion in that it lacks support
  for per-site security mechanisms,delegation and
  user authentication.
• Corba is not a metacomputing system-it does not
  construct an OS like environment using underlying
  distributed resources.

43
Conclusion

• Presented basic security architecture
• Demonstrated that the design is flexible enough
  to a wide-variety of security-related mechanisms.
• Legion has been deployed on many sites like San
  Diego Supercomputing Center and NAVO.

44
References used

• A Flexible Security System for Metacomputing
  Environments,
• Adam Ferrari, Frederick Knabe, Marty
  Humphrey, Steve Chapin and Andrew Grimshaw, High
  Performance Computing and Networking Europe (HPCN
  Europe99) April, 1999.
• Website www.cs.virginia.edu/legion
• For additional papers please visit
• http//www.cs.virginia.edu/legion/papers.htmlse
  curity