Extending Security for Object-Oriented Models using Security Meta-Objects

Extending Security for Object-Oriented Models using Security Meta-Objects Fahd Arshad Based upon the work of Thomas Riechmann & Franz J. Hauck: Meta Objects for Access Control: Extending Capability-Based Security ACM New Security Paradigms Workshop 97 Proceedings (NSPW97), Great Langdale, UK, 1997.

Basics of Capabilities in Object-oriented Systems • What are objects and how are they related? • What is an object-oriented system (OOS)? • What is Access Control? • What are capabilities and references?

Object A Object C Method P() Method Q() Method R() Object B Object D Data S Data T Illustration: An Object-oriented System

Object A Object C Object B Object D Illustration: An Object-oriented System Objects Subjects

Principles of Capability-based Security • Access based on possession of rights by capability • Allow revocation of rights by issuer • Rights expire after a specified period • Rights are implemented by an attached script

Drawbacks of Capability-based Security • Highly complex exchange maps make proving security • implementation scheme correctness very difficult. • Problems lead to dilution of object-oriented model: larger interfaces and objects and fewer references. • A capability can not prevent method invocations from leaking references to untrusted objects. Propagation restriction is too restrictive a solution. Providing access control explicitly involves amending all existing code, and is not in accord with OOP of encapsulation and reusability.

Object A Object C Object B Object D Domain-based Security • Java and CORBA use domain- and ACL-based security to improve upon capabilities.

Introduction to Security Meta Objects (SMOs) • Assumption: OO programming model that does not allow access except by using object references (e.g. Java and its Byte-code Verifier) • An SMO is an object which can be attached to a reference in order to enforce security. • It can not be detached unless it itself allows

Illustration: SMOs and References Object Variable 1 Variable 2 Variable 3 SMO1 SMO2

Capabilities Implemented As SMOs • Capabilities add three concepts to object references, each ofwhich can be enforced using SMOs: • Restriction of access • Revocation of access • Expiration of access

Implementation: Expiring List SMO List list =.....; // a list reference SecurityMeta smo = new MetaExpire(new Date(12,31,2001)); // create SMO smo.attachTo(list); // connect SMO to object reference // now the reference 'list' is protected list.Get(...); // any call to the list is checked // The implementation of the MetaExpire class: class MetaExpire extends SecurityMeta { final Date d; // expiration date MetaExpire(Date d){// Constructor this.d = d; // store date in “d” } // this method checks calls via protected ref void incomingCall(Object o, Method m, ParameterList p){ // Check if the reference is expired: if (d.isBefore(getCurrentDate())) { // throw exception, if ref. expired throw(new SecException(...)); } } }

Untrusted U list Trusted T smo Illustration: Expiring List SMO

Extending Capability-based Security With SMOs • SMOs cure an important vulnerability in pure systems: lack of access control over references passed to untrusted parts of an application. • Lack of transitive protection: methods can return unprotected objects

Implementation: Transitivity of Access Control • If a method returns an object, it is unprotected. Simple solution: if the original method invocated through a protected reference, SMO is attached implicitly to all outgoing references: // The re-implementation of the MetaExpire class: class MetaExpire extends SecurityMeta { final Date d; MetaExpire(Date d){this.d = d;} void incomingCall(Object o,...){…} void outgoingRef(Object o,...){ // object reference ‘o’ is being returned this.attachto(o); } }

Untrusted U Untrusted V Illustration of a Transitive SMO for List object list Trusted T smo

Untrusted U Untrusted V Illustration: Trojan Horse problem object m list Trusted T smo

Implementation: Trojan Horse solution • If a method returns an object, it is unprotected. Simple solution: if the original method invocated through a protected reference, SMO is attached implicitly to all outgoing references: // The re-implementation of the MetaExpire class: class MetaExpire extends SecurityMeta { final Date d; MetaExpire(Date d){this.d = d; } void incomingCall(Object o,...){…} void incomingRef(Object o,...){ this.reverseAttachto(o); } void outgoingRef(Object o,...){ this.attachto(o); } }

Conclusion SMOs: Capabilities on Steroids • Protected class implementation does not require any support for security. • SMO implementation does not need any special support for protected class and can be used with any class. • General forms of SMO are class-independent and may be reused • Specialized forms may be implemented for method-dependent security.

Questions?

References • Presented by Fahd Arshad for CS428: Operating Systems taught by Dr. Linda Lankewicz at Sewanee in Fall 2000.fahd@acm.org, http://itw.sewanee.edu/Fahd/ • Based on a paper presented to ACM New Security Paradigms Workshop at Great Langdale, UK, 1997 by Thomas Riechmann & Franz J. Hauck • Authors’ web pages:http://www4.informatik.uni-erlangen.de/~fzhauck/http://www4.informatik.uni-erlangen.de/~riechman/

Extending Security for Object-Oriented Models using Security Meta-Objects