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. Object’s class, instance no. of the object). • Additional fields contain information like location hints or security information such as object’s 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.

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 object’s 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 object’s key and issuing a new one as this would imply a complete change of the object’s 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 can’t 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 can’t be given user’s 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 user’s official X.509 certificate for its security field. • The resource providers must then modify appropriate system groups and replace user’s 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 user’s 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. • Risk:proxy 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 target’s object can’t itself misuse the authentication credential as the credential holds the target’s 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 recipient’s 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 doesn’t 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 object’s 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 user’s 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 Legion’s 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.html#security