The Concept of Self-Defending Objects and the Development of Security Aware Applications
by
John William Holford
Bachelor of Applied Science (Physics), QIT, Australia 1974 Graduate Diploma in Education, UQ, Australia 1975 Graduate Diploma in Computer Science, QIT, Australia 1987 Master of Applied Science (Computing), QUT, Australia 1991
Thesis submitted in accordance with the regulations for the Degree of Doctor of Philosophy
Information Security Institute Queensland University of Technology
May 2006 ii Keywords
Mandatory Access Control, Authorisation, Security Aware Applications, Information Security, Computer Security, Information Technology, Software Engineering, Object Oriented Programming, Programming Paradigms.
iii iv Abstract
The self-defending object (SDO) concept is an extension to the object-oriented pro- gramming paradigm, whereby those objects that encapsulate the protected resources of a security aware application (SAA), are made aware of, and responsible for, the de- fence of those resources. That defence takes two forms, the enforcement of mandatory access control on protected resources and the generation of the corresponding portion of the SAA’s audit trail. The SDO concept acts as the philosophy that guides the ap- plication level mandatory access control within SAAs which ensures that the provided access control is both complete and non-bypassable. Although SDOs accept responsibility for controlling access to the protected data and functionality that they encapsulate, an SDO delegates the responsibility for mak- ing authorisation decisions to an associated authorisation object. Thus, SDOs fulfill their access control obligations by initiating the authorisation check and then enforc- ing the decision made on their behalf. A simple, yet effective mechanism for enforcing that access control at the object level involves controlling the ability to invoke those SDO methods that access protected resources. In the absence of previous research on this approach to the enforcement of appli- cation level access control, the primary aim of this research was to demonstrate that the SDO concept is a viable paradigm for developing SAAs. That aim was achieved in two stages. The first stage targeted the provision of a ‘proof of concept’, that demon- strated that the SDO concept could be applied to the development of non-distributed SAAs. The second stage demonstrated its applicability to the development of dis- tributed SAAs. In the second stage, two versions of a distributed prototype were de- veloped, one based on a traditional (proprietary) distributed computing model, (Java RMI), and the second using the currently popular Web services model, to demonstrate the general applicability of the SDO concept. Having already demonstrated that the SDO concept could be applied to SAAs executing on a single machine, the major fo- cus of that research was to devise a mechanism by which SDOs could be transferred
v between machines. The research then concentrated on determining what impacts the adoption of the SDO concept would have on SAA development. Experimentation carried out using the distributed prototypes demonstrated that (1) the adoption of the SDO does not restrict the use of inheritance hierarchies that include SDOs, (2) the restriction of the lifetime of SDOs can be supported, (3) usage rights enforcement can be employed, and (4) the use of cryptographic techniques to provide additional security guarantees is not affected. A key feature of the SDO concept, is that no major changes need to be made to current development tools or methodologies, so its adoption is not hampered by significant financial or training impediments. This research demonstrated that the SDO concept is practical and constitutes a valuable extension to the object oriented paradigm that will help address the current lack of security in information systems. The SDO approach warrants additional re- search and adoption.
vi Contents
Keywords iii
Abstract v
Declaration xxi
Previously Published Material xxiii
Acknowledgements xxv
1 Introduction 1 1.1 Objectives of the Research and Investigation ...... 2 1.1.1 Objectives for Stage 1: Proof of Concept for SDOs ...... 2 1.1.2 Objectives for Stage 2: SDOs in Distributed Environments . . 3 1.2 A Need for a Change to the Object-Oriented Programming Paradigm . 4 1.2.1 Greater Security is Required ...... 5 1.2.2 The Object-oriented Paradigm ...... 7 1.2.3 Providing Improved Security ...... 8 1.3 What are Self Defending Objects (SDOs)? ...... 9 1.4 The Origin of SDO Concept ...... 10 1.5 Limitations of the SDO Concept ...... 12 1.6 Thesis Outline ...... 12
2 Literature Review 15 2.1 The Notion of Objects and their Realisation ...... 17 2.1.1 Classes and Objects ...... 17 2.1.2 Encapsulation, Inheritance and Polymorphism ...... 18 2.2 Web Services ...... 20 2.2.1 Extensible Markup Language (XML) ...... 22
vii 2.2.2 Universal Description, Discovery and Integration (UDDI) and Web Services Description Language (WSDL) ...... 23 2.2.3 Simple Object Access Protocol (SOAP) ...... 24 2.2.4 WS-Security ...... 25 2.2.5 Web services are still insecure ...... 27 2.3 Objects Protecting Encapsulated Resources ...... 28 2.3.1 Digital Rights Management ...... 28 2.3.2 Self-Securing Devices ...... 29 2.3.3 Self Protecting Objects in Object-oriented Databases ..... 31 2.4 The Need for Security — HIPAA ...... 32 2.4.1 eHealth and SDOs ...... 33 2.5 Related Operating System Concepts ...... 34 2.5.1 Mandatory and Role Based Access Control ...... 34 2.5.2 Information Security Models ...... 36 2.5.3 Trusted Operating Systems ...... 38 2.5.4 Trusted Computer System Evaluation Criteria ...... 40 2.5.5 Common Criteria ...... 41 2.6 Access Control and Security Policies ...... 43 2.6.1 Specifying and Enforcing Application Level Security Policy . 43 2.6.2 Enforcing Application Level RBAC ...... 45 2.7 Trusted Computing Group and Trust Establishment ...... 48 2.7.1 The TCG Specification ...... 48 2.7.2 Remote Attestation ...... 50 2.7.3 Implications for SDOs ...... 52 2.8 Mobile Agents ...... 52 2.8.1 The Mobile Agent Model ...... 52 2.8.2 Securing Mobile Agent Platforms ...... 54 2.8.3 Securing Mobile Agents ...... 55 2.8.4 Applicability of Mobile Agent Techniques to SDOs ...... 55 2.9 AspectJ — Aspect-Oriented Programming for Java ...... 56 2.9.1 AspectJ and SDOs ...... 57 2.10 Summary ...... 57
3 A Review of Java’s Security Features 59 3.1WhyJava? ...... 59 3.2 Java’s Support for Security ...... 60
viii 3.2.1 The Java Language ...... 61 3.2.2 Securing the Java Platform ...... 61 3.2.3 The Evolution of the Java Security Architecture ...... 62 3.2.4 Security Managers ...... 64 3.2.5 Security Policies ...... 65 3.2.6 Java Authentication and Authorization Service Framework . . 67 3.2.7 Java Support for Object Protection ...... 69 3.3 The Java Virtual Machine ...... 71 3.3.1 Introducing the Java Virtual Machine ...... 71 3.3.2 The Architecture of the JVM ...... 76 3.4 Summary ...... 84
4 Applying the SDO Concept 87 4.1 A Human Resources Example ...... 89 4.1.1 HR Example - Design Details ...... 91 4.2 Implementing Authorisation ...... 93 4.2.1 Authorisation Objects and SDOs ...... 94 4.2.2 Propagating Policy Updates ...... 97 4.2.3 Controlling Access ...... 99 4.2.4 Potential Problems with SDO-based Authorisation ...... 102 4.3 Provision of a Complete Audit Trail ...... 103 4.3.1 Audit Log Overview ...... 104 4.3.2 SDOs and the Audit Log ...... 105 4.3.3 Problems with Auditing SDO-based Systems ...... 106 4.4 Characteristics of SDO Classes ...... 107 4.4.1 Implementing SDO Inheritance Hierarchies ...... 107 4.4.2 Maximum Lifetimes for SDOs ...... 110 4.5 Using SDOs ...... 114 4.5.1 Authorising Access to an SDO’s Protected Content ...... 114 4.5.2 Accessing Protected Resources ...... 115 4.5.3 Returning an SDO from a Method ...... 116 4.5.4 Returning the Information in a Collection of SDOs ...... 118 4.6 Handling Usage Rights ...... 119 4.7 SDOs and Cryptography ...... 120 4.7.1 Protection of Data in Transit ...... 121 4.7.2 Protection of Data within SDOs ...... 122
ix 4.8 Summary ...... 127
5 The SDO Concept in Java Non-distributed Applications 129 5.1 The CD Catalog Prototypes ...... 130 5.1.1 The Starting Point for the Prototype ...... 131 5.2 Applying the SDO Concept ...... 135 5.2.1 The Conversion Process ...... 136 5.2.2 The Self-Defending CD Catalog Prototype ...... 143 5.3 Authentication and Authorisation in the CD Catalog Prototype ...... 144 5.3.1 JAAS Authentication ...... 145 5.3.2 Authorisation Credentials ...... 149 5.3.3 The Authorization Process ...... 151 5.3.4 Audit - Logging Authorisation Events ...... 155 5.4 JAAS Authorisation and the CD Catalog Prototype ...... 157 5.4.1 Extending JAAS Authorisation to Non-System Resources . . 157 5.5 SDOs and Windowing Environments ...... 162 5.5.1 Threads in Windowing Environments ...... 162 5.5.2 Excessive Authorisation Checking ...... 163 5.6 Conclusions ...... 165
6 The SDO Concept in Distributed Java Applications 169 6.1 The HR System Prototype ...... 170 6.1.1 HRIS Overview ...... 170 6.2 The Non-distributed Prototype ...... 174 6.3 The Initial RMI Prototype ...... 176 6.3.1 The RMI Model ...... 177 6.3.2 Using RMI to Create the SDO-based HRIS ...... 179 6.3.3 SDOs in a RMI Environment ...... 181 6.4 The Web Services Prototype ...... 183 6.4.1 A Web Services - SDO Mismatch ...... 184 6.4.2 Special Classes for the Web Services Prototype ...... 188 6.4.3 Observations Regarding the Web Services Prototype ..... 191 6.5 The RMI Prototype ...... 192 6.5.1 Implementing the RMI Prototype ...... 192 6.6 Securing Network Communications ...... 193
x 6.6.1 Securing Communications in the RMI Prototype ...... 194 6.6.2 Securing Communications in the Web Services Prototype . . . 195 6.7 SDOs and Inheritance Hierarchies ...... 196 6.7.1 Authorisation and SDO Inheritance Hierarchies ...... 196 6.8 Usage Rights and SDO Lifetimes ...... 201 6.8.1 Usage Rights ...... 202 6.8.2 Implementing SDO Lifetimes ...... 208 6.9 Usefulness of AspectJ ...... 211 6.9.1 The Investigation Performed ...... 212 6.10 Closing Comments ...... 217
7 The SDO Support Environment 219 7.1 SAA Life Cycle and the SDO Concept ...... 220 7.1.1 Development Environment ...... 221 7.1.2 Commit Environment ...... 222 7.1.3 Deployment Environment ...... 223 7.1.4 Execution Environment ...... 223 7.2 Protecting the Execution Environment ...... 224 7.2.1 Trust Establishment ...... 224 7.2.2 Security Policy Distribution ...... 228 7.2.3 Web Services Support ...... 228 7.3 The SDO Support Environment API ...... 229 7.3.1 Authentication Services ...... 230 7.3.2 Authorisation Services ...... 231 7.3.3 Audit Services ...... 233 7.3.4 Cryptographic Services ...... 235 7.4 Summary ...... 235
8 Conclusions and Future Work 239 8.1 Conclusions ...... 239 8.1.1 The Research Outcomes ...... 239 8.1.2 The Strengths ...... 241 8.1.3 The Weaknesses ...... 242 8.2 Future Work and the Potential for SDO Concept ...... 247 8.2.1 Scalability ...... 247 8.2.2 Application to Non GUI Application Domains ...... 247
xi 8.2.3 Application to e-Health ...... 247 8.2.4 SDOs Adapt to their Environment ...... 247 8.2.5 Audit ...... 248 8.2.6 Critical Infrastructure ...... 248 8.2.7 Pervasive Computing ...... 249
A WSDL Description of the EmployeeServer 251 A.1 Command to generate WDSL Description ...... 251 A.2 Configuration File: “xml gen config.xml” ...... 251 A.3 The EmployeeServer Interface ...... 251 A.4 WSDL Description of the EmployeeServer ...... 254
B SOAP Messages captured at Server 261 B.1 get Request Message ...... 261 B.2 get Response Message ...... 262
C The HRWebServicesConnection Class 265
D Class SDOClassConverter 273
E Enabling Application and Link level Protection 283 E.1 Security Configuration File: “encrypt-server.xml” ...... 283 E.2 Security Configuration File: “encrypt-client.xml” ...... 284 E.3 An Non Encrypted delete Request Message ...... 284 E.4 An Encrypted delete Response Message ...... 285
F The aspect EmployeeSDOAspect 287
G APIEMS’04 Conference Paper 295 G.1 INTRODUCTION ...... 296 G.2 BACKGROUND INFORMATION ...... 297 G.2.1 Security Aware Applications & Access Control ...... 297 G.2.2 Self-Defending Objects (SDOs) ...... 299 G.2.3 Issues In Wireless Local Area Networks ...... 299 G.2.4 Context Aware Computing ...... 300 G.2.5 Incorporation Of Location Within Security Applications . . . 301 G.2.6 Self Securing Devices ...... 301 G.2.7 Critical Control Systems ...... 302
xii G.3 MOTIVATION ...... 303 G.4 THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE . 305 G.4.1 Self-defending Objects And Control Systems ...... 306 G.4.2 Overview Of The Access Control Mechanism ...... 307 G.4.3 The Authorisation Mechanism ...... 307 G.4.4 Authorisation Communication Protocols ...... 309 G.5 AN IMPLEMENTATION SCENARIO ...... 312 G.5.1 Analysis Of The Infrastructure ...... 313 G.5.2 Four Scenarios ...... 313 G.6 CONCLUSIONS ...... 315
Bibliography 317
xiii xiv List of Figures
3.1 Possible realisation of two objects of a class C ...... 76 3.2 Logical organisation of the JVM ...... 77 3.3 Organization of the Java Stacks Data Area ...... 83
4.1 A Simple Organisational Hierarchy ...... 90 4.2 A hruser view of an executive’s record in the HR Prototype ...... 92 4.3 Interaction with Audit Log ...... 106 4.4 The propagation of an (Executive.) getSalary call ...... 109
5.1 The Original CD Catalog GUI ...... 133 5.2 CD Catalog Program GUI ...... 143 5.3 Overview of the Self-Defending CD Catalog Prototype ...... 145 5.4 Dialog used for User Authentication - PasswordDialog ...... 148 5.5 The ListGUI Object ...... 164
6.1 HRIS Overview ...... 171 6.2 The HR System GUI ...... 175 6.3 Overview of the Initial RMI-based HRIS ...... 177 6.4 The RMI Mechanism ...... 178 6.5 Transferring SDOs in a Web Services Environment ...... 185 6.6 Overview of the RMI-based HRIS ...... 193 6.7 A Listing of All Personnel Records ...... 207 6.8 A Printable Listing of All Personnel Records ...... 207 6.9 The ListGUI after Employee lifetimes have expired ...... 210
7.1 SAA Life Cycle ...... 221
G.1 Control System ...... 303 G.2 The Authorisation System ...... 308
xv xvi List of Tables
5.1 Class List for the original CD Program ...... 134 5.2 Application-Level Access Control Rules ...... 137 5.3 Extract from the Method Authorisation Table ...... 154 5.4 Extract from the Data Authorisation Table ...... 154 5.5 Extract from the Audit Log Policy Table ...... 156 5.6 Extract from the Audit Log Table ...... 157
6.1 Security policy extract for the data member Salary ...... 196
G.1 Protocol Notations ...... 310
xvii xviii Listings
3.1 Security policy file security.policy ...... 66 3.2 Running the application ExampleApplication subject to the security policy security.policy ...... 67 5.1 Security Policy for CDProgram ...... 138 5.2 Method Signatures for class CatalogModel ...... 140 5.3 Method Signatures for the SDO class CatalogModel ...... 140 5.4 Typical SDO Code used to Perform Method Authorisation ...... 141 5.5 Typical SDO Code used to Perform Data Authorisation ...... 141 5.6 Running the CD Catalog application catalogSDO.CDProgram .... 147 5.7 JAAS Configuration File jaas.config ...... 147 5.8 Code required to authenticate a user using JAAS Authentication . . . 148 5.9 Public methods of the authorisation token class UserID.java ..... 150 5.10 Method Signatures for the class SDOAuthorisation ...... 153 5.11 Method Signatures for the class SystemLog ...... 156 5.12 Part of the JAAS Security Policy for role user ...... 159 5.13 Using AccessControlContext-based Authorisation ...... 161 5.14 Obtaining an AccessControlContext ...... 162 6.1 Authorisation in the HRIS ...... 173 6.2 Extract from Interface EmployeeServer ...... 179 6.3 Instantiating the EmployeeServerImpl Server Object ...... 181 6.4 Obtaining a Server Object Reference ...... 181 6.5 Extract from Class HRWebServicesConnection ...... 186 6.6 Extract from Interface EmployeeServer ...... 186 6.7 The Method HRWebServicesConnection.get ...... 187 6.8 The Method SDOClassConverter.convertToSDOEmployee ...... 189 6.9 setSalary methods from the Employee and Executive Classes . . . . . 197 6.10 canSetSalary method from the Executive Class ...... 199
xix 6.11 Signature Updating in the Executive Class ...... 200 6.12 Cryptographic Functionality in the Executive Class ...... 201 6.13 The interface UsageRights ...... 204 6.14 Lifetime checking in UserID.checkSignature() ...... 209 6.15 Lifetime checking in StringArrayList.get ...... 211 6.16 Extract from the Executive class ...... 213 6.17 Proposed replacement methods for the Executive SDO class ..... 214 6.18 Extract from the EmployeeSDOAspect aspect ...... 215 7.1 The authenticator interface SDOAuthenticator ...... 230 7.2 The authorisor interface SDOAuthorisor ...... 232 7.3 The application log interface ApplicationLog ...... 234 7.4 The cryptographic functionality interface CryptoFunctionality .... 236
xx Declaration
The work contained in this thesis has not been previously submitted for a degree or diploma at this or any other higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made.
Signed: ...... Date: ......
xxi xxii Previously Published Material
The following papers have been published or presented, and contain material based on the content of this thesis.
[1] John W Holford, William J Caelli, and Anthony W. Rhodes. The concept of self-defending objects in the development of security aware applications. In 4th Australian Information Warfare and IT Security Conference, Adelaide, Australia, 2003.
[2] John W Holford, William J Caelli, and Anthony W. Rhodes. Using self-defending objects to develop security aware applications in java. In V Estivill-Castro, editor, 27th Australasian Computer Science Conference, volume 26 of Conferences in Research and Practice in Information Technology, pages 341–349, Dunedin, New Zealand, January 2004. Australian Computer Society.
[3] Harikrishna Vasanta, John W. Holford, William J. Caelli, and Mark Looi. Ar- chitecture for securing critical infrastructures using context-aware self-defending objects. In Erhan Kozan, editor, Fifth Asia-Pacific Industrial Engineering and Management Systems Conference 2004 (APIEMS 2004), page 292, Brisbane Aus- tralia, December 2004. Asia Pacific Industrial Engineering and Management So- ciety, Kozan, Erhan. Abstract only, Papers on CD-ROM ISBN 0-9596291-8-1.
xxiii xxiv Acknowledgements
I wish thank my principal supervisor Prof. William Caelli, AO who both proposed the concept of self-defending objects and provided invaluable insight that guided my re- search and thesis preparation. I also wish thank my associate supervisors Dr. Anthony Rhodes and Prof. Peter Croll for their support and guidance.
Sun and Java are registered trademarks of Sun Microsystems. .Net and NGSCB are registered trademarks of Microsoft Corporation.
xxv xxvi Chapter 1
Introduction
The aim of this research is to investigate whether an extension to the object-oriented programming paradigm, based on the Self-Defending Object (SDO) concept, can en- hance the protection provided by object-oriented, Security Aware Applications (SAAs). An SAA is any application program that exhibits behaviour that is based on security information. In most cases, that behaviour will be dictated by the requirement to en- force fine-grain, application-specific security policies, and to respond intelligently to the occurrence of security problems. In the context of this research, the SAAs of in- terest are those which exhibit behaviour that is dependent on who (or what process) is using the protected resources of the application. The SDO concept can be paraphrased as: “any object in an object-oriented pro- gram, that encapsulates security-sensitive resources1, should be made aware of, and take responsibility for, defending those resources from access by unauthorised users”. An SDO is therefore responsible for the enforcement of that portion of the appli- cation’s security policy that relates to its encapsulated resources, i.e. it will enforce mandatory access control2 on its encapsulated sensitive resources.
1In this context, a ‘security-sensitive resource’ might take the form of either data or functionality, that was identified within the application’s security policy as requiring protection from unrestricted access. 2In most cases, it is expected that role based access control (RBAC) model, rather traditional manda- tory access control, will be enforced.
1 2 Chapter 1. Introduction
1.1 Objectives of the Research and Investigation
The specific research objectives have been categorized according to the research stage in which the objectives were either met, or research was conducted. The first stage of the project culminated in a demonstration of the ‘proof of concept’ for the SDO concept, more specifically its application in non-distributed applications. The second stage concentrated on the application of the SDO concept in distributed environments.
1.1.1 Objectives for Stage 1: Proof of Concept for SDOs
The first stage investigated the role which SDOs might play in the development of non-distributed, custom built3, security aware applications. The major objectives of this stage of the research were:
• To undertake an extensive literature survey to determine what research had or is currently being carried out in that and related areas,
• To devise a mechanism that will enable the enforcement of mandatory access control at the software object level,
• To determine whether the SDO concept can be successfully applied to the de- velopment of SAAs,
• To identify any difficulties inherent in the application of the SDO concept
• To explore different SDO implementation strategies to gauge the general appli- cability of the concept and to devise guidelines for its future use in production environments,
• To determine whether any modifications to existing object-oriented program- ming languages are either required, or desirable, to enable them to better support the SDO concept, and
• To determine whether the SDO concept can be used to retrofit access control to legacy (object-oriented) applications.
3A custom built application is one that is constructed using object classes that have been specifi- cally developed for the application or those classes that are provided by the programming language’s development environment. In particular the construction of application programs primarily through the composition of general purpose components, is excluded. 1.1. Objectives of the Research and Investigation 3
The literature survey had confirmed our belief that no research had, or was cur- rently being carried out, into making those software objects that encapsulate an SAA’s protected resources, responsible for their protection through the enforcement of manda- tory access control4. In the absence of previous research, demonstrating that the con- cept was viable was the major focus of this stage of the research. The concrete outputs from the first stage of the research were: a number of versions of a small prototype application that acted as a ‘proof of concept’, and two conference papers [1, 2]. Those papers introduced the SDO concept and discussed the lessons learned from having applied the SDO concept to the development of those prototypes. The development of these prototypes, using a standard Java release, demonstrated that the application of the SDO concept was practical, and that the SDO concept could be applied using multiple mechanisms supported by the Java application programmers interface (API). Further, no modifications to the Java language, or its API were re- quired (or desired), to support the SDO concept. A detailed discussion of the lessons learned while conducting this research is presented in Chapters 4 and 5.
1.1.2 Objectives for Stage 2: SDOs in Distributed Environments
Within object-oriented distributed applications, most information is transmitted be- tween application hosts in the form of objects5. When the SDO concept is adopted, whenever security sensitive information is being transferred, those objects that encap- sulate that information should be ‘self-defending’. Such an approach will ensure that the application-specific access control policy that dictates access to that information, will continue to be enforced by the SDO, irrespective of the location of the informa- tion. In this stage of the research, the application of the SDO concept to the development of SAAs that used two orthogonal distributed computing models was investigated. The first model was a conventional proprietary distributed programming model, Java RMI6, while the second was the currently popular Web services model. The aims of this second stage of the research, that correspond to the milestones to
4A summary of research conducted in related fields forms the basis of the literature review of Chapter2. 5Similarly, when messages are passed between objects within the same program, the majority of the message content is in the form of objects. 6The implementation language that was chosen for prototype development was Java. Consequently, the distributed application development model chosen was Java Remote Method Invocation (RMI), a model that is both extensively used within distributed Java applications and fully supported by the Java API. 4 Chapter 1. Introduction be attained to fulfill the vision of SDO-based distributed computing, are:
1. To devise a mechanism for the secure migration of SDOs between the hosts of distributed Java RMI-based applications.
2. To develop a prototype distributed Java RMI-based client-server application in which SDOs, rather than normal objects, are transferred between the client and server.
3. To devise a mechanism for the secure migration of SDOs within Web services based applications.
4. To develop a distributed Web services based prototype in which SDOs, rather than normal objects, are transferred between the Web Service provider and the Web Service requester.
5. To further investigate the ability of the SDO concept to accommodate the re- quirements of SAA development.
6. To verify that the use of the SDO concept is compatible with requirements of systems developers, in particular the use of hierarchies of SDOs can be sup- ported
7. To investigate the role that aspect oriented programming languages might play in the supporting the SDO paradigm.
8. To investigate the role which SDOs might play in the defence of peripheral and control devices.
The concrete outputs from this stage of the research have been a single conference paper describing the potential use of SDOs in the protection of critical infrastructure; and two implementations of a distributed application, one based on Java RMI model and the other based on the Web services model. The results of the research carried out during this stage are discussed in detail in Chapters 6 and 7.
1.2 A Need for a Change to the Object-Oriented Pro- gramming Paradigm
The need for improved computer security is well known. In this section, factors that have contributed to that need are outlined and the dominance of the object-oriented 1.2. A Need for a Change to the Object-Oriented Programming Paradigm 5 programming paradigm in current application development is identified. Consequently, any attempt to provide increased the security within SAAs, must necessarily be ap- plied in the context of the object-oriented paradigm.
1.2.1 Greater Security is Required
The last decade has seen a profound shift in how industry and government agencies manage their information systems. Information systems are now almost universally interconnected and often integrated with external systems; responsibility for the pro- vision and support for those information systems has been delegated (outsourced), and those information systems operate in computing environments protected by com- mercially available operating systems that are known to be insecure. The need for improved security is now paramount. New security paradigms, that reflect the new information security reality, are desperately needed. The SDO concept is a new se- curity architecture that addresses part of that need; the provision of a new paradigm that guides the provision of access control within SAAs that must operate in this new world. This section details the security implications of each of these trends, and then identifies how the SDO concept can help meet the emerging security needs.
1.2.1.1 World-wide Interconnection of Information Systems
No longer are information systems isolated from the rest of the world or developed and supported from within the organisation. Instead information systems have been increasing interconnected, a trend fueled by the increasing internationalisation of or- ganisations, the drive to integrate their information systems with those of trading part- ners to maximise profits, to support the insatiable thirst for information and to reap the profits that can be made through the conducting of trade on the Internet. The availabil- ity of gigabit type broardband services supports this exchange of information. Today, nearly all computers are connected via the Internet, irrespective of whether those com- puters are used by government, industry or are privately owned.
1.2.1.1.1 Web Services The need to integrate information systems has spawned a new Standards-based distributed programming model, Web services. That model overcomes the problems associated with providing remote procedure call semantics within heterogeneous systems. Reliance on the Internet and the adoption of Web ser- vices are becoming increasingly inter-twined as Web services becomes the mechanism 6 Chapter 1. Introduction for providing inter-application integration on the Internet7. The success of Web ser- vices model is fueled by its ability to make business to business e-commerce on the Internet, both easier and less expensive. Inherent in the provision of such interac- tion is the exposure of critical business processes (as Web services), to enable their automated interaction with the information systems of business partners. Achieving application to application integration, is reliant upon making the pro- gramming interface available to business partners. The Web services architecture in- cludes Standards that: (1) enable the availability of Web services to be advertised in publicly accessible depositories, (2) make those depositories searchable allowing suit- able services to be located, and (3) support the download of the complete description selected Web service. Given that Web service description, readily available software tools automatically generate the code needed to interact with the Web service8. The availability of such support, makes the adoption of the Web services model very at- tractive. However, the security implications of using Web services are significant despite the development of standards that enable Web services communications to be secured. A major problem still remains. The publication, on the Internet, of the programming interface for a Web service is as valuable to attackers, as it is to legitimate users of the Web service. The attacker can also automatically generate the code needed to interact with the service. Armed with the detailed knowledge of the Web service API, includ- ing the usage details for each available method, attackers can employ techniques used by application testers to locate flaws in software, e.g. they can probe for vulnerabilities by using extreme or unexpected parameter values. Current application development techniques are not sufficient to provide the in- creased level of trust required of a Web service implementation. The SDO concept helps to address this inadequacy.
1.2.1.2 Delegation of Responsibility for Information Systems
At the same time, both government and industry are relinquishing responsibility for the provision and support of their information systems. In an attempt to reduce costs associated with maintaining their indispensable information system, outsourcing (both nationally and increasingly off-shore), has become the ‘optimal’ mechanism for man-
7According to Zhang [3], “A variety of Web services appear daily, and an increasing number of software producers announce products that are Web-service-enabled.” 8Section 2.2 provides a introduction to the Web services architecture and selected supporting stan- dards, including those that were developed to secure Web services. 1.2. A Need for a Change to the Object-Oriented Programming Paradigm 7 aging their information needs. The management of their information systems are no longer reliant on their in-house expertise, but is instead reliant upon contractual ar- rangements with service providers. The benefits of outsourcing, particularly offshore outsourcing, is primarily con- cerned with cutting costs and gaining access to specialised expertise not available internally [4]. However the benefits of outsourcing come at the expense of increased data insecurity [5], “most companies give little or no concern to the protection of data they send to the outsourcers” [6].
1.2.1.3 Operating System Insecurity
Commercial operating systems and their associated system tools were not designed with security in mind and the vulnerabilities that are regularly identified in such soft- ware, undermine what security they propose to provide9. Associated with this inse- curity is a proliferation of viruses, and related malware, that take advantage of these system level vulnerabilities.
1.2.2 The Object-oriented Paradigm
The object-oriented (OO) paradigm has become the programming paradigm of choice for most new software development due to the commercial success of such program- ming languages as C++, Java and the .Net family of languages10. Unlike previous programming models, the object-oriented paradigm is data-centric, rather than code- centric11. Objects typically encapsulate both data and code, with the code providing the functionality that must be associated with data to make it useful. Current OO languages such as Java and C# are designed to be secure. Language constructs that are known to lead to programming errors have been removed from the language. Support for security has been especially prevalent in Java, the securing
9In January 2002, Bill Gates (Microsoft) sent an email to all full time employees [7] in which he announced the company’s commitment to Trustworthy Computing and contrasted it to the current situation “Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness in computing. . . . Every week there are reports of newly discovered security problems in all kinds of software, from individual applications and services to Windows, Linux, Unix and other platforms.” 10It might be argued, the use of software components [8] and Web services, are currently becoming the dominant development paradigms. However as these higher-level programming constructs are typ- ically implemented using object-oriented languages, the dominance of object-oriented languages will remain. 11The object oriented paradigm is discussed in greater detail in Section 2.1. 8 Chapter 1. Introduction computing systems from potentially malicious code (applets) has always been a ma- jor design goal. Consequently, restrictions have always been placed on mobile code. The Java security architecture currently allows such restrictions to be placed on both applets and application code. The code’s right to access protected system resources can be defined in terms of the origin of the code, the presence of a trusted signature and who is running the code. An extended review of the security features of the Java language and the Java Virtual machine are presented in Chapter 3
1.2.3 Providing Improved Security
In response to the need to improve computer security but the apparent lack of will- ingness on the part of the information technology sector to address that problem as a matter of urgency, legislators are beginning to demand an improvement. Already, legislation has mandated the provision of adequate security within critical application domains, e.g. the US HIPAA legislation which requires the securing of health records (see Section 2.4). The computer industry is beginning to adopt the idea of trusted computing. The Trusted Computing Group (TCG)12 has defined the specifications for a hardware com- ponent, the Trusted Platform Module. Microsoft is employing its implementation of a trusted platform module as the foundation for its Next Generation Secure Computing Base (NGSCB) architecture. The NGSCB will be incorporated into Longhorn, the next generation of Microsoft operating systems. Also, the National Security Agency (NSA) has conducted research into the viability of enhancing the security of commer- cial operating systems through the provision of role based access control (RBAC) and significant aspects of Mandatory Access Control (MAC) structures. The NSA has re- leased a patch for Linux to create a security enhanced version of Linux, SELinux [9]. To address the current deficiencies in computer security, much more needs to be done. Radically different security paradigms are needed. A major thrust must relate to the improvement in application security. Such improvements will involve further re- finement of the security models enforced OO language runtime systems and new ways of using the available security primitives to secure applications. The SDO paradigm partially addresses the need to make better use of the available language support. It represents a major shift in the role of objects in SAAs. The SDO paradigm provides a framework for systematic application of mandatory access control at the object level. Further, the use of SDOs to encapsulate the application’s sensitive resource is expected
12The work of the TCG is discussed in detail in Section 2.7. 1.3. What are Self Defending Objects (SDOs)? 9 to ensure that those access control measures are appropriate, and that such access re- strictions continue to be enforced even after that information leaves the ‘information server’.
1.3 What are Self Defending Objects (SDOs)?
The SDO concept is proposed as an important extension to the object-oriented para- digm that specifically targets some deficiencies in the development of SAAs . Specif- ically, the extension targets two requirements of SAAs: (1) the need to ensure that access to protected data and functionality, is in accordance with the application’s se- curity policy, and (2) all attempted accesses to those protected resources are included within the application’s audit trail (subject to the application’s audit policy). The SDO approach aims at defining new concepts related to the growing requirement for infor- mation assurance in information systems. An SDO is an object that encapsulates sensitive data and/or provides sensitive functionality, that has been made aware of, and assumes responsibility for, the protec- tion of those sensitive resources. Such protection is afforded through the provision of a type of mandatory access control called role based access control (RBAC)13. Since SDOs are responsible for defending their protected functionality and data from unau- thorised access, they are referred to as being self-defending. The cornerstone of the research is the belief that the introduction of the SDO concept into the current object- oriented programming paradigm both simplifies the development of SAAs and ensures the completeness of their access control and audit measures. A distinguishing characteristic of the methods provided by SDOs is the presence of an additional parameter, by convention the first parameter, an authorisation token. That token acts as the source of the user information to be incorporated within an audit, and will typically form the basis of the authorisation decision. Such an approach represents a major shift in the way in which application devel- opers view objects. Rather than merely acting as containers and dispensers of data and functionality, software objects may become actively responsible for the protection of those resources. By basing the design of SAAs on the SDO concept, the provision of application-specific user-centric access control is simplified by localising the ac- cess control mechanisms. Rather than distributing responsibility for enforcing access control throughout the application, only those objects that encapsulate protected re-
13RBAC is discussed in Section 2.5.1. 10 Chapter 1. Introduction sources are responsible for controlling access to those resources. Since in well written programs, objects provide the only means of accessing their encapsulated resources (from within the application), the security measures will be both consistently applied and cannot be bypassed.
1.4 The Origin of SDO Concept
The evolution of programming paradigms, beyond the current view of the object- oriented paradigm, such as the inclusion of the concept of SDOs, is required to help meet the needs of SAA developers. They must deliver SAAs, including those based on the Web services model, that must reliably provide controlled access to resources. In this section, a discussion of an observed trend in programming languages that has lead to an increase in the reliability of application programs, will be presented. It will then be argued that an analogous disciplined approach should be taken to the application of access control measures within SAAs. The SDO paradigm provides such a discipline. Object-oriented (OO) design is data-centric and relies on the identification of the data present in the system and associating functionality with that data. Classes and their individual instantiations, objects, are responsible for the encapsulation of that data and providing a set of operations appropriate to that data. Good programming practice dictates that the methods of the object provide the only mechanism by which that data may be accessed. The OO paradigm represents the latest stage in the evolution of approaches, that has taken place within third generation programming languages. Associated each stage in that evolution is associated with the provision of an increased level of ab- straction and degree of data encapsulation that are made available to software devel- opers. The typically identified milestones in this development were: (1) structured programming that collected code performing related functionality into self contained units (functions), and provided support for their use in the form of parameter passing and local variables; (2) the development of abstract data types (ADTs) whereby all of functions needed to operate on a programmer defined type were collected into a sep- arately compiled library module; and (3) the current object-oriented and component technologies. Each of these approaches also provided increased support for the maintenance of data integrity, in particular the integrity of complex data structures, primarily by 1.4. The Origin of SDO Concept 11 increasing the localization of code that has direct access to data. Within the OO paradigm, good programming practice dictates that such access is restricted to its encapsulating object. Each successive approach also simplified program testing and debugging. In the OO paradigm, if a data structure becomes corrupted, that corruption is necessarily caused by an error in the code of that object. Prior to the adoption of the OO approach (and its predecessor, the abstract data type approach), that flawed code could have been located anywhere in the application. Consequently, it can be argued that the adoption of the OO paradigm has resulted in a significant improvement in program reliability. There is however, a major deficiency with the OO paradigm when it is applied to the development of SAAs. When an object receives a message requesting an operation be performed, an attempt will always be made to satisfy that request. Whether that ac- tion should be permitted, is not considered14. Within the object-oriented paradigm, an object is unaware of the sensitivity of its encapsulated resources (whether they be data or functionality), so does not mediate any request to access these resources. Although such an approach is appropriate for the majority of programs, it is not necessarily appropriate for SAAs. By their very nature, SAAs take security considerations into account when performing their tasks. Most SAAs authenticate the user and thereafter mediate their access to sensitive information on the basis of that established identity and the application’s security pol- icy. Unfortunately, the code which enforces that control is currently not localized. Instead security checks are made from wherever in the code is deemed appropriate, i.e. from effectively anywhere within the application. Consequently the possibility of making an inappropriate security check, or not performing one at all, is unacceptably high. It is apparent that an approach similar to that used to preserve data integrity is re- quired. Responsibility should be localized within the software object that manages the protected resource. Such objects should actively defend their encapsulated resources from unauthorised access, and so are referred to as being self-defending objects.
14This statement is not strictly true. Java, for example provides security managers that restrict access to resources that the Java runtime considers to be security sensitive. Mechanisms are also provided that can be used to restrict access to programmer defined resources. The SDO approach provides a framework for utilising these mechanisms to enforce access control requirements of an SAA, in a coordinated manner. 12 Chapter 1. Introduction
1.5 Limitations of the SDO Concept
The SDO concept does not, in itself, provide any absolute security guarantees. It is primarily concerned with ensuring that an SAA will mediate all accesses to protected resources, and that all relevant access attempts are logged. Achieving a prescribed level of security is far more challenging and requires a multi-faceted approach. To provide absolute levels security the major requirements that must be satisfied are: the provision of a secure computing environment (based on the use of trusted hard- ware and operating system); a trusted execution environment in which application programs, including SDO-based SAAs, will reside; and finally an application that provides complete access control. Research into the provision of secure environments has been unfashionable for some time, in fact, little significant research has been conducted over the last twenty years. However, as eluded to earlier, in recent years interest in such research is being rekindled. Even in the current relatively insecure computing environments, the SDO concept has a significant role to play. By ensuring the access control measures of an SAA are systematically enforced, the rigorous application of the SDO concept will ensure that the access control requirements of the application are met. Further, by encapsulating protected resources within SDO rather than in a normal object, access control contin- ues to be enforced, even if the SDO is transferred between host computers. Protected information can potentially still be obtained by an attacker, if either a programming flaw exists in the SDO/ SAA code or mechanisms other than those provided by the application are employed, e.g. directly accessing the file or database in which that information is stored. Consequently, within this thesis, not only is the SDO concept and its implementa- tion discussed, but also how the SDO concept can be used in conjunction with other security mechanisms such as encryption, to provide true security guarantees.
1.6 Thesis Outline
The remainder of this thesis is divided into seven chapters. The next chapter, Chap- ter 2, provides a literature review that details selected research that relates to the SDO concept and its implementation. No research into the SDO concept, i.e. making ob- jects within object-oriented programs responsible for the enforcement of mandatory access control on their encapsulated resources, was identified. However, the provision 1.6. Thesis Outline 13 of computer security and access control in various situations has been well researched, and has been reviewed in that chapter. Chapter 3 continues the literature review. That chapter concentrates on the pro- vision of security within the Java language, its associated application programmers interface (API) and the Java Virtual Machine (JVM). The purpose of that chapter is two-fold. Firstly, as the prototypes that were developed to support this research are written in Java, it provides details of the Java features that will be exploited to im- plement the SDO concept. Secondly, and of equal importance, the chapter includes a review of the important elements of the Java security architecture. Since Java en- vironment arguably embodies the current state security knowledge, by presenting the width, depth and intricacies of the facilities provided, an appreciation of the current state of computer security is gained. It also serves as a way of demonstrating that the SDO concept is indeed a novel approach, and how it both harnesses and complements current security techniques. Chapter 4 discusses how the SDO concept can be implemented. The implemen- tation mechanisms are discussed in language independent terms, i.e. language de- pendent features have been avoided, making this chapter suitable for developers or re- searchers irrespective of the object-oriented language they wish to employ. Chapters 5 and 6, on the other hand, discuss the implementation of a non-distributed prototype and two versions of a distributed prototype, using the Java programming language. Those prototypes and the related discussion presented in these chapters act as a proof of concept, demonstrating that SDO concept is generally applicable and that the mech- anisms discussed in Chapter 4 were implementable. Two versions of the distributed prototype were developed to ensure that the applicability of the SDO concept was not dependent upon the peculiarities of a particular distributed computing model. Having provided a proof of concept, the distributed prototype was used to explore the strengths and weaknesses of the SDO concept. Results of those investigations are included in Chapter 6. Chapter 7 discusses the impacts which the adoption of the SDO concept is ex- pected to have on the SAA development processes and the requirements for an SDO Support Environment. The support environment provides an SDO specific API and those services that help to secure the environment in which SAAs execute. Chapter 8 concludes this thesis by discussing the outcomes of this research and suggest future research directions. 14 Chapter 1. Introduction Chapter 2
Literature Review
This is the first of two chapters that provides a review of the literature that relate to the Self Defending Object (SDO) concept. No previous work has been found that has attempted to fulfill the mandatory access control requirements of a security aware application (SAA), through the application of the SDO concept, i.e. the making of those objects that encapsulate protected data or functionality, responsible for enforcing access control on those resources. The next chapter, Chapter 3 forms part of the literature review but discusses only one topic, the security features of the Java as manifested as the Java language, the Java API and the Java Virtual Machine. The purpose of that chapter is: (1) to provide an introduction to those Java features that will be utilised in the development of the SAA prototypes, and (2) to provide an insight into the range of security features that have been incorporated into Java, a system for which security has been a major design consideration, to provide an appreciation that the SDO concept is a novel approach and that it complements existing security features. This chapter provides a introduction to nine broad topics that are relevant to the SDO concept, namely:
• the notion of objects and their realisation This section introduces the object oriented concept and related terminology that will be used throughout the remainder of this thesis.
• Web services Web services is a distributed programming model which is currently enjoying
15 16 Chapter 2. Literature Review
widespread adoption. This section introduces the major components of the Web services architecture, some of the terminology used and the security measures introduced to secure its messaging. One of the distributed prototypes utilises the Web services model.
• objects protecting encapsulated resources This section introduces three research areas in which objects have been made responsible for the protection of their information content. The SDO concept applies that idea to secure the protected resources of an SAA.
• the need for security The HIPAA legislation, that mandates the securing of medical information in the US, is introduced as an example of the move by governments to use legislation as a means of forcing the provision of adequate security for critical information systems. The SDO concept is aimed at addressing that need.
• related operating system concepts Operating systems underpin the provision of security in computer systems. This section introduces the security services provided by secure operating systems and their relevance to the implementation of the SDO concept.
• the provision of application level access control This section introduces research that has guided the implementation of access control within SDOs.
• trust establishment The work of the Trusted Computing Group targets the provision of a mecha- nism by which the trustworthiness of remote systems can be estimated. In a distributed SAA, a major requirement is the establishment of trust that the des- tination to which an SDO (and its protected content) is to be sent, is secure.
• mobile agents Mobile agents like SDOs are examples of mobile code and data. This section introduces research conducted on the securing of mobile agent systems, to help identify the security ramifications of introducing the SDO concept and how they might be mitigated.
• AspectJ AspectJ is an aspect oriented programming language that offers promise as a 2.1. The Notion of Objects and their Realisation 17
mechanism for implementing the SDO paradigm. This section introduces the language and its syntax.
2.1 The Notion of Objects and their Realisation
In this section, the terminology associated with the object-oriented (OO) programming paradigm will be briefly discussed. In many respects, this section forms an extended glossary of OO programming terms that are defined in relation to their usage in Java. Object-oriented languages date back to the definition of Smalltalk in the early 1980s [10], but only gained widespread adoption with the development of C++ [11]. OO languages are data-based, rather than code based, so OO design entails the iden- tification of the data entities involved in the process being computerised, associating functionality with those data entities, and finally defining the interactions between those entities. In Java, the units of functionality are referred to as methods. In other language paradigms, such named groupings of programming language statements may be referred to as functions, procedures or sub-routines. Like C and C++ functions, all Java methods have a type (i.e. a return type) and only support the passing of parame- ters by value.
2.1.1 Classes and Objects
A class is a named collection of related data members (data fields) and methods that operate on those fields. Classes are the fundamental structural elements of Java pro- grams with each class defining a new data type. All Java (code) statements must be located within a class and the class is the smallest unit of source code that can be separately compiled. At run-time, an ‘instance’ of a class is ‘instantiated’ (created), which involves allocation of memory for the ‘data members’ (fields) defined within the class and their initialisation. The entity formed is referred to as an ‘object’ (refer to Sections 3.3.1.1 and 3.3.1.2 for a detailed discussion of the loading of classes and the instantiation of objects). Thus, objects form the unit of encapsulation of data and functionality within OO programs. Program execution occurs as a consequence of the passing of messages between objects. At the programming level, the passing of messages between objects, translates to one object invoking a method of another object1. Objects/ classes define
1Syntactically, this is very similar to calling a function in a non OO programming language. How- ever it is semantically very different. Rather than passing the data to be manipulated to code, the data 18 Chapter 2. Literature Review the basic level of abstraction provided by an OO programming language. Reasoning about programs involves reasoning about the interaction between objects.
2.1.2 Encapsulation, Inheritance and Polymorphism
Central to the OO programming paradigm are the concepts of encapsulation, inheri- tance and polymorphism.
2.1.2.1 Encapsulation
Encapsulation is the hiding of data within the class. It is considered to be bad pro- gramming practice to allow direct access to the data members of a class. Instead, only indirect access should be provided via the methods of the class2. This approach is known as encapsulation “because it seals the data (and internal methods) safely in the “capsule” of the class, where it can be accessed only by trusted users (i.e. the methods of the class)” [12].
2.1.2.2 Inheritance
Inheritance is a way of creating a new class (type) by extending another class, i.e. a new class is formed by adding data and/or functionality to an existing class. All but one class in Java, Object, are created in this manner. The process is referred to as either the subclassing or extending a class. Inheritance can be viewed as being a is-a relationship between classes. As one class has inherited all of the attributes, i.e. data members and methods, of the other class, it ‘is’ also of that type. Consider the following section of inheritance chain: a utility is a car, and a car is a motor vehicle. This relationship is illustrated pictorally as:
motorvehicle ← car ← utility
In OO terms, car is said to extend (or inherit from) motor vehicle. It will then add the extra attributes common to all cars. Utility in turn extends car. In that example, a car is said to be a ‘subclass’ of motor vehicle, and motor vehicle is a ‘superclass’ of car. (object) operates on itself using the specified method. 2In Java, access to methods, classes and fields are controlled by access specifiers which appear in their declaration. Two commonly used access specifiers are: private - the entity can only be accessed by the methods of the class, and public which permits access from anywhere in the program. 2.1. The Notion of Objects and their Realisation 19
One might expect that it would be possible for one class to extend multiple classes, as something in real life typically belongs to more than one category, e.g. a utility is both a car and a three-dimensional object3. Such an inheritance model is referred to as ‘multiple inheritance’ and is supported by such OO languages as C++. Since a number of problems are associated with the implementation of multiple inheritance in programming languages, newer OO languages, such as Java and C#, only support ‘single inheritance’, i.e. a class can only inherit from a single superclass. This restric- tion does not prevent numerous classes from extending a single class, which provides the real power of inheritance. Returning to the car example, numerous classes, such as sedan and station wagon, can extend car. As already mentioned, when a class extends another class, it will inherit all of the methods of its superclass. Often, some of the behaviour exhibited by the super- class needs to be either replaced or customised within the subclass to meet its more specialised needs, i.e. one or more of the inherited methods may need to be ‘overrid- den’. Method overriding is achieved by declaring a method in the subclass that has an identical signature and return type to an inherited method, and provides a replacement implementation4 of the superclass method. Since an object of a subclass exhibits all of the functionality of its superclass types, an object of a subclass can be used anywhere that one of its superclasses is expected. In Java, the lack of support for multiple inheritance is overcome, to a certain extent, through the use of ‘interfaces’. A class can only extend a single superclass, but it can implement multiple interfaces. An interface is similar to a class in that it is a Java type, but rather than actually providing functionality, an interface only specifies the required API, i.e. it defines what functionality must be provided by a class in order to be of that type. Since an interface is a pure specification, interfaces cannot define instance variables5, and cannot be instantiated (however necessarily, classes that implement the interface can be instantiated).
3A utility is a three-dimensional object as it has the attributes such as a volume and surface area. 4Commonly the overriding method will need to invoke the inherited method that it is overriding. To invoke the overridden method, in Java, the keyword super is used in place of the method name to denote the overridden method. A very commonly overridden method is the toString method that provides a textual representation of the content of the object. Typically the overriding method will invoke the inherited method to generate the textual representation of the superclass, and then appends its contribution. 5It is possible to declare static constants in an interface. 20 Chapter 2. Literature Review
2.1.2.3 Polymorphism
Polymorphism in Java takes the form of dynamic binding, i.e. the resolving of which method to invoke when that method has been overridden by one of more classes in the inheritance hierarchy. The method invoked will depend on the type of the actual object, not on the type of the object reference that appears in the code. Dynamic binding provides tremendous flexibility. The inheritance relationships can be exploited by writing code in terms of a superclass, knowing that code will work appropriately when objects of any of its subclasses are used. To help clarify how polymorphism works, consider the motor vehicle example and assume that each car type overrides the drawBodyShape method that is declared in the class car. Thus, an object of each car type will draw its distinctive body shape. If the drawBodyShape method of a variable of type car is invoked, the utility object referenced by that variable, will draw a utility, even though the variable was declared in the code as being of type car, i.e. the drawBodyShape method declared in the class utility, not the one from car, is invoked.
2.2 Web Services
Web services are reshaping the Internet by supplementing the user-server interaction of the World Wide Web. Unlike HTML and other Web standards which allow a user (using a browser) to obtain information and services on the Internet, Web services is concerned with enabling application to application interaction. Web services is the latest architecture for enabling distributed computing. The major reasons for the widespread adoption of Web services are: the lure of profits to be made from electronic commerce; the ability to build integrated, cross-enterprise applications; and the ease of conducting business anytime anywhere. The standards based approach taken with the specification of the Web services architecture and its text based communications6, makes such integration possible. Al- ternatively, a Web service might provide far less complex functionality that can be used as a building block for application development. Web services is effectively an- other variation of the classic client-server model, though with the added advantages of platform independence and being a Standards based, rather than a propriety, architec-
6Text based communications, although quite inefficient, ensures platform independence, so is par- ticularly suited to distributed computing in heterogeneous corporate networks and enabling business to business system integration. 2.2. Web Services 21 ture. By combining Web services, it is anticipated that the development time for a new application will be significantly reduced, as the functionality provided by existing ser- vices is reused, rather than through new software development. Curpey [13], describes a Web service as being “a collection of functions that are packaged as a single en- tity and published to a network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide.” Thus, Web ser- vices is considered by many, to be the elusive mechanism for achieving code reuse, enabling applications to gain the majority their functionality from existing Web ser- vices either developed in-house or obtained from the Internet. At present, Web services are attracting enormous interest and are increasingly being used in production systems and enjoys support from the majority of platform vendors and tool developers, so the rate of its adoption is expected to increase dramat- ically. The availability of a Web service is advertised using a combination of WSDL (Web services Description Language) (Section 2.2.2) and UDDI (Universal Descrip- tion, Discovery and Integration) (Section 2.2.2). UDDI specifies the interfaces to Web services based depositories that allow service descriptions to be stored, located and the WSDL descriptions of the service API downloaded. From the WSDL description of a Web service, software tools are readily available to generate the code required to sup- port the invocation of the Web service and to obtain the result from that invocation. Those remote procedure call semantics are achieved by exchanging SOAP (Simple Object Access Protocol) (see Section 2.2.3) messages between the client and the Web services server. In an environment in which the programming interface to a Web service is pub- lished on the Internet, and that service can be invoked using automatically generated code, needless to say, there are very considerable security implications. Standards, such as WS-Security (see Section 2.2.4), have been developed to address the initial lack of security associated with Web services. WS-Security, and related standards, target the need for the secure exchange of messages between the service client and the Web service, using a combination of application level cryptography, and the transfer of security tokens and assertions. The SDO paradigm, on the other hand, addresses a different aspect of the need to secure the Web service based application, the securing the information while it is 22 Chapter 2. Literature Review within the communicating entities, rather than the securing of the communications. The use of SDO concept will ensure that access to protected information will at all times, be subject to the access control policy and audit requirements of the application. Thus, the SDO approach complements the measures currently being used to secure Web services. In the remainder of this section on Web services, several of the following major elements of the Web services architecture, will be discussed to provide an overview of Web services architecture and the security measures currently available to secure them7:
• Extensible markup language (XML)
• Universal Description, Discovery and Integration (UDDI) and Web Services Description Language (WSDL)
• Simple Object Access Protocol (SOAP)
• WS-Security
The separate issue of determining whether the message should be allowed to reach the Web service after it is received at the destination machine, is considered in Sec- tion 2.6.1.1 where XACML and the application of policy based access control are described.
2.2.1 Extensible Markup Language (XML)
Web services rely on the exchange of messages expressed in XML. XML is a text- based, general purpose, markup language which not only enables the transmission of information but also the structural description of that data. The structure of the data is defined through the use of tags and attributes, which being user-definable, allow any data type to be described. Further, as the tags can be nested to an arbitrarily depth, there are no restriction placed on the complexity of the data being described. Provided the meaning of the tags are known by the communicating parties, the meaning of the data being communicated is also known. Thus, XML provides a means by which the semantics of arbitrarily complex data may be transferred between applications running on different platforms.
7“An overview of Web services security” [14] provides a far more detailed review of the security requirements for Web services and a brief introduction to other standards not discussed in the thesis. 2.2. Web Services 23
The verbosity of the text-based encoding is however, a significant drawback. As well as the large bandwidth required to transmit the data, considerable computational costs are incurred during encoding and decoding of the XML message. Consequently, proprietary binary XML formats have been proposed. There is significant debate re- lating to the benefits of binary XML. Currently, there is no standards-based binary XML format, and adoption of binary XML is still low.
2.2.2 Universal Description, Discovery and Integration (UDDI) and Web Services Description Language (WSDL)
“At the heart of the Web services architecture is the need for program-to-program communications. And in order for that communication to take place, the Web service itself needs to be described in detail so that other programs can understand what it is and how to connect to it.” [15] UDDI [16] specifies a directory for advertising avail- able Web services, i.e. it is a searchable collection of descriptions of Web services. As might be expected, the UDDI directory is itself a Web service which (1) enables service providers to dynamically register services that they provide together with de- tails about themselves, (2) enables service requesters to search for Web services which provide the services that they require, and (3) supports download the API for the cho- sen Web service. The information relating to both the Web service and information relating to their provider, are usually written in WSDL. WSDL [17] is the XML based language, whose main function is to describe Web services8. A service description defines where a Web service is located, the methods available from the service, and how to call each of the methods. Gralla [18] describes the important elements within a WSDL document and their function as:
•
• service This details the location of the Web service.
Although it is possible to obtain service descriptions from a UDDI or other direc- tory service, it is unlikely that such a method will be used to locate services for an SAA. Rather, the WSDL description of the service is more likely to be obtained from within the organisation itself, or if outsourced, the description is likely to be obtained directly from the service provider after receiving evidence of the trustworthiness of the service. As noted earlier, the WSDL description is used by software tools to au- tomatically generate the code that binds with the Web service and then controls the exchange of SOAP messages.
2.2.3 Simple Object Access Protocol (SOAP)
SOAP is currently the technology most often used to support Web services. It is a standards-based protocol for invoking Web services through the exchange of XML messages, i.e. enabling remote procedure call semantics over the Internet. An alterna- tive view of the SOAP framework was expressed by Roy [19] as: “The SOAP speci- fication defines an envelope for transmitting messages, offers guidelines for encoding data, and provides rules for representing remote-procedure calls”. The protocol is based on the transmission of messages, normally using the HTTP protocol. A Web service is invoked by sending a “service request”, a SOAP formatted mes- sage, to the Web service9. The Web service responds by sending a service response, which might return the result of the request or report an error. A SOAP message is an XML message that consists of three kinds of elements:
9The URL of the Web service, and the message format required for identifying the method being invoked and the parameters required, are obtained from the WSDL description of the service (see Section 2.2.2). 2.2. Web Services 25 to hold security tokens10, timestamps, digital signatures (see Section 2.2.4.1), and the description of any encryption used (see Section 2.2.4.2). The body element carries the message payload. Typically the body element con- tains the information needed for a method invocation (i.e. the identity of the method being invoked and details of the parameters being passed), or the result of the service invocation. Alternatively, a service response might contain a “Fault” element that is used to report errors11. SOAP messages are seldom created by hand. Instead, they are constructed using one of the many Web services toolkits which are available, e.g. tools provided by the Java Development Kit and the Java Web Services Developer Pack allow a Java language method invocation on a web server to appear the same as a local method invocation.
2.2.4 WS-Security
The SOAP standard completely ignores security issues. It is concerned with enabling Web services. Transport level protocols, in particular the almost assumed HTTP trans- port protocol, is relied upon to provide the necessary level of security [20]. It is true that secure transport protocols, such as Secure Sockets Layer (SSL), can be relied upon to secure messages transmitted directly between a Web services requester and provider, i.e. the transport layer ensures the integrity and confidentiality of the mes- sages. “However, existing transport-level security is a solution limited only to point to point messaging. If intermediaries are present when using a secure transport, the initial sender and the ultimate receiver must trust those intermediaries . . . (also) other risks such as local storage of messages and the potential for an intermediary to be compromised must be considered.” [21] IBM et al. [22] expressed the widely held view that Web services, as originally proposed, were known to be insecure and that the lack of security was hampering its adoption: “our customers, industry analysts, and the press identify a key area that needs to be addressed as Web services become more mainstream: security.” To ad- dress this problem, the WS-Security specification was released12. IBM et al. [22, 24] claimed that the WS-Security extensions to SOAP would enable the exchange of en- crypted and/or signed SOAP messages. The aim of WS-Security, is to specify how
10Security tokens whose transmission formats are defined within the SOAP standard are username password pairs, Kerberos tickets and X.509 certificates. 11The ‘Fault’ element is the only defined SOAP payload. 12WS-Security is now an OASIS standard [23]. 26 Chapter 2. Literature Review
digital signatures, encrypted content and security tokens can be included within SOAP messages. As standards already existed for achieving such cryptographic functional- ity, WS-Security defined how these standards could be used to provide application level security that was required to secure the content of SOAP messages. In summary, “WS-Security allows for a SOAP message to identify the caller, sign the message, and encrypt message contents. Whenever possible, existing specifica- tions are reused to reduce the amount of invention required to securely deliver a SOAP message. Because all of the information is delivered within the message itself, the message becomes transport neutral.” [25] Two standards which are crucial to the WS-Security specification are XML Sig- nature and XML Encryption. These standards, and how they are used to secure Web services, will now be discussed.
2.2.4.1 XML Signature
XML Signature specifies how digital signatures can be applied at the application level. Being applied at the application layer, rather than the transport layer, the signature provides endpoint to endpoint integrity guarantees. Like any digital signature, the presence of the signature does not guarantee the integrity of the message, but does however (1) make evident any changes that have been made to the signed information, and (2) verify the identity of the signer. An important aspect of XML Signature is that it allows part, or parts, of a message to be signed and for content to be signed multiple times (by different parties). Such an approach enables the signing of only those parts of the message for which integrity is important, while allowing intermediaries to add or modify other parts (and potentially sign those parts of the message). The standard necessarily specifies how the following information is to be included within the signed SOAP message: (1) the extent of the content that has been signed, (2) the encryption algorithm used to generate the hash value, and (3) the signature13. The signature information is included within the header of the SOAP message, with the message payload remaining unmodified. Such an approach enables an intermediary to perform the necessary integrity checking before forwarding the service request to the Web service where the requested service will be performed.
13Since the signature is being included within an XML message, the signature is text rather than binary format. 2.2. Web Services 27
2.2.4.2 XML Encryption
Without encryption, the entire content of a Web service request is in plain text. Such a situation would prevent the use of the Web services model, within those application domains in which confidential information is transferred. For example, the use of Web services within the Health sector would be prevented, or severely restricted, due to both the moral and legislative requirement to keep health information private (refer to Section 2.4). XML Encryption solves the problem by providing a standards-based mechanism for encrypting the payload of a Web services request and/or response. It is possible to encrypt portions of the message payload. Thus, the body element identifies what data has been encrypted, the encryption algorithm used and some indication of the key used.
2.2.5 Web services are still insecure
Web services are still a relatively new technology. Tool builders, developers and standards organisations were initially concerned with getting the technology to work. When the lack of security within Web services became evident, steps were taken to secure Web services. As previously outlined, the enhancements to SOAP attempt to secure the communications channel (including the passing of user credentials) be- tween the requester of a Web service and its provider. Unfortunately these measures, although vital, still do not address the need for establishing trust that a Web service will function correctly, and thus protect critical business information. Consider a Web service that exposes a critical portion of a corporate critical in- formation system to business partners. Often information system was developed for in-house use, and so was not security hardened, and is unlikely to withstand expo- sure on the hostile Internet. The WSDL description of the Web service provides those business partners with all the information that they require to interact with the infor- mation system. A hacker armed with the same service description will also have the information they require to launch an extensive probe for any weaknesses in the Web service. Consequently, a programming error which results in a vulnerability in the Web service is a significantly greater problem than a similar vulnerability in another distributed application. A similar view was expressed by Kearney et al. [14]: “The In- ternet is already a dangerous place, and the very attributes of Web services that make them attractive also necessary introduce new potential vulnerabilities. By making ac- 28 Chapter 2. Literature Review cess easier for legitimate users and systems from outside the enterprise boundary, new possibilities for malicious and felonious entities to exploit are also brought about.” The SDO paradigm is targeted at facilitating the development of more trustworthy, security aware, Web services.
2.3 Objects Protecting Encapsulated Resources
The SDO approach aims to enhance the security provided by SAAs by making the object that encapsulates a security sensitive resource responsible for controlling access to that resource. In this section, three research areas (DRM, Self-Securing Devices and Self-Protecting Objects) in which a similar approach has been successfully employed to secure resources, will be discussed. In each case, the aim of the mechanism is to use the encapsulating container of the protected resource to mediate access to that resource in accordance with a defined security or access control policy.
2.3.1 Digital Rights Management
The aim of digital rights management systems is to protect digital material such as audio, video or text, from unauthorized use, most often, the unauthorized copying of such material. Although numerous mechanisms have been developed to provide such protection, only two mechanisms that mirror the self-defending object approach will be discussed here.
2.3.1.1 DigiBox
The first approach, that taken by InterTrust, is to encapsulate and cryptographically protect material along with access control requirements within a so called ‘Digi- Box’ [26]. In that model, the protected material may be freely distributed in the form of the DigiBox container, however the access to that information is prevented by encryption. That encapsulation technology is also integrated into a content readers, such as the Adobe Acrobat Reader, that enables the encrypted content to be unlocked. However that content is only made available to the user in those ways specified in the associated protection policy [27]. This mechanism is commonly used for document distribution, e.g. reports and academic papers, where the primary goal is to protect the content from modification, while allowing the document to be displayed and printed. 2.3. Objects Protecting Encapsulated Resources 29
2.3.1.2 Cryptolopes
Cryptolopes are offered by IBM as a mechanism for secure document distribution. In their architecture, a distributor acts as an intermediary between the copyright owner and customers. Once again the protected data may be freely distributed, via the distrib- utor or otherwise, and cryptography is used both to protect the main document from unauthorized access and to produce a cryptographic checksum. This mechanism, ac- cording to Kohl [28] enables, “all of the intents of the publisher (protection, marking, etc.), and all the terms and conditions he is offering, ”tobe“expressed in a tamper- evident digitally signed package.” The rights information is not encrypted, ensuring that the user clearly knows what rights to the document, they have been acquired. The integrity of the rights information is made evident through the use of a digital signa- ture. As one would expect, the software that provides access to the protected content of the cryptolope, also controls the use of its protected content.
2.3.1.3 Relevance to SDOs
In both of these cases, the access control information is permanently associated with the protected content. In the same way, an SDO encapsulates its protected content and performs access control. The SDO approach is different in that it is often not feasible to encrypt the protected content due to the number of accesses performed. The approaches are similar, in that the SDO provides the only mechanism to access the protected resource from within the program, and since the access will only be permitted if sufficient privileges are possessed by the requesting entity, the information is protected from unauthorised access.
2.3.2 Self-Securing Devices
‘Self-securing devices’ approach used to secure computer systems by having individ- ual hardware devices take responsibility for their own protection [29]. The argument developed to support their proposal involves drawing an analogy between the evolu- tion in defence strategies in ancient times, and the defence strategies currently being used to secure computer systems. Ganger and Nagle observed that current network security relies heavily on the establishment of a secure perimeter by using firewalls and the security features of COTS (commercial off the shelf) operating systems. They assert that such an approach is inherently flawed as once these border pro- tection measures are breached, an intruder effectively has free access. This deficiency 30 Chapter 2. Literature Review was described as “conventional security architectures are brittle by design, because a small number of border protections (e.g. firewalls and/or host OSs) are used to protect a large number of resources and services. For example, an attacker who compro- mises a machine’s OS gains control over all resources of that machine” [29]. They continued by arguing that such an approach parallels the mechanisms taken to secure towns in Roman times. Then defence relied on the provision of a wall to secure the perimeter. Once breached, invaders effectively gain access to everything inside that perimeter. Over time, defence strategies evolved in response to more sophisticated attacks. By medieval times, multi-tiered defence structures were employed. The authors ar- gued that a similar change is needed to secure today’s computer systems. In accor- dance with the principle of ‘defence in depth’, the current perimeter approach to se- curity should be supplemented by the provision of multiple internal, and individually defended, boundaries. “This “self-securing devices” architecture distributes security functionality amongst physically distinct components, avoiding much of the fragility and unmanageability inherent in today’s border-based security” [29]. Individual net- work devices, including storage devices, network cards, routers and switches, are re- sponsible for their own protection. Thus the secure perimeter protection provided by firewalls, is supplemented by separate security perimeters around individual network devices. These enhanced devices, which they refer to as ‘self-securing devices’, not “only protect their own resources, they can observe, log, and react to the actions of other nearby devices. Compromises of one security perimeter will compromise only a small fraction of the network environment” [30]. In related papers, Strunk et al. [31] provides a description of how a self-securing device, namely a storage server, was implemented.
2.3.2.1 Relevance to SDOs
Making hardware devices responsible for their own security is both a novel and ef- fective way of increasing network security. Due to the similarity of the concepts of self-securing devices and SDOs, the argument presented to support the adoption of the self-securing device approach, applies equally well to the SDO approach to se- curing SAAs. A programming error that allows an unauthorised user to gain access to a system resource in one part of the SAA, is prevented from exploiting that access by the protection mechanisms provided by SDOs which provide a secondary line of 2.3. Objects Protecting Encapsulated Resources 31 defence14. Thus the SDO and the self-securing device approach logically mirror each other, though in a completely different context. The effectiveness of the strategy of providing localized protection within self-securing devices in order to enhance the security of the computer network, supported the initial belief that the SDO concept would prove to be a valuable extension to the object-oriented programming paradigm.
2.3.3 Self Protecting Objects in Object-oriented Databases
An SDO-like concept has been employed in the context of federated object-oriented databases where the database objects are referred to as being ‘self protecting objects’. A federated database is described by Olivier [32] as being “a distributed database that allows the various sites to implement different security policies. The policy of a site is then enforced by all sites for data owned by this site.” In a series of papers, Olivier [32, 33] describe the mechanism by which the use of self protecting objects ensures that all policies relating to a particular object continue to be enforced even after the object has been migrated within the distributed database. The security architecture relies on the presence of a Trusted Common Core (TCC) within all member databases. The TCC is responsible for providing basic protection measures including assurance that any of the specific protection measures associated with a particular object are enforced. An optional Trusted Extension (TE) may be present at a site to provide additional site specific protection for its objects. If an object is migrated, a copy of the TE migrates with that object. The TCC ensures that the TE associated with the object will always be executed, so access to the information within the migrated object will always be in accordance with the security requirements of the site from which it originated. Olivier et al. [34] also introduced the concept of baggage: “baggage is collected from all the components involved in any request; this baggage may be verified by the object against its personal security profile before any method is executed”. This mech- anism enables the evaluation of requirements such as ‘method X’ can be invoked only in response to a message if that message was transmitted over secure channels. The baggage associated with the message, includes amongst other accumulated informa- tion, the necessary transmission channel details.
14Each SDO protects its encapsulated resources by requiring authorisation before it provides access to one of its protected resource. Thus the SDO provides a secondary line of defence, following the inappropriate release of a security sensitive object (that SDO) by the ‘information server’ (which is also an SDO). Thus breaching one defence mechanism does not guarantee success in accessing a protected resources. 32 Chapter 2. Literature Review
2.3.3.1 The Significance to SDOs
In a distributed environment, both self-protecting objects and SDOs target the require- ment that the security policy relating to data specified which is specified at its source, will continue to be enforced irrespective of the location of that data. Although they tar- get the same security outcome, their realm of application and the mechanisms that they employ, are completely different. Self-protecting objects are confined to federated object-oriented databases where they are concerned with the enforcement of manda- tory access control. The SDO concept, on the other hand, targets the enforcement of mandatory access control in distributed object-oriented programs, i.e. SDOs are used in the context of software development, specifically the development of SAAs. Despite these differences, the successful implementation of the self-protecting ob- ject concept, supported the belief that the analogous the SDO approach would also be feasible. The separate idea of having messages accumulate security relevant ‘baggage’ as they are transferred between nodes, should also be applicable in the context of SAAs. There too, that baggage should assist in the evaluation of the trust-worthiness of indi- vidual messages. Unfortunately lack of time prevented this aspect of trust establish- ment within distributed SAAs to be investigated.
2.4 The Need for Security — HIPAA
Increasingly computers are being connected to the Internet, driven primarily by ei- ther the need to exchange information or the promise of profits to be made through e-commerce. However, exposure to the Internet greatly increases their risk of compro- mise. The commercial operating systems that are currently being used to secure such systems, are known to be incapable of providing the services required to provide ade- quate security [35]. In response, legislators are beginning to take action to ensure that national assets are adequately secured, through the passing of legislation mandating the provision of adequate protection. A prime example of this trend is the HIPAA legislation that applies in the health care sector. In this section, the requirements of the HIPAA will be introduced, to provide an indication of the profound shift in emphasis that software developers must place on the provision of security, if they are to meet their responsibilities demanded by this, and similar, legislation. In the United States, the Health Insurance Portability and Accountability Act of 2.4. The Need for Security — HIPAA 33
1996 (HIPAA) introduced regulations relating to the provision of data security and privacy within the health care sector. Such legislation moves the provision of secu- rity within a health care application from a highly desirable feature, to a requirement of paramount importance. Specifically, HIPAA mandates the protection of the confi- dentiality, integrity and availability of ‘protected health information’ (PHI) from both external and internal security threats and vulnerabilities. PHI is defined as being “all ‘individually identifiable health information’ held or transmitted by a covered entity or its business associates, in any form or media, whether electronic, paper or oral.” [36]. The protection afforded the PHI must be complete and must include the provi- sion of: (1) administrative safeguards — implement policies and procedures to ensure prevention, detection, containment and correction of security violations, (2) physical safeguards — limit physical access to electronic information systems and the facili- ties in which they are housed, and (3) technical safeguards — maintain information systems which only allow access to protected health information to those persons and programs that have been granted access rights [36]. The enormity of the problem which such legislation presents to the health sector and its computing resource suppli- ers, is reflected in the significant delay in implementation of the Act. The regulations only came into effect in April 2005. As can be seen from this brief description, the ramifications of the HIPAA and other legislation, is changing the way in which SAAs are designed and has highlighted the need for trusted operating systems. The need to meet such legislative requirements will almost certainly rekindle research into trusted operating systems, in particular their application to non-military application domains.
2.4.1 eHealth and SDOs
It is anticipated that the SDO approach will be applied to development of SAAs, in- cluding those relating to health care to assist that sector to meet the HIPAA require- ments. As already identified, the SDO concept is being proposed to help address the need for new and improved design techniques that can be applied to the development of SAAs. For these applications to provide the security guarantees demanded by the HIPAA legistlation, their security mechanisms must be underpinned by a trusted op- erating system. Trusted operating systems and the services they provide, are reviewed in Section 2.5.3. 34 Chapter 2. Literature Review
2.5 Related Operating System Concepts
SAAs are generally believed to be capable of providing complete fine grained access control. Certainly, it is possible to ensure that the access control requirements cannot be bypassed from within the application, but such mechanisms alone, cannot prevent access to the sensitive resources via other means other than through the application. Application level access control mechanisms cannot prevent the unauthorised access to the files and/or databases which hold: the information being protected, the SAA’s configuration files, or the authentication and authorisation information on which the SAA’s protection mechanisms rely15. The need for a secure environment was identified by Loscocco et al. [35], and expressed as: “Current security efforts suffer from the flawed assumption that ade- quate security can be provided in applications with the existing security mechanisms of mainstream operating systems”. The authors continued by arguing that such an ap- proach “can only result in a ‘fortress built upon sand’ ”. Thus, SAAs, including those which employ the SDO concept, provide only a false sense of security unless the un- derlying operating system and hardware are secure. To provide complete protection, the SAA must reside in a trusted operating system environment, such as that provided by Trusted Solaris16. The trusted operating system is relied upon to provide such critical services as mandatory access control, the maintenance of a secure audit trail and complete process isolation (including the cleansing of memory and disk space after use by a process). The fine grained mandatory access control on the resources managed by the applica- tion is complemented by and reliant upon, these services provided by its operating environment. The following sections provide a review of the fundamentals of trusted operat- ing system security. Naturally these principles apply equally to the development of trustworthy application programs.
2.5.1 Mandatory and Role Based Access Control
In terms of access control, an SDO conceptually provides the same protection to its en- capsulated data and functionality as a secure operating system applies to its protected resources. Access control, the controlling of the access of subjects (users) to objects
15An application potentially could ensure the confidentiality of such persistent data and be able to detect the modification of that data using cryptographic techniques. 16Trusted Solaris is a product of Sun Microsystems Inc. 2.5. Related Operating System Concepts 35
(resources), is divided into two broad categories: discretionary and mandatory. When discretionary access control is employed, as in a typical UNIX system, the control of access to the resources owned by a user is left to the discretion of that user [37]. How- ever in a commercial, and more so in a military setting, the generator of information is not the owner of that information, the information belongs to the organisation. Hence organizational policies must dictate access to the resource. Mandatory access control (MAC) has been studied for many years, normally in the context of trusted operating systems, where it has been successfully applied to the protection of sensitive system resources including files, sockets and processes. Mechanisms based on the use of access control lists or capabilities have ensured that such resources are only accessed in accordance with the system’s security policy [37]. As described by Loscocco et al. [38], the function of a mandatory access control (MAC) system is to “enforce an administratively set policy over all subjects and ob- jects in a system, basing decisions on labels containing a variety of security-relevant information”. MAC mechanisms ensure that security depends on the security require- ments of the data, rather than the discretion of users. A major problem with classic MAC approach is the cost and complexity of administering such systems, e.g. when a new user is to be given access to the system, all the numerous privileges needed by that user to perform their duties, must be incorporated into the security policy. To overcome this problem with MAC administration, Ferraiolo [39] proposed a different MAC model, one based on the roles which users hold within the organization. In a role based access control (RBAC) system, rather than directly associating users with the ability to access resources, users are associated with roles, and roles are associated with access to resources. When using RBAC, a new user gains all of the rights and permissions needed to operate within the system by simply being associated with one or more roles. According to the proposed NIST RBAC standard [40], a RBAC system may also support the following features:
• role hierarchies: one role inherits permissions and members from another.
• static separation of duty: membership of one role prevents membership of an- other related role, e.g. in the financial domain, a user cannot act in the role of financial adviser and internal auditor.
• dynamic separation of duty: current membership to one role prevents the simul- taneous membership of another related role, e.g. a user cannot simultaneously 36 Chapter 2. Literature Review
act in the role of bank teller and account holder.
N.B. The banking sector examples are those used by Barkley [41].
The advantages of the RBAC model over normal MAC was identified by Wakid [42] as “Role Based Access Control (RBAC) is an access control mechanism that can lower the cost of access management. RBAC is able to specify and enforce enterprise- specific security policies in a way that maps naturally to an organization’s structure”. In recent years, little emphasis has been placed on the provision of MAC, nor trusted operating systems in general. Contrary to this trend, the National Security Agency (NSA) has been conducting research into the feasibility of adding RBAC functionality to an existing operating system. They developed and provide a patch to the Linux kernel, which transforms standard Linux system into ‘Security Enhanced Linux’ (SE Linux) [9,38,43–45]. SE Linux however, still lacks the other functionality expected of a trusted operating system. Currently, the only commercially available trusted operating system is Sun Mi- crosystem’s ‘Trusted Solaris’ which includes support for the RBAC model. The char- acteristics of trusted operating systems are discussed in Section 2.5.3. Due to the increased need for security in distributed systems, much of the recent research into RBAC has concentrated on distributed systems [46–49] or for the World Wide Web [50–52]. Research papers that were considered to be particularly relevant to the implementation of the SDO concept, are discussed in Section 2.6.2.
2.5.1.1 RBAC and SDOs
An enforcement to mandatory access control, in particular the RBAC model, has been identified as the core responsibility that is peculiar to SDOs. Considering the advan- tages of the RBAC model, all of the prototypes developed in association with this research, implement the RBAC model.
2.5.2 Information Security Models
Trusted operating systems are required on multiuser computers that must maintain the secrecy or integrity of stored information. Typically, the users of the system will have different trust levels and information stored on the system will also have different levels of secrecy or integrity requirements. The provision of MAC forms the cor- nerstone of a trusted operating system’s controlled sharing of resources. To address 2.5. Related Operating System Concepts 37 a primary concern of MAC, how information can be secured, security models have been developed. Those security models that have been most influential in defining the philosophy behind MAC, and underpin its application, will be briefly introduced in this section. Each model permits the reasoning about a different aspect of the securing of information.
2.5.2.1 Military Model
The most significant of the data models is the military model. In the military model, information is ranked according to its sensitivity, rank, and divided into compartments according to its subject matter. Users are given clearances, that enable them to access information of a given sensitivity and within a set of compartments. The combination of rank and set of compartments which pertain to an object, is referred to as its class or classification [37]. Inherent within the military model is the ‘need to know rule’17 which states that a user should only be granted access to the minimum amount of information that they require to do their work. In the military model, “A subject can access an object only if (a) the clearance level of the subject is at least as high as that of the information, and (b) the subject has a need to know about all compartments for which the information is classified” [37]. Two most significant models that deal with the controlled use or flow of informa- tion within such systems, are the Bell-LaPadula and Biba models.
2.5.2.2 Bell-LaPadula Model
The Bell-LaPadula model [53] is concerned with the maintenance of security, i.e. the identification for information flows that would lead to an inappropriate disclosure of information. The basis of the model are two properties which are characteristic of secure information flows. They were described by Pfleeger [37] as being:
• Simple Security Property. A subject s may have read access to object o only if C(o) ≤ C(s)18 In the military model, this property says that the security class of someone receiving a piece of information must be at least as high as the class of the information. 17The ‘need to know’ rule is effectively just a restatement of the ‘principle of least privilege’. 18In the security properties presented above, C(o) relates to the security class of the object, i.e. C( ) represents the security class of the associated identifier. 38 Chapter 2. Literature Review
• *-Property. A subject s who has read access to an object o may have write access to an object p only if C(o) ≤ C(p).
The *-property says that a subject who has read access to information of a higher security class cannot write to an object of a lower security class. However, the highly restrictive nature of this property means that to make it useful in practice, that property is normally relaxed, requiring only that a subject be prevented from writing high level data to a lower level object. Thus, the Bell-LaPadula model permits reasoning about the preservation of the secrecy of information however it ignores the orthogonal need to maintain information integrity.
2.5.2.3 Biba Model
The second of the very influential information flow models is the Biba model [54], that relates to the maintenance of the integrity of information but ignores the need to maintain its secrecy. That model is used to identify information flows which could lead to a loss of integrity. The model also has two properties, which are effectively the dual of the properties of the Bell-LaPadula model: (1) a subject cannot modify an object having a higher integrity level, and (2) an object cannot be used by a subject to generate another object of higher integrity.
2.5.2.4 Clark-Wilson Model
The Clark-Wilson model [55] deals with a different aspect of maintenance of data in- tegrity. According to their model, (1) subjects are only able to access objects through specified programs, and (2) there is a requirement for a ‘separation of duty’ which ensures that authorized subjects are unable to make inappropriate changes to informa- tion. The Bell-LaPadula, Biba and Clark-Wilson models, together define the basis of trust in computer systems.
2.5.3 Trusted Operating Systems
A secure operating system is significantly different in design to commercial off the shelf operating systems, reflecting the foremost requirement for the maintenance of the security of information, rather than providing ease of use or efficiency. A trusted operating system, is a secure operating system in which there has been sufficient evi- 2.5. Related Operating System Concepts 39 dence provided by its developer, to establish a level of trust that the operating system really is secure. Thus, there are three imperative characteristics which an operating system must exhibit to be considered to be a ‘trusted operating system’: (1) the provision of those services required to allow users to harness the hardware resources and provide some level of user isolation, i.e. the normal operating system services, (2) the provision of those additional services which are required to ensure that resources, both hardware and information, are only made available to authorised users19, and (3) the provision of adequate ‘proof’ that the security mechanisms are complete and have been correctly implemented. The provision of basic operating systems is not considered in this docu- ment, the services needed to secure the system will be discussed in this section, while the establishment of trust in the implementation of those services will be discussed in sections 2.5.4 and 2.5.5. Security pervades the design of a secure operating system. Such systems are based on the following design principles that were identified by Saltzer [56].
• least privilege — users and processes are granted the minimum privileges that are required to perform their function
• economy of mechanism — the security mechanism should be small and simple
• open design — the design should be public, i.e. its security properties should not depend on the secrecy of the design
• complete mediation
• permission based — access should be disallowed unless a permission is explic- itly granted
• separation of privilege — ideally access to resources should depend on multiple conditions being met
• least common mechanism — physical or logical separation should be used to prevent unwanted information flows
• ease of use — easy to use mechanisms should be used to avoid them being bypassed by users
19The access control requirements of the system are specified using a security policy. Security poli- cies are discussed in Section 2.6. 40 Chapter 2. Literature Review
Implementing such principles results in a design in which the lowest level func- tionality is concentrated in the operating system kernel. A section of that kernel, the security kernel is then segregated from the remainder of the kernel and is solely and only responsible for implementing the security mechanisms. It “monitors all operat- ing system hardware accesses and performs all protection functions.” [37] By limiting its functionality, the security kernel can be made both efficient and small enough to potentially allow its correctness to be formally proved. The necessary reduction in size can be achieved through the concept of trusted software whereby all non-critical security related functionality is removed from the kernel. Such software is used to provide data and security related functionality to the security kernel, e.g. enabling direct communication with the user via a ‘secure communications path’ during user authentication. At least four execution domains are required within a secure computer system; the hardware, security kernel, operating system and user domains. The security kernel, with hardware support, is primarily responsible for the maintenance of the isolation and integrity of these domains. The operating system domain is subdivided into sub- layers, with the inner layers providing services for the less-trusted outer layers. The operating system thus attains an onion like structure, with calls between these layers being restricted to well defined interfaces. Access to these inter-layer interfaces is typically restricted to nearby layers. As an extreme example, user code is unable to directly call kernel functions. Any software system, including a secure operating system, is prone to errors. A procurer of such systems requires some level of assurance that the operating system, that is claimed to be secure, has been appropriately designed and implemented, and so provides the claimed level of security. The means by which that trust is established is discussed next.
2.5.4 Trusted Computer System Evaluation Criteria
At about the time that the first time-sharing computer systems were being developed and used for military purposes, a major attempt to quantify the security measures needed to secure such systems was undertaken by the U.S. Department of Defence. The developed set of standards, the Trusted Computer System Evaluation Criteria (TCSEC), provided criteria for evaluating not only the functionality provided by the operating system to secure a computer system, but also evaluated the level of assurance that the functionality has been correctly implemented [57]. Consequently the rating 2.5. Related Operating System Concepts 41 obtained for a system, related directly to the strength of the system to withstand an attack. A key functional requirement of a secure operating system identified in that Standard was the provision of mandatory access control (MAC). The TCSEC effectively provided an implementation model for the construction of secure computer systems through the identification of the six fundamental require- ments [57]:
• SECURITY POLICY — There must be an explicit and well defined security pol- icy enforced by the system
• MARKING — Access control labels must be associated with objects.
• IDENTIFICATION — Individual subjects must be identified.
• ACCOUNTABILITY — Audit information must be selectively kept and protected
• ASSURANCE — The computer system must contain hardware/software mecha- nisms that can be independently evaluated
• CONTINUOUS PROTECTION — The trusted mechanisms that enforce these basic requirements must be continuously protected
A major criticism of TCSEC was that it bundled functional and assurance require- ments. Also, as the criteria were developed to evaluate the level of security provided by computing systems that were essentially intended for governmental use, it was of little surprise that security models that were more applicable to commercial use, were not supported. TCSEC, together with several other nation-based standards that emerged later, were superseded by an international standard, the Common Criteria for Information Technology Security Evaluation.
2.5.5 Common Criteria
The Common Criteria for Information Technology Security Evaluation, CC 2.1, pro- vides the current standard for the evaluation of the security related functionality of computer systems. The Common Criteria (CC) is described as being the “outcome of a series of efforts to develop criteria for evaluation of IT security that are broadly useful within the international community” [58]. To establish trust in a security product or system, not only should a product or ap- plication provide security related functionality, but evidence should also be available 42 Chapter 2. Literature Review to users that the product can be trusted to correctly perform that functionality. The CC enables a trusted third party to evaluate a security product and certify its trustworthi- ness. Thus, the purchaser of a security product can have confidence that a procured product will meet specified security requirements. The CC framework permits consumers to specify a set of security requirements, that will form the basis of a product evaluation20. These requirements, referred to as a ‘protection profile’ (PP), are described as being “an implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs” [59] (TOEs are described in the following paragraphs.). The CC also enables a product manufacturer or developer to prepare ‘security tar- gets’ (STs), that specify security claims made about a specific product. Both an ST and a PP include assurance requirements, i.e. a level of confidence that the product will perform as specified. This confidence is specified in terms of ‘Evaluation Assur- ance Levels’ (EALs), that provide an ordering of assurance requirements from EAL 1, functionally tested, through to EAL 7, formally verified design and tested. A secu- rity product or part of a product, a ‘target of evaluation’ (TOE), can then be evaluated against the requirements of either a PP or an ST by a certification authority. Thus, the CC provides a mechanism by which security requirements may be cap- tured, together with a certification mechanism that enables the claims made by a prod- uct developer to be evaluated by a trusted third party. These mechanisms combine to enable the purchaser of a security related product gain confidence that a procured product will meet their security needs. When the CC approach is used to gauge the suitability of a particular security product, potential misunderstandings can occur. The TOE was evaluated against a PP or ST and the certification obtained specifies the level of trust that the TOE will implement those particular requirements. Potentially the TOE could be a subset of the procurable product, or the environmental conditions specified within the TOE may not be realisable in practical systems. Hence the certification may not necessarily provide any guarantee relating its performance of a product in a production environment. The use of the SDO concept when developing a security product is likely to be of assistance during the certification process. Its use will simplify aspects of the design, and as certification is both time consuming and very expensive, any simplification of design will translate into significant cost reductions. Using the SDO approach, rather than other more ad hoc approaches, will also simplify program testing and
20On most occasions, the requirements need not be developed, but instead are able to be selected from those already developed and cataloged within the CC. 2.6. Access Control and Security Policies 43 code inspections. Together, these factors should help establish the level of trust in a product’s security measures that will be needed if it is to gain certification.
2.6 Access Control and Security Policies
In this section, some representative examples of different ways of specifying and en- forcing security policies, will be reviewed. The aim of this section is to introduce the reader to research being undertaken in this area and place the access control model employed by SDOs in context. Whether at the system or SAA level, access to resources is mediated through the use of security policies which detail the rights of subjects to access protected resources. Although an enterprise wide security policy is written for a large organ- isation, that high level policy is usually implemented as numerous separate target dependent policies. The complexity arises because different servers, workstations, firewalls and SAAs will each have a separate policy relating to that part of the organ- isational policy, that it enforces. Potentially each of these policies will be written in a different, and usually low-level, language. Such a situation is far from satisfactory for many reasons including: the need for highly trained personnel to maintain the pro- tection measures, the virtual impossibility of generating a consolidated view of the policy that is actually being enforced, and making changes to the security policy is both expensive and error prone.
2.6.1 Specifying and Enforcing Application Level Security Policy
Numerous approaches have been taken to attempt to overcome the problem of multiple incompatible security policies within organisations. They tend to display two common characteristics. Firstly, they attempt to write the security policy for the organisation in a high-level and target independent manner and secondly, policy specification is separated from policy enforcement. In this section, the approaches taken by XACML and Ponder to standardise the specification and enforcement of security policies within an organisation, will be dis- cussed. 44 Chapter 2. Literature Review
2.6.1.1 eXtensible Access Control Markup Language (XACML)
The OASIS eXtensible Access Control Markup Language standard [60] takes the ap- proach of specifying security policies in a target independent manner, and using stan- dardised decision making software tools, ‘policy decision points’ which understand that policy specification, to enforce it. Such an approach requires that all requests for an access control decision must be translated from their target specific format to the format required by the policy decision point. This translation must take place every- time an access decision is to be made. XACML, defines both an XML based policy language and a framework for the processing of access decision requests. The policy language: (1) defines the XML format in which access control rules and policies may be expressed, (2) supports use of types and logical/ mathematical operations, and (3) supports the concept of ‘com- bining algorithms’21. Since XACML policies will be applied in a variety of target environments, the standard defines how an ‘XACML context’ is to be insulated from its environment. That isolation is achieved in a straight forward way. The context has defined inputs and outputs and the application environment is responsible for translating domain specific values to those required by the XACML context. The policy decision point, within the context, makes the access control decision on the basis of those translated inputs, and returns its result (that potentially may need to be translated to make it meaningful within the target environment). Thus, the security policies for an organisation can be written using a single policy language. The major benefit of this approach is that the widespread support for XML tech- nologies that is currently being displayed by major platform vendors and tool devel- opers, ensures the availability of the software tools needed to support this standards- based architecture.
2.6.1.2 The Ponder Policy Specification Language
In the Ponder [61] approach, security policies are specified using an general purpose policy language, Ponder. The Ponder language supports the writing of access control policies incorporating positive authorisations, negative authorisations and delegation;
21When multiple rules impact on a particular access decision, a combining algorithm can be specified within the policy that determines how potential conflicts between individual rules can be resolved e.g. the ‘Deny-overrides’ combining algorithm requires that for an access to be allowed, that access must be approved by all relevant rules. 2.6. Access Control and Security Policies 45 as well as supporting policy constraints and the composition of policies. Ponder takes an orthogonal approach to the specification and enforcement of se- curity policies to that taken by XACML. The Ponder policy for a particular security component is translated to the relevant target specific format. That translated pol- icy then used by the standard policy enforcement mechanism for that environment to make the access control decision. The translation of the security policy is performed by the policy compiler. The writers of the compiler adopted the standard compiler design that is used whenever a single input language needs to be translated into multiple output languages, using a single compiler ‘front end’, and multiple ‘back ends’ [62]. The compiler front end validates the input, in this case checking the security policy for consistency, before producing an intermediate representation of the policy being translated. That interme- diate representation is, in turn, translated by the relevant target specific compiler back end to the required target format. This approach has a performance advantage over XACML in that the translation is performed only once (at compile time), and the target specific policy is then used by the standard enforcement mechanism for the target environment. It suffers from the distinct disadvantage that only a limited number of compiler back ends are available.
2.6.1.2.1 Ponder and SDOs A Ponder compiler back end is available for the gen- eration Java security policy files. Consequently, the possibility exists to use the Ponder language to specify the security policy for an SAA and have that policy compiled to the corresponding Java security policy file. As only simple security policy was needed for the version of the CD Catalog pro- totype, the only prototype that used Java security policies, this mechanism was not used as part of this research. However it provides a mechanism by which the security policy for SDO based SAAs, can be written in the same language as other parts of the system’s security policy,
2.6.2 Enforcing Application Level RBAC
Typically fine grained access control decisions must be made within application pro- grams, rather than in the operating system due to the coarseness of control enforced at the system level. Beznosov et al. [46] supported that view: “There are two main reasons for application-level access control, namely the necessity in fine-grained ac- cess control and the need for authorisation decisions based on factors known only 46 Chapter 2. Literature Review
to the application”. Two different mechanisms for enforcing application level secu- rity policies that were instrumental in the defining the SDO authorisation mechanism will be discussed. In both approaches, a significant feature is the separation of the authorisation mechanism from application code.
2.6.2.1 Middleware provides RBAC functionality
Most applications access their information resources by making calls to the API as- sociated with the particular type of resource, e.g. the operating system’s file API for file access. Barkley [63] argued that the flexibility afforded by RBAC enables it to be applied within applications as well as at the system level. He proposed the re- moval of the access control logic from the application and moving that functionality to a middleware layer, which is responsible for mediating the interaction between the application and the information resource. Using their approach, the application ignores the need to restrict access to infor- mation and attempts to access the information by invoking the appropriate method in the API. The API method however, does not access the information resource, but in- stead makes the corresponding call on a role object. A role class is created for each role and encapsulates the security policy for that role. That role object is responsible for determining which resources a user acting in that role is permitted to access and the form of that access. If the requested access is permitted, the corresponding method is invoked on the object that maintains the information resource. An advantage of this approach is that a change in the privileges associated with a role, does not require a corresponding modification to the application program, instead, only the (potentially automatically generated) role class requires updating.
2.6.2.1.1 The Implications for SDOs This model illustrated that the separation of application logic from authorisation logic was achievable. Systems based on the use of SDOs also achieve the same separation of logic by delegating the responsibil- ity for access control from the application proper, to the individual SDOs. It would be prudent to further separate the authorisation responsibilities of the SDO from the data manipulation responsibilities, by partitioning the logic of SDO. The authorisa- tion logic should be encapsulated within a separate authorisation object, that although intimately associated with the SDO, is separate from the SDO. The use of separate authorisation objects is also expected to simplify the updating of the relevant SDO policies in response to updates to the application’s security policy as those changes 2.6. Access Control and Security Policies 47 will be confined to the authorisation object. The logic of the SDO itself would remain unchanged.
2.6.2.2 RAD Service in Distributed Applications
Beznosov et al. [47] propose the use of a ‘resource access decision’ (RAD) service within distributed CORBA applications to “decouple application level authorisation logic from application logic. Authorisation logic is encapsulated into an authorisa- tion service external to the application, which is traditionally part of the application program”. In their model, a client makes a request of an application service. Early in the processing of the request, the application service needs to determine whether that request should be permitted. Rather than making the authorisation decision itself, an authorisation request is sent to the RAD server. That message includes the information on which the decision should be based, namely the resource name, type of access being performed and the client’s credentials. The decision made by the RAD is then enforced by the application by either rejecting, or continuing to process the client request. An important aspect of the centralised nature of the RAD service, is that it al- lows both static and dynamic attributes22 of the subject to be taken into account when making the authorisation decision. The resource names and their associated access types are defined at the applica- tion level, and so capture the access semantics that apply at that level and allow fine grained application specific requirements to be encapsulated. Those resource names and access types have no meaning to the RAD, the authorisation decision is based solely on the specified security policy and does not rely on any knowledge of the se- mantics of the operations being administered. Clearly, application level authorisation decisions can be made by an external authorisation object without knowledge of the semantics of the decision being made.
2.6.2.2.1 Distribution of SDO Policies This research also supports the belief that separation of application logic from authorisation logic is generally applicable. The centralised nature of the RAD server architecture, ensures that authorisation decisions are based on the current policy information. Such an approach has implications to
22Static attributes do not change regularly and are set by system administrators. Dynamic attributes, on the other hand, encapsulate attributes which are constantly changing, e.g. the doctor is currently attending a particular patient. The use of a centralised service facilitates access to such information. 48 Chapter 2. Literature Review long lived SDOs. They too must be able to respond to changes to the security policy that may occur over time, so the use of a centralised authorisation object will solve the problems associated with keeping the policy current. Although that policy is unlikely to be directly accessed by an SDO’s authorisation object, local authorisation servers could regularly download policy updates from that central repository.
2.7 Trusted Computing Group and Trust Establishment
With the growth in user connectivity and the adoption of electronic commerce, there is a need for an increased level of security and trust on the Internet. The lack of trust is caused, to a large extent, by the huge number of personal computers (PCs) being connected to the Internet. These PCs typically lack a security aware operating system, and for those systems which have a security aware operating system, their owners lack the knowledge to configure the system appropriately. The Trusted Computing Group (TCG)23 was formed to develop industry standards which would help to address the non-trustworthiness of the Internet. As described on the TCG web site [64], the aims of this industry based standards body is to “develop and promote open industry standard specifications for trusted computing hardware building blocks and software interfaces across multiple platforms, including PC’s, servers, PDA’s, and digital phones. This will enable more secure data storage, online business practices, and online commerce transactions while protecting privacy and individual rights.”
2.7.1 The TCG Specification
The two aspects of the work of the TCG that are of particular interest to this research are: (1) the ability to obtain reliable security information about a remote computer, and (2) the provision of cryptographic functionality.
2.7.1.1 Trusted Platform Module (TPM)
As already identified, the main aim of the TCG is to facilitate online commerce by counteracting its major obstacle, the non-trustworthiness of user platforms. The in- herent assumption made within the TCG model is that a remote platform is not to be
23The TCG took over the standards work formally conducted by the Trusted Computing Platform Alliance (TCPA) early in 2003, and adopted the TCPA standards as their initial standards. 2.7. Trusted Computing Group and Trust Establishment 49 trusted until such time as evidence of its trustworthiness is provided. In their model, that evidence is provided by a new hardware component, the tamper-resistant trusted platform module (TPM). The TCG has specified both the functionality to be provided by a TPM and the programming interface to that module, the TCG Software Stack. A TPM that is compliant with the standard, must provide the following function- ality:
1. “Asymmetric key functions for on-chip pair generation using a hardware ran- dom number generator; private key signatures and public key encryption and private key decryption of keys enable more secure storage of files and digital secrets.
2. Secure storage of HASH values representing platform configuration information in Platform Control Registers (PCRs) and secure reporting of these values
3. An Endorsement Key which can be used by an owner to anonymously establish that identity keys were generated in a trusted platform module
4. Initialization and management functions that allow the owner to turn functional- ity on and off, reset the chip and take ownership, with strong controls to protect privacy” [65]
2.7.1.2 Establishing Trust
That platform independent specification is supplemented by platform specific speci- fications. The PC Specific Implementation Specification [66] defines the Core Root of Trust for Measurement, as being either the BIOS boot block or the entire BIOS. The Trusted Building Block, which comprises the TPM, Core Root of Trust for Mea- surement and their methods of connection to the motherboard, is the only part of the computer system that needs to be trusted. From this trust foundation, a chain of trust is established during the boot process. At each stage of the boot process, the currently executing entity reliably measures the next entity in the chain, and communicates the result to the TPM, before passing control to that next stage. A summary24 of the steps involved in the boot process for a PC follows.
24The complete specification for the boot process is detailed elsewhere [66, 67]. 50 Chapter 2. Literature Review
• On reset, control passes to the Core Root of Trust for Measurement (i.e. the BIOS) which obtains a measure (a cryptographic hash) of itself and other exe- cutable firmware present on the mother board, and transfers the measure to the TPM. This measure can be used to determine the trustworthiness of the BIOS.
• The BIOS after ensuring that the user is authorized to use the system, measures the operating system (OS) loader and communicates the result to the TPM.
• The OS loader similarly measures the OS kernel prior to its execution.
• The OS kernel obtains from the TPM, all of the measures collected during the boot process. By comparing the collected hash values with the hash values that were expected, the kernel can establish that only trusted software has been executed before it took control. Thus, the OS kernel knows that it has full control of the system and so is in a position to maintain the integrity of the system.
2.7.2 Remote Attestation
Those measures can also be used for remote attestation. As the measures collected during the boot process are securely stored within the TPM, the measures can be provided to a remote system or application as evidence of the trustworthiness of the platform. Naturally, the supplied metrics are digitally signed by the TPM to guarantee their authenticity and to allow detection of transmission errors. Importantly, the TPM does not certify whether the system is secure. The responsi- bility for determining whether the system should be trusted, resides with the receiver. The receiver can then either make an informed determination of the trustworthiness of the particular platform by referring to its own collection of trustworthy configuration signatures, or may instead rely on a trusted third party to make that determination on its behalf. Thus, it is suggested that sufficient trust can be established, to enable the parties to engage in electronic commerce over the Internet.
2.7.2.1 Limitations of Remote Attestation
Certainly, the information accumulated during the boot process and thereafter main- tained in a secure manner, provides reliable information relating to the state of plat- form when the operating system kernel was loaded. 2.7. Trusted Computing Group and Trust Establishment 51
There remains a significant problem with this approach. What has happened after the operating system kernel was loaded?
2.7.2.1.1 What Happened since the Kernel Loaded? Although, it is essential to know that the operating system kernel was loaded in an uncompromised state, it is still not possible to determine whether any security breaches have occurred since system bootstrap, that have rendered the platform untrustworthy. Device drivers typically execute with kernel privileges, so have the potent to under- mine the system’s security measures. As device drivers are not necessarily obtained from reputable sources, they pose a significant threat to the trustworthiness of the platform. Another threat is the flawed nature of commercial operating systems and their system tools, that too often execute with kernel privileges. Vulnerabilities are regularly being discovered in such system software, which if not promptly patched are exploited by viruses and related malware. The fundamental assumption made by the TCG that securing loading the kernel is sufficient to guarantee trust is flawed. For trust in a platform to be established, all the software that has been executed on the platform needs to be considered.
2.7.2.2 Achieving Reliable Remote Attestation
Recent work has been conducted by IBM Research [68–70] into the feasibility of extending the software measures presented during remote attestation, to include all software executed on a platform. Modifications were made to a Linux system, that would ensure that all software was measured before it was executed. If the measure was not amongst the measures already recorded, the name of the program, its measure and TPM signature, were added to the accumulation. Their results indicated that after a relatively short time, the size of the accumulation for their test systems plateaued. The data presented during remote attestation consisted of all the accumulated mea- sures, so a remote system was truly able to gauge platform trustworthiness. Although significantly more processing was required, they suggested that the reliability of the result justified the resources expended. There was however, a significant simplifying factor, the test platforms used the same reference installation, which enormously sim- plified the checking process. All programs were known to both systems, and there were not multiple versions of the same programs to consider. The research demonstrated that reliable remote attestation was achievable in con- 52 Chapter 2. Literature Review trolled environments, i.e. where a standard operating environment is maintained, in- cluding the application of vulnerability patches and software upgrades. However, the problem of achieving reliable remote attestation, in general, remains a monumental problem.
2.7.3 Implications for SDOs
The major benefit of the work of the TCG is the specification of the TPM, in partic- ular the specification for low cost cryptographic functionality that is becoming avail- able. The ability to securely store cryptographic keys and to perform hardware based encryption and signature generation, is expected to prove invaluable to SDO based SAAs. The availability of such hardware might also make the routine encryption and signing of an SDO’s encapsulated data practical. The remote attestation capability of a TCG compliant system is unlikely to be of a great benefit in the short term, except in those situations where there is a require- ment for a standardised platform configuration. In such circumstances, the remote attestation facilities, with the extensions discussed in Section 2.7.2.2, would provide sufficient information to make an informed risk assessment of the destination platform before an SDO is transmitted to that site.
2.8 Mobile Agents
In this section, a brief survey of research into the security of mobile agent based archi- tectures will be presented. Mobile agents are similar in nature to SDOs in that they, like other objects in a distributed application, are manifestations of mobile code and data. It would appear that approaches used to secure mobile agent based systems, be- yond those of other distributed systems, are likely to be applicable to distributed SDO based systems. The discussion will introduce the mobile agent model then discuss the mechanisms used to secure mobile agent platforms and mobile agents.
2.8.1 The Mobile Agent Model
The mobile agent model is aimed at achieving flexible execution in a distributed het- erogeneous environment. A mobile agent is a unit of code, state and data which have been specifically generated to fulfill a particular mission and is able to migrate au- 2.8. Mobile Agents 53 tonomously between agent enabled hosts25, i.e. they “exercise an individual’s or or- ganization’s authority, work autonomously toward a goal, and meet and interact with other agents.” [71] The perceived benefits of using mobile agents, rather than the more conventional client server architectures, are that they provide greater flexibil- ity in design and provide a mechanism for achieving low bandwidth asynchronous communication within a heterogeneous network. The characteristic that distinguishes mobile agents from other forms of mobile code is that an agent is able to suspend its execution on one host computer, cause itself to be transferred to another (agent-enabled) host and then resume its execution on the new host. A mobile agent can gain this exceptional ability by carrying state information, in addition to the code and data normally associated with mobile code. Farmer et al. [72] identified this state as including “a program counter, registers, envi- ronment, recursion stack, and store.” Thus a mobile agent can continue its execution from where it left off, following its own agenda. This is significantly different to ap- plets which only begin their execution on arrival at the host, and transferred objects that have their methods invoked according to the needs of their host. To fulfill their mission, agents will typically communicate or interact with other software (very often other mobile agents), or humans. “Possible interactions among agents include contract and service negotiation, auctioning and bartering.” [71] The security requirements of a mobile agent based system can be viewed from several viewpoints, however only two of those viewpoints will be considered here: the securing of host platforms from potentially malicious mobile agents and, the securing of mobile agents from potentially hostile platforms. Securing a host platform entails “the protection of hosting nodes against illegal accesses and leakage of information caused by the dynamic injection of potentially malicious mobile code by untrusted users.” [73] The other aspect is the interference with the agent by a hostile agent platform. That interference could take the form of: refusing the agent access to the resources that it requires to fulfill its mission, preventing the agent from migrating to the next site on its itinerary, or attacking the agent itself in an effort to determine or modify its behaviour and/or its collected data. Much of the following discussion relating to the mechanisms available for securing mobile agent based systems is derived from the “NIST Special Publication 800-19 — Mobile Agent Security” [71].
25For a mobile agent to be able to execute within different environments, agent code is typically interpreted. An agent environment is required at each site to provide a means of executing that code and to provide a consistent interface by which the agent can interact with that host environment. 54 Chapter 2. Literature Review
2.8.2 Securing Mobile Agent Platforms
Hostile mobile agents may take advantage of security flaws in the agent platform to either attack their host or access resources to which they are not entitled. The types of threats which hostile mobile agents pose include: (1) masquerading — posing as an authorised agent to gain access to resources or to shift blame for their malicious ac- tions, (2) denial of service attacks — consuming excessive resources which degrades the performance, or even causing shutdown, of the host platform, and (3) unauthorised access — gaining access to services and resources which were not permitted by the host’s security policy [71]. The conventional approach used to protect host platforms against such threats is through the use of a “reference monitor”. That approach is also used to protect mobile agent platforms where the reference monitor is used to establish “separate isolated domains for each agent and the platform, and control all inter-domain accesses” [71]. Interpreted languages are typically used to implement agent systems as they pro- vide mobile agents with platform independence. The use of interpreted languages also has the potential to provide significant security benefits to the host as interpreters can exert a much higher level of control over interpreted code than can be achieved over natively executing code. “The idea behind Safe Code Interpretation is that commands considered harmful can be either made safe or denied to the agent.” [71] By employ- ing a custom interpreter for the language, additional checking can be performed prior to the interpretation of unsafe instructions, that renders them safe. Also inherently unsafe instructions are implemented as a process termination instructions, or similar mechanism, that prevents the execution of those instructions. Safe code interpretation semantics can best be achieved by using a ‘safe’ language. Java is considered to be a safe interpreted language. It is type-safe, static checking is performed before code is executed and runtime checking is performed during its ex- ecution, to ensure adhesion to the Java language semantics. A security manager acts as a reference monitor ensuring that access to security sensitive resources is in accor- dance with the platform’s security policy, thus ensuring the confinement of code to the relevant security domain. “In addition, Java inherently supports code mobility, dynamic code downloading, digitally signed code, remote method invocation, object serialisation, platform heterogeneity, and other features that make it an ideal founda- tion for agent development. . . . However, limitations of Java to account for memory, CPU, and network resources used by individual threads [74] and to support thread 2.8. Mobile Agents 55 mobility [75] have been noted.” [71]2627 The level of host protection afforded by Java has lead to the development of several mobile agent platforms based on Java, in particular Aglets [76]. Java has also been used as the development environment for the SDO prototypes, because of the inherent safety of the Java language and execution environment.
2.8.3 Securing Mobile Agents
The difficulty of securing the information contained within an agent on a malicious platform was identified by Jansen & Karygiannis [71] as “the agent platform can not only monitor communications, but also monitor every instruction executed by the agent, all unencrypted or public data it brings to the platform, and all the subsequent data generated on the platform. Since the platform has access to the agent’s code, state and data, the visiting agent must be wary of the fact that it may be exposing propriety algorithms, trade secrets, negotiation strategies, or other sensitive informa- tion.” They continued by commenting that “an agent is completely susceptible to an agent platform and cannot prevent malicious behaviour from occurring, but may be able to detect it.” A number of methods have been proposed to attempt to protect mobile agents from malicious hosts. Two such approaches are ‘Obfuscated Code’ [77] and ‘Computing with Encryption Functions’ [78].
2.8.4 Applicability of Mobile Agent Techniques to SDOs
The most effective defence for host platforms is the use of a trusted operating system which will protect the SDO support environment from external threats. That support environment should in turn be implemented in a safe programming language such as Java or one of the .Net28 programming languages. Thus, type safeness of the language and the absence of unsafe language features, facilitates the development of an SDO environment with fewer errors. Combined with the security features of the language environment such as the Java Security Manager and the Java virtual machine, the securing of hosts to which SDOs are sent is simplified.
26The reference numbers in this quotation have been modified to make them consistent with those used within this document. 27Refer to Chapter 3 for a much more in-depth discussion of the security features of Java. 28.Net is a registered trademark of the Microsoft Corporation. 56 Chapter 2. Literature Review
The protection of SDOs, and more particularly its protected resources, from hos- tile platforms is a particular concern and will limit the use of the SDO concept to environments with established trust relationships. None of the defence mechanisms used by mobile agents appear sufficient to be useful in securing themselves or SDOs.
2.9 AspectJ — Aspect-Oriented Programming for Java
Aspect oriented programming is being introduced, as it potentially represents an ap- proach to implementing the concept of SDOs which shows a great deal of promise. It is a paradigm extension to the object-oriented programming paradigm which is aimed at addressing the loss in modularity which occurs when orthogonal aspects of a sys- tem’s requirements are addressed. Those aspects, referred to as ‘cross cutting concerns’ include optimization, as- sertion checking, logging and authentication. The code needed to implement such concerns is typically unstructured and is both scattered and duplicated across the ap- plication’s class hierarchy. The failure of object-oriented programming paradigm to adequately handle the diverse requirements of real systems was described by Lad- dad [79] as: “Most software systems consist of several concerns that crosscut multiple modules. Object-oriented techniques for implementing such concerns result in sys- tems that are invasive to implement, tough to understand and difficult to evolve. The new aspect-oriented programming (AOP) methodology facilitates modularization of these concerns.” AspectJ adds the concept of a joint point to Java, along with several language constructs to support that concept, namely: aspects, pointcuts, advice and inter-type declarations. A join point is a well defined point in a program’s flow of control, such as the calling of a method or the updating of a data member. Aspects are the unit of modularity for crosscutting concerns and correspond to the Java class construct. A pointcut picks out an arbitrary number of join points and exposes context infor- mation relating to those points. A specialized pointcut exists for each of the supported types of join points. Advice is like a method, in that it is a unit of code which will be executed whenever a captured join point is reached. The final construct, Inter- type declarations, are used to modify the static structure of the program. They permit the insertion of both data members and methods into a class, or the changing of the relationships which exist between classes, e.g. declaring that a class implements a paricular interface. 2.10. Summary 57
2.9.1 AspectJ and SDOs
Although at the byte code level, the code inserted by the AspectJ compiler is nec- essarily woven into the binary representation of the program, the source code of the program itself, remained unchanged, i.e. there was no need to manually add code at numerous places, in potentially many class files, which once inserted, tends to obscure the design of the program. From a practical point of view aspect oriented programming appears to be in- valuable. Duplication of code is not required, which simplifies change management. Consider that traditional approach to performing a debugging task. There must nec- essarily be code insertion around each targeted method call. Although careful design could reduce the impact of duplication to the insertion of method calls, duplication still exists. The need for one extra piece of debugging information might necessi- tate the addition of another parameter to that debug method. Then every call needs to be updated manually. With the aspect oriented approach, only the aspect would need be modified, followed by a recompilation. Also, the debugging code is removed from the production version of the program by merely removing the aspect from the compilation. There are disadvantages of the aspect oriented approach. When AspectJ is being used, the whole of the program’s source must necessary be compiled, to facilitate the location of all join points and the addition of advice where needed. Another problem is not being able to adequately view the changes that the AspectJ compiler has made to the program’s Java source code. The AspectJ browser only partially overcomes that concern. Despite these apparent advantages, when an attempt was made to use AspectJ convert a non-SDO class to an SDO class, the result was disappointing. That process undertaken and the difficulties experienced are described in Section 6.9.
2.10 Summary
This chapter reviews that section of literature which relates to the Self-Defending Ob- ject (SDO) concept. The SDO concept brings to the development of security aware applications, the idea that encapsulating objects should be made responsible for the protection of their sensitive resources. As illustrated in Section 2.3, that idea has already been successfully employed in diverse areas of research as digital rights man- agement and self-securing devices. Section 2.1 (and then in greater detail in Chapter 3) 58 Chapter 2. Literature Review identifies that such a concept is completely foreign to the current object-oriented pro- gramming paradigm. The need for increased application security was highlighted in Section 2.4 by con- sidering an important illustrative example, the need to meet the the legislative require- ments of the HIPAA legislation within the United States. The SDO concept helps to fulfil part of that need. The protection provided by SDOs takes the form of the enforcement of mandatory access control at the application and the provision of a complete audit trail. Section 2.5 explores the concept of mandatory access control and other features that must be pro- vided to create a trusted operating environment. In contrast, Section 2.6 discusses selected research that has been conducted into the provision of application level ac- cess control that guided the application of the SDO concept to the development of prototype SAAs. Sections 2.2, 2.7 and 2.8 introduced the Web services distributed programming model, the work of the Trusted Computing Group (TCG) and work on mobile agents, each of which helped to define the how the SDO concept might be realised. Chapter 3
A Review of Java’s Security Features
The SDO concept represents an extension to the current object-oriented development paradigm, that changes the way that mandatory access control is applied within SAAs. To make an informed decision of the worth of that approach, a clear understanding of what security features are provided by contemporary application development envi- ronments, needs to be attained by the reader. Only then can the reader decide whether the SDO concept complements or duplicates existing security features and be able to make an informed evaluation of the proposed SDO paradigm.
3.1 Why Java?
Object-oriented programming (OOP) has become the programming paradigm of choice for most new software development. The major benefits of object-oriented program- ming were described by Burgett [80] as “OOP offered a programming model with important advantages such as encapsulation and inheritance. Many problems facing developers were easier to solve when viewed from this perspective. And OOP also offered a greater opportunity to achieve one of the most elusive goals of large-scale development - reuse.” In addition, Laddad [79] attributes much of the success of object-oriented programming to its ability to constrain complexity in large systems. Currently there are two widely adopted development environments for object- oriented languages, Java and .Net1. As similar features are provided by both envi- ronments, this chapter will only consider the security features provided by one of
1Java and .Net are trademarks of Sun Microsystems and the Microsoft Corporation respectively.
59 60 Chapter 3. A Review of Java’s Security Features
these development environments, the Java platform. The choice of the development environment was somewhat arbitrary, with both Java and .Net being equally suitable for the task. That having been said, the practical consideration; the researcher had a good knowledge of the Java language and development environment, resulted in the adoption of Java. The Java language (JavaTM 2 Platform Standard Edition 5.0) was used by the candidate to develop the prototype applications used to investigate the ramification of adopting the SDO concept. The Java Platform was also considered to be the appropriate choice because both the application programmer’s interface (API) and Java Virtual Machine were designed to provide a programming and execution environment in which the provision of secu- rity was paramount. The Java platform, arguably, represents the current state of the art in security aware, object-oriented, development environments. From an application programmer’s perspective, the features that contribute most to the provision of application security are: the security manager, the Java Authentica- tion and Authorization Service Framework (JAAS) and support for object protection. These features in particular, will form the basis of the discussion in the next section. The separate issue, that of the provision of a secure virtual machine on which Java code executes, is discussed in Section 3.3.1.
3.2 Java’s Support for Security
From its conception, the provision of security has been a major design goal of both the Java programming language and the Java platform. The initial success of Java was closely entwined with the widespread adoption of the World Wide Web, which is considered to be an extremely hostile environment (from a security perspective). At the time, Java applets were the only way to provide non-static content on the web. Ap- plets can be downloaded along with the requested web page, from what is usually an untrusted site, and without the knowledge of the recipient. Without strong security in place, applets could provide the ideal mechanism for the development and distribution of computer viruses and allied malware. Hence, the initial Java security model “fo- cused on protecting users from hostile programs downloaded from untrusted sources across a network.” [81] The Java language and the Java Virtual Machine were initially designed to greatly restrict the functionality that applets could provide, i.e. applets were prevented from accessing any system resource that could be maliciously used. 3.2. Java’s Support for Security 61
3.2.1 The Java Language
The Java language incorporates features that promote the production of robust sys- tems by only allowing controlled access to memory. These features include: strong typing, structured memory access (i.e. no pointer arithmetic) and automatic garbage collection. Adherence to the semantics of the language is enforced by the Java Virtual Machine (JVM) and a combination of compile-time and run-time checking. Important run-time checks include ensuring that: any array index used is less than the array size; an object reference is not null; and any type cast performed is valid. Programming er- rors resulting from the absence of such restrictions in older programming languages, such as C, are regularly exploited by hackers to attack computer systems and applica- tion programs [82]. Security is further enhanced through the provision of support for structured error handling. Whenever an error is detected, an exception is raised. The handling of an exception involves the transfer of program control to a point in the program where, the system developer believes, that exception can be effectively handled. Any ex- ceptions that are not handled within the application, eventually propagate to and are handled by the system’s default handler. Depending on the exception type, they may be reported on the command console and the program continues to execute, or if suf- ficiently serious, the program is terminated. Importantly, the structured error handling mechanism prevents the program from crashing, which might in turn, cause the JVM to malfunction and potentially permit a security breach.
3.2.2 Securing the Java Platform
Daconta [83] describes other steps taken to secure the Java environment as “The most well known security aspect of Java is the Java sandbox, a general environment for containing applications. The next line of defense is the Java class loader, followed by the Java byte code verifier, and the last line of defense is the Java Security Manager.” A brief discussion of each of these components of the security architecture will be briefly introduced in the following paragraphs. The sandbox model effectively provides a place where Java programs can play/ execute (the sandbox) but where the program is prevented from doing anything that might be harmful. When the sandbox model is employed, all downloaded code, e.g. applets, are deemed to be hostile and so are provided with minimal rights. Any effects that the program code might cause, are prevented from leaving its sandbox, by the 62 Chapter 3. A Review of Java’s Security Features action of the security manager which restricts the code’s access to sensitive resources. To support the execution of distributed applications, the Java platform supports the dynamic loading of classes. Rather than loading the whole program into memory, class files are only loaded when required. Also, unlike a normal program loader, Java class loaders are not only responsible for loading class files, but are also responsible for ensuring the validity of the code and the maintainence of multiple namespaces that restrict what rights the loaded class gains by virtue of the package to which it belongs. The security benefits of using multiple namespaces is discussed in detail in Section 3.3.2.2. The execution of a flawed class file might compromise the integrity of the JVM, so as part of the load process, the class file verifier performs extensive check of the class file to ensure that its code is correctly formed. The role of the class verifier is discussed, in detail, in Section 3.3.1.1.1. Although the JVM inherits the access control rights of the user, these measures are designed to ensure that such rights are not automatically made available to potentially hostile code that is being executed on the JVM.
3.2.3 The Evolution of the Java Security Architecture
The security architecture has evolved significantly since its initial Java release. Each new release of the Java specification is accompanied by a reference implementation of that specification, the Java Development Kit (JDK).
3.2.3.1 Java 1.0 - Sandbox Security Model
The initial Java release, JDK 1.0, implemented the sandbox model. In that model, local code was considered to be completely trusted and so was granted full access to protected system resources, while downloaded code (applets) were considered to be completely untrustworthy, and so provided with extremely limited access to system resources. The restrictions placed on downloaded code were such that they were pre- vented from performing such operations as: accessing the local file system, opening network connections (other than to their originating server), starting other programs on client, and accessing system properties. The adoption of the sandbox model resulted a fundamental change in the provision of computer security. The almost universal use of untrusted operating systems meant that until the appearance of the sandbox model, preserving security relied on prevent- 3.2. Java’s Support for Security 63 ing malicious code from being run on the system. Anti-virus software provided the first and only line of defense. If that security barrier was breached, the virus (or related malware) would have unrestricted access to the system. Java’s Sandbox provided an alternative paradigm for maintaining security, one that permitted the execution of foreign and untrusted code, in the form of downloaded applets. Venners [81] described the profound difference the sandbox model made as: “Instead of security being established by requiring you to prevent any code you don’t trust from ever making its way onto your computer, the sandbox model lets you welcome code from any source. But as it is running, the sandbox restricts code from untrusted sources from taking any actions that could possibly harm your system.”By running the downloaded applet in a controlled environment, the Java Virtual Machine (JVM), the applet was prevented from performing any actions that might compromise the security of the system. Thus, provided the Java security measures were complete, downloaded (completely untrusted) applets could be safely executed on a computer system without compromising the integrity of the computer system.
3.2.3.2 Java 1.1 - Signed Applets
Because the sandbox model placed such severe restrictions on applets, applets were prevented from performing useful tasks even if they were known to be trustworthy. There was an identified need for the concept of ‘trusted applets’. In response, the Java 1.1 release saw a significant change in the trust model for applets. An applet that was either downloaded from a trusted site or signed by a “trusted” party, was considered to be completely trustworthy, so all restrictions placed on it were removed. To support the revised security architecture, the accompanying JDK included tools for the creation, manipulation and storage of digital signatures and certificates.
3.2.3.3 Java 1.2 - Security Domains
The release of Java 1.2 saw major changes in the Java security architecture which in- cluded: (1) local code could be subjected to the same scrutiny as remote code, (2) the configurability of the security policy was simplified by removing the policy specifi- cation from application code (typically the security policy is held in a separate policy file), and (3) the provision of fine grained access control was simplified and made less error prone. Supporting these changes required the introduction of the concept of security domains and security policies, to the security architecture. “Security do- mains (or as they are also called, protection or protected domains), are defined within 64 Chapter 3. A Review of Java’s Security Features a policy file via the signedBy or codebase keywords. A security domain is formed by granting a set of privileges to a given signer or codebase or combination of both.” [83]
3.2.3.4 Beyond Java 1.2
No significant changes to the security architecture occurred in the release of Java 1.3. The major changes made in Java 1.4 were the integration of the Java Authentica- tion and Authorization service (JAAS), the Java Cryptography Extension and the Java Secure Socket Extension into the JDK, that previously had only been extensions [84]. An important aspect of the Java security architecture is that both the architecture, and its implementation, are open to scrutiny. As Venners [85] observed, “Instead of keeping the internal implementation of Java’s security a secret “black box”, it is open to anyone who wishes to look at it. This encourages security experts seeking a good technical challenge to seek out security holes in the implementation. When security holes are discovered, they can be patched.”
3.2.4 Security Managers
Security managers provide configurable protection for most resources that are exter- nal to the JVM. Before a sensitive operation2 is performed, the classes of the Java API always invokes the application’s security manager to determine whether the re- quested operation is permitted by the application’s security policy. The security policy enforced by the default security manager is to allow local code unrestricted access to protected resources, i.e. the sandbox security policy. Similarly, if the default security settings of the web browser are not modified, the security manager within the browser will also enforce the sandbox security policy, i.e. greatly restrict the actions that ap- plets can perform. To enforce an alternative security policy on an application, a security manager can be explicitly installed3 when the application is executed. Before the Java program can be executed an instance of the JVM must be created, on which the program will run.
2Operations that are deemed as being sensitive by the Java Standard API include: accessing or modifying the local file system, accessing or modifying a system property, accepting or opening a socket, and causing the application to terminate. 3A security manager can also be installed from within the program. For the obvious security reasons, a security manager once installed retains control for the lifetime of the program, i.e. an installed security manager can not be removed, replaced or changed. 3.2. Java’s Support for Security 65
3.2.5 Security Policies
Within a security policy, permissions can be granted to code, either unconditionally or conditionally. When permissions granted conditionally, the conditions that apply can be specified in terms of the location from which the code originated, the presence of a trusted digital signature, or who is executing the code. The first two methods for conditionally allocating privileges are straight forward. Support for the last method, the granting of privileges on the basis of the user of the application, is provided by the Java Authentication and Authorization Services (JAAS) architecture. This feature is particularly useful to the developers of SAAs. Sun [86] describes the extensions made by JAAS as “the Java 2 security architecture requires additional support for authentication (determining who is actually running the code) and extensions to the existing authorization components to enforce new ac- cess controls based on who was authenticated. The JAAS framework augments the Java 2 platform with this support.” JAAS is described in detail, in Section 3.2.6. The overriding principle of the security model is that unless a privilege is explicitly granted, access to the corresponding sensitive resource will not be permitted. The ability to grant all privileges except those that have been specified, is not supported. A security policy file consists of a series of grant statements. An example policy file, security.policy, is presented in Listing 3.1. That security policy is not of any practical use, it is only useful for illustrative purposes, as it show the various forms that a grant statement can take. The first declaration unconditionally grants all code the permissions needed to read the name and version of the operating system. The second declaration grants code from the jar file ExampleApplication.jar4, which is stored in the current direc- tory, permission to read files in the current directory and its subdirectories. The third statement grants the same code the right to read the file C:/syslog.policy and to invoke the method load from the class catalogSDO.datastore.DataStoreRDB, but only if the current user is manager. This example illustrates the use of a user-defined permission. Here, the semantics of grant statement are to grant the right to invoke the method load from the class catalogSDO.datastore.DataStoreRDB. The use of user-defined permis- sions are discussed in Section 5.4.1.2. In a practical security policy, each of the grant statements would grant the code identified within it the privileges that are required by that code to perform its task.
4JAR files are used to package Java applets and applications. The files may be compressed and/or the JAR file be digitally signed to vouch for its trustworthiness. 66 Chapter 3. A Review of Java’s Security Features
Listing 3.1 Security policy file security.policy grant { permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; }; // code
grant codebase "file:./ExampleApplication.jar" { permission java.io.FilePermission "-", "read"; };
grant codebase "file:./ExampleApplication.jar", Principal security.UserID "manager" {
permission java.io.FilePermission "C:/log.policy", "read"; permission catalogSDO.security.SDOMethodCallPermission "catalogSDO.datastore.DataStoreRDB.load"; };
Conversely, no permission should be granted that is not required! Assuming that the Standard Java Platform is being used, the single line command presented in Listing 3.2 could be used to execute the application ExampleApplication. The command arguments,
-Djava.security.manager and -Djava.security.policy==security.policy
cause a security manager to be installed, the security policy to be read from the file security.policy, and that policy to be used to instantiate a policy object that will be used by that security manager. The argument
-classpath ExampleApplication.jar
specifies that the class path should be restricted to the specified jar file and the Java API. The packaging of the application in that jar file was necessary to allow its classes to receive privileges that were granted (to classes in that jar file) by security policy presented in Listing 3.1. Whenever an access to a sensitive resource is attempted, the Java API method invoked by the application will invoke the security manager to determine whether the access should be permitted. If, in the security policy, the relevant permission was explicitly granted to that code, the access will occur, otherwise the security manager throws an exception. 3.2. Java’s Support for Security 67
Listing 3.2 Running the application ExampleApplication subject to the security policy security.policy java -Djava.security.manager -Djava.security.auth.login.config==login.config -classpath ExampleApplication.jar -Djava.security.policy==security.policy ExampleApplication
(N.B. This command must appear on a single line.)
3.2.6 Java Authentication and Authorization Service Framework
The terms authentication and authorization were defined by Laddad [87] as: “Authenti- cation is a process that verifies that you are who you say you are. Authorization,on the other hand, is a process that establishes whether an authenticated user has suffi- cient permissions to access certain resources.” The JAAS framework provides com- prehensive facilities for performing both authentication and authorization within Java applications.
3.2.6.1 JAAS Authentication
Authentication is the process of establishing the identity of a user. Central to the JAAS framework are the concepts of principal, a name (possibly one of many) associated with a particular user, and subject, a collection of both principals and security creden- tials that are associated with a particular user. Consequently, a user (represented by a subject object) is permitted to have several identities (each of which is represented by a separate principal object). The need to use multiple identities is a consequence of applying the ‘Principle of Least Privilege’, that requires each user to be provided with only that minimum set of privileges that are required to perform their duties. When the user wishes to perform a particular privileged task, they assume the identity authorised to perform that task for as long as required to perform that task5. A key feature of JAAS authentication is that the application program remains inde- pendent of the authentication mechanism. By providing this independence, a different authentication mechanism or even multi-factor authentication6, can be ‘plugged into’
5The use of multiple identities, especially for privileged users, has significant security benefits. Should an identity of a user become compromised (e.g. they know the required username-password combination), the attacker can assume that identity, will gain the privileges associated with that identity. If the user has only one identity, the compromise would provide the attacker with all the privileges that the user possesses. 6An authentication mechanism might rely on the direct interaction with the user, the possession of 68 Chapter 3. A Review of Java’s Security Features the application as security requirements dictate, i.e. it is possible to change the mech- anism used to authenticate users, without having to modify the application program. Details of the steps involved in incorporating JAAS authentication within an Java application, are provided in Section 5.3.1. For complete details of the JAAS frame- work, the reader is referred to Sun Microsystems JAAS documentation [88, 89].
3.2.6.2 JAAS Authorization
JAAS authorisation supplements the access control enforced by the Java security framework on system resources. JAAS authorisation adds the extra perspective of controlling the action of a Java program, based on who is using the program. More formally, JAAS authorization is the process by which a determination is made as to whether an authenticated user has sufficient permissions/ credentials to access a par- ticular protected resource. Authorization is reliant upon the identity of the user that is established through authentication. Without that verified identity, decisions relating to a user’s right to access protected system resources, cannot be made. JAAS authentication provides that identity information, and any associated credentials, in the form of a Subject object. Knowing the identity of the user, hence the permissions they hold (from the security policy), the security manager is able to established the right of that user to access protected resource. When using the Standard Java Platform, the security policy for the program is read from a text file. The policy file presented in Listing 3.1 shows several ways that a grant statement can be used to grant permissions, to the application and its users. JAAS is fully integrated into the Java security model, grant statements that conditionally allocate user-centric privileges, may be freely intermingled with code- centric statements. Code automatically acquires such ‘code-centric’ permissions when the program is executed. The permissions associated with a particular user are only acquired after the relevant thread has been associated with that user, i.e. the relevant Subject object. That association is made by invoking methods of the Subject class. Once that association has been made, the security manager will mediate the actions performed by that thread on the basis of both the user-centric and code-centric permissions. Details of how that association is achieved, are presented in Section 5.4. credentials, the use of smart cards or biometric information. Increased security can be achieved by requiring a user to authenticate using more than one mechanism. Such authentication is referred to as being multi-factor authentication. 3.2. Java’s Support for Security 69
3.2.6.3 JAAS and SDOs
The SDO concept and JAAS provide complementary aspects of the provision of user- centric access control. The SDO concept provides the philosophy behind the appli- cation of access control, while JAAS provides potential mechanisms by which that philosophy can be implemented. JAAS authentication is particularly useful to SAA developers as it provides the infrastructure needed to enable user authentication, while at the same time supporting features such as the independence of the application from authentication mechanism and support for multi-factor authentication. JAAS provides two authorization mechanisms: the use of either the security man- ager or an access control context, to make the required authorisation decision. Those mechanisms are described in Section 5.4 and their usefulness contrasted in Section 5.5.
3.2.7 Java Support for Object Protection
Java provides support for object protection by providing three distinct mechanisms by which an object may be (1) cryptographically signed to protect its integrity (a Signe- dObject) (2) encrypted to provide confidentiality (a SealedObject) and (3) associated with a guard object which controls access to the protected object (a GuardedObject).
3.2.7.1 Signed Objects
A java.security.SignedObject encapsulates both the object being protected and a cryp- tographic signature for that object. The signed objects are described within the Java API documentation [90] as: “SignedObject is a class for the purpose of creating authentic runtime objects whose integrity cannot be compromised without being de- tected. . . . The signed object is a ‘deep copy’ (in serialized form) of an original object.” The protected object can only be extracted if its associated digital signature is valid. Like a signed JAR file, a signed object provides a mechanism by which any loss in the integrity of an object is made evident. A signed object differs from a signed JAR file in that it provides a mechanism for the signing runtime objects, rather than files. Possible uses for signed objects that were identified by Gong [91] were the pro- vision of unforgeable authentication and authorization tokens, and the protection of objects being transmitted between virtual machines or those held in storage. 70 Chapter 3. A Review of Java’s Security Features
As identified by Gong, sealed objects have a potential role to play in the develop- ment of SAAs, as a means of protecting security tokens, whose integrity are critical to the correct operation of the authorisation mechanism. Signed objects could also be used to monitor the integrity of SDOs, especially when they are being migrated between machines.
3.2.7.2 Sealed Objects
A java.crypto.SealedObject provides a mechanism for preserving the confidentiality of an object. The use of sealed objects is described within the Java API documenta- tion [90] in the following manner: “Given any Serializable object, one can create a SealedObject that encapsulates the original object, in serialized format (i.e., a ‘deep copy’), and seals (encrypts) its serialized contents, using a cryptographic algorithm such as DES, to protect its confidentiality. The encrypted content can later be de- crypted (with the corresponding algorithm using the correct decryption key) and de- serialized, yielding the original object.” If a guarantee of both the integrity and confidentiality of an object is required, the object should firstly be signed by creating a SignedObject, and then encrypted by creating a SealedObject from that signed object. The most likely use for sealed objects in SDO based SAAs is to guarantee the confidentiality of SDOs that are being transmitted across the network.
3.2.7.3 Guarded Objects
A java.security.GuardedObject is an object that encapsulates both a protected object and a guard object. The guard object is responsible for restricting access to the pro- tected object. When a request is made to extract the protected object from the Guarde- dObject, the guard is called upon to perform a permission check. Then, on the basis of the privileges held at the time, either the protected object is returned or an exception is thrown. To be used as a guard, an object must implement the Guard interface. All of the permission classes supplied within the Java API, implement that interface and so are potential guard objects.
3.2.7.3.1 SDOs and GuardedObjects At first glance, it might appear that a guarded object provides the same functionality as an SDO. In both cases, there is some pro- tected content and an associated guard or authorization object that controls access to 3.3. The Java Virtual Machine 71 the protected content. However, a guarded object is only used to protect a whole ob- ject, i.e. the object must be extracted before it can be used. An SDO, on the other hand, does not provide protection for the object as a whole, but instead provides finer grained access control by determining which of the methods and data members of the SDO may be accessed. Importantly, an SDO’s access controls are part of the SDO, so for as long as the data remains within the SDO, those resources are protected. When discussing guarded objects, in an example that illustrated how guarded objects could be used to protect a FileInputStream, Gong [91] described the provi- sion of SDO functionality in the following manner: “hypothetically we can radically rewrite the FileInputStream class as follows. ...Forevery access method (such as read(bytes)), the uniform security check in the form of g.getGuard() is invoked first.” Using this approach, the modified FileInputStream would have become an SDO. No comment was made regarding the advisability or otherwise of such an approach.
3.3 The Java Virtual Machine
3.3.1 Introducing the Java Virtual Machine
The heart of Java technology is the Java virtual machine (JVM), an abstract stack- based computer whose operation is specified in ‘The Java Virtual Machine Specifi- cation (Second Edition)’ [92]. Since the Java specification only describes how the virtual machine should behave, not how it should be implemented, JVMs from differ- ent vendors vary greatly in how they are implemented. However, they must all be able to read a class file and execute the virtual machine instructions in that file in a manner that ensures that the semantics of the language are adhered to. Potential techniques for executing those JVM instructions include: direct inter- pretation, just-in-time compilation, adaptive optimization and native execution (i.e. in silicon). The JVM has no knowledge of the Java language, it only knows about ‘class files’ and ‘bytecode’, so theoretically the JVM can execute bytecode generated by compilers for other languages [62, 93]7. A separate instance of the JVM is created to execute each Java program. The virtual machine once instantiated, starts executing the program at the method main
7Although other type-safe programming languages can be supported, the design of the JVM instruc- tion set was based on the need to support only one language, Java. Consequently, their implementation may be complicated by the lack of JVM support for language features not found in Java, e.g. passing parameters by reference. 72 Chapter 3. A Review of Java’s Security Features of the specified class. When the program terminates8, the virtual machine will, by default, terminate all activity immediately and exit. A program that requires some program specific cleanup to be performed before the virtual machine terminates, can require that all object finalizers9 are invoked. Due to the importance placed on security within the Java framework, the integrity of the JVM10 is protected. Class files are checked for integrity prior to their execution and extensive runtime checks are performed as they execute. At runtime, checks are performed to detect allocation errors on the application stacks11 and the heap. The detection of such errors cause the appropriate exception to be raised, which permits the controlled handling of these events. The provision of exceptions and safe exception handling, plays a pivotal security role in both the Java language and the JVM.
3.3.1.1 The Loading, Linking and Initialisation of a Class
In a typical implementation of the JVM, when a class or interface is referenced for the first time, the absence (from memory) of the relevant Class object (the binary repre- sentation of the class) will be detected. A class loader is used to locate the relevant class file and from the content of the class file, construct a Class object to represent that class. However, before the class can be executed, it must be linked. Linking12 involves three stages: verification, preparation and resolution, which are discussed in the following sub-sections.
3.3.1.1.1 Verification The verifier has a significant impact on the robustness of the JVM, by ensuring the validity of class files before they are executed. The execution of either malformed or an invalid byte code instruction by the JVM might result in the incorrect execution or even the crashing of the JVM, invalidating the JVM’s protection
8The program is deemed to have terminated when all non-daemon threads have terminated, or the exit method from either of the classes System or Runtime is invoked. 9Finalizers are described in Section 3.3.1.3. 10In this context, the ‘integrity of the JVM’ means that the JVM is prevented from executing any code which might cause it to crash or behave abnormally, preventing the JVM from providing the required level of security. It does not mean that the virtual machine is capable of monitoring its own integrity, i.e. the JVM does not contain self-checking code. 11Each thread has a separate stack. 12In the following discussion, the assumption will be made that no errors occur. However, errors are possible; the class file may not be found, it might be malformed or there is insufficient memory to perform an operation. If an error occurs, the relevant exception will be thrown, and if not successfully handled, will result in the termination of the thread. 3.3. The Java Virtual Machine 73 mechanisms. Ensuring that only valid class files are executed by the JVM, is a corner- stone of Java security. The JVM cannot rely on compile time checking performed by the Java compiler, after all the class file currently being loaded might have been produced by a buggy compiler or an attacker using a byte code ‘assembly level’ language. “The class ver- ifier enables untrusted code to be verified up front, rather than on the fly as the code is executed. This ability provides uninterrupted execution (the program can’t “crash” uncontrollably) at a minimal cost in execution speed.” [94] The verification stage ensures that the binary representation of the class is struc- turally correct and obeys the semantic requirements of the JVM. If a problem is dis- covered, an exception is thrown, and the class file is never executed. The checks performed by the verifier include ensuring: (1) that each instruction has a valid op- code and obeys the Java type discipline no matter how that instruction is reached; (2) that the target of each jump instruction is an instruction opcode (3) that at no stage during the execution of each method does the operand stack exceed the size specified in the class file; and (4) that all method signatures are structurally correct. During ver- ification, all checks are carried out on the class file, that are possible without reference to other classes.
3.3.1.1.2 Preparation The preparation stage is responsible for the creation and the initialisation of static variables13, to default values (i.e. either zero or null depend- ing on their type). The use of uninitialised variables is a common bug in computer programs. Additionally, a check is performed to ensure that a non-abstract class does not contain any abstract methods. The absence of this check could allow a method without a body to be invoked, potentially jeopardising the integrity of the virtual machine. During this stage, implementations often create additional data structures to improve runtime efficiency, e.g. a method table which will permit the efficient location of the methods of the class.
3.3.1.1.3 Resolution A Java compiler cannot assume any particular implementa- tion of the JVM and its runtime structures, so a compiler has no way of knowing where entities, either within or outside the class, will be located at runtime. Consequently, only symbolic references (effectively the fully qualified names of the entities) are used
13This load time initialisation of static variables supplements the checks performed elsewhere, that ensure non static variables are initialised. 74 Chapter 3. A Review of Java’s Security Features within Java class files. Resolution involves checking that a symbolic reference is valid and then determining the runtime location of that entity14. Resolution is optional, during the initial linking of the class. Different implemen- tations of the JVM are permitted to perform resolution at different times. In an extreme case, all symbolic references within the class might be resolved during the linking of the class. Alternatively, resolution may be deferred until a reference is actually re- quired, or some compromise between these two approaches might be used. “The only requirement regarding when resolution is performed is that any errors detected dur- ing resolution must be thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error.” [92] The process of resolution is further complicated by the presence of multiple names- paces. Each class loader is associated with a different namespace, that contains all the types that it has loaded. “When the virtual machine needs to resolve a symbolic ref- erence from one class to another, it requests the referenced class from the same class that loaded the referencing class” [95]. Thus, two classes with the same fully quali- fied name, but which were loaded by different class loaders, will belong to different runtime classes. Further discussion of namespaces is provided in Section 3.3.2.2.
3.3.1.1.4 Initialisation Initialisation is the process that results in the class being placed into a consistent state15. That process involves the execution of the static ini- tialisers and the initialisers of static fields, that ensure that all class variables have been correctly initialised, i.e. to the values specified in the program code (over writ- ing the default values that were set during preparation). The recursive initialisation of superclasses is performed before the initialisation of the class itself. It should be noted, that following the loading, linking and initialisation of a class, only a Class object, which represents that class has been created and added to the JVM. The class object contains the validated bytecode from the class file and is now in a consistent state having had its static variables initialised. However an instance of that class has not been created. The creation of a class instance, i.e. an object, will be discussed next.
14Typically, once the entity has been located, the symbolic reference is replaced by the direct refer- ence. 15A class will be initialised at the first active use of the class. 3.3. The Java Virtual Machine 75
3.3.1.2 The Creation of a Class Instance (an Object)
The creation of an object occurs explicitly16 when a class instance creation expression is executed (the Java keyword new is used) or the newInstance method of the relevant Class object is invoked. When an object is created, in the JVM memory is allocated for the instance variables17 of the class, and its superclasses. The initialisation of the object involves the following steps: (1) superclass ob- jects are (recursively) initialised by either invoking the explicitly specified superclass constructor, or if none is specified, the implicitly implied default superclass construc- tor, (2) the instance variable initialisers for this class are executed, and finally (3) the remainder of the body of the constructor is executed. “The Java virtual machine does not mandate any particular internal structure for objects. In some of Sun’s implementations of the Java virtual machine, a reference to a class instance is a pointer to a handle that is itself a pair of pointers: one to a table containing the methods of the object and a pointer to the Class object that represents the type of the object, and the other to the memory allocated from the heap for the object data” [92]. Assuming such a scheme had been adopted to permit the efficient method invocation, the runtime organization would be similar to that shown in Figure 3.1. That figure shows the location of these data structures within the runtime data areas of the virtual machine. The organisation of these data areas is discussed in detail in Section 3.3.2.3.
3.3.1.3 Finalisation of a Class Instance (Object)
When an object is no longer reachable, its memory will be automatically reclaimed by the garbage collector. A finalizer can be used by an object to perform any required cleanup, such as releasing resources (e.g. file handles, database connections) held by the object, before the object is reclaimed. A finalizer for the object is created by overriding the superclass method Object.finalize18. The JVM specification does not specify how soon or in what order finalizers will be invoked, hence finalizers should not be used to perform tasks that must be carried out in a timely manner for the correct operation of the program. For an object which encapsulates sensitive information, it would be tempting to
16String objects can also be created implicitly. 17Instance variables are the non-static variables declared that were declared at the class level within the Java source code. Each object has its own personal copy of these variables. 18It should be noted that finalizers differ from constructors, in that finalizers in super classes are not implicitly invoked. Consequently the finalize method of the superclass object is normally invoked. 76 Chapter 3. A Review of Java’s Security Features
Object A handle Heap reference to object A method table ptr Object B handle instance data ptr method table ptr reference to object A instance data ptr other Object B objects & Object A handles instance instance data data
Method Area Method table Class C class data ptr class data method data ptr method data ptr method data method data other method data ptr method data method data ptr method data classes
Figure 3.1: Possible realisation of two objects of a class C use a finalizer to overwrite that information. This approach may not be effective, see Section 4.4.2.1.2.
3.3.2 The Architecture of the JVM
The JVM Specification describes the operation of the JVM in terms of data types, subsystems, memory areas and instructions. These components are used purely to describe the outward behavior of the virtual machine. As shown in Figure 3.2, the major subsystems of the virtual machine are: (1) the class loader subsystem, that is responsible for loading class files into the virtual machine, (2) the runtime data areas that provide storage for the components of the executing program, and (3) the execution unit (that typically contains multiple execution engines19) that is responsible for execution of the program code.
19An execution engine is responsible for executing the bytecode of a thread, i.e. as the thread is executing, the execution engine (logically at least) translates each bytecode instruction to its equivalent machine code for the real processor on which the JVM is running, and causes it to be executed. This does not necessarily mean that the bytecode is being interpreted, other techniques may be employed. 3.3. The Java Virtual Machine 77
Class class Execution Loader file Unit Sub system
PC Registers Heap Method Area Java Stacks Native Method Stacks
Class data
(1 per thread) (1 per thread) Object (1 per thread) Run time Data Areas
Figure 3.2: Logical organisation of the JVM
3.3.2.1 The Execution Engine and Instruction Set
A virtual machine is created to support the execution of each Java program, with an execution engine being instantiated for each thread within that program. In the JVM Specification, the behavior of an execution engine is specified in terms of how it should behave as it executes each of the virtual machine instructions. How the required behavior is achieved is an implementation consideration and might involve one or more of the following approaches: direct interpretation, JIT (just-in-time) compilation or hardware implementation. A ‘PC register’ data structure is created for each thread (in the runtime data area) to hold the address of the current instruction. Just like a real machine, the execution engine executes the standard fetch-execute cycle, i.e. fetches the instruction at the address held in the PC register and then executes that instruction. The PC register is updated as part of the instruction execution. In the JVM, the determination of the next instruction is significantly complicated by Javas support for exception handling. If an exception is thrown, control must be transferred to the first handler capable of handling that exception. If the exception cannot be handled within the method in which it is thrown, control passes to the invoking method and the same exception is re-thrown at the point of method invocation. Thus, the exception propagates back up the call chain until it is successfully handled, or if it cannot be successfully handled, results in the termination of the thread. The bytecode for a method is an instruction sequence with the first byte of each 78 Chapter 3. A Review of Java’s Security Features
instruction being the opcode. The opcode is followed by zero or more operands. In an attempt to reduce code size and improve performance, many instructions have implied operands. Being an abstract stack machine, the operand stack is often the implied source and destination for operands, e.g. the isub instruction pops the top two int values off the operand stack and pushes the computed difference back onto the stack. Other instructions have local variables20 or common constants, as implied operands. Reflecting the strong typing of the Java language, the JVM has separate instruc- tions for operating on different primitive data types, e.g. subtraction is carried out by the instructions isub, lsub , fsub and dsub, that operate on operands of type int, long, float and double respectively. To ensure that the number of instructions does not ex- ceed 256 (i.e. ensure that all opcodes only occupy a single byte) not all data types are supported by the instruction set21. The JVM operates on two kinds of types, reference and primitive types, which correspond to their Java language equivalents. Although the ranges for the primitive types are defined within the Java specification, the actual amount of memory allocated for each type within the virtual machine, is implementation dependent. In the JVM specification, the abstraction notion of a word is used. It is defined in the following manner: “A word is large enough to hold a value of type byte, char, short, int, float, reference, or returnAddress, or hold a native pointer. Two words are large enough to hold values of the larger types, long and double. Javas runtime data areas are all defined in terms of these abstract words” [92].
3.3.2.2 The Class Loader Subsystem
Given the binary name of a class, a class loader is responsible for loading that class22. As discussed previously, that process is more correctly described as finding, loading, linking and initialisation of the class. There are two kinds of class loaders: the bootstrap and user-defined class load- ers. Each JVM implementation is required to provide a bootstrap class loader that is responsible for loading the classes of the core Java API. All other class loaders are defined as being user-defined even though they may be supplied as part of the
20For example, the iload 1 instruction pushes the integer value at position 1 in the local variable array, onto the operand stack. 21Types char, short and byte are usually promoted to type int and are manipulated using int instruc- tions. Type conversion instructions are provided to convert between these unsupported types and the supported types. Such instructions also perform the explicit type conversions found in user code. 22Class objects for array classes are not created by class loaders, but are created automatically as required by the Java runtime system. 3.3. The Java Virtual Machine 79
Java API, e.g. the supplied ‘class’ loader. That loader is responsible for loading class files located on the local file system in some platform-dependent manner. On many platforms, this involves the searching for the class files in directories specified by the CLASSPATH environment variable. Other user defined class loaders that might be use- ful to a particular application include those which are capable of downloading class files from a network server or handling encrypted class files. Each class loader is associated with a separate namespace. The use of multiple namespaces improves the security of the system. After briefly considering the design of class loaders, Section 3.3.2.2.2 will discuss two examples that illustrate how that improvement in security can be achieved.
3.3.2.2.1 Design of Class Loaders In Java 2, user defined class loaders extend the abstract class java.lang.ClassLoader and use a delegation model when loading classes. Each class loader has an associated parent class loader. When a class loader is requested to find a class, the search is initially delegated to its parent. Only if the parent cannot find the class, will the class loader attempt to find the class in its special way. The bootstrap class loader is the last link in the chain, so will always be the first to attempt the loading of a class. Thus, the use of the delegation model will ensure that the trusted API classes will be loaded by the bootstrap class loader [90].
3.3.2.2.2 Multiple Class Loader Improve Security A class will often grants spe- cial access privileges to classes that either extend that class or belong to the same package. At runtime, those additional access rights will only be granted to those classes that belong to the same runtime package, not the same declared package, i.e. they must not only have the same package name, they must also have been loaded by the same class loader. Consider a class that attempts to gain special access rights to the trusted API classes by having the same package name as the target trusted classes. The boot- strap loader will only search the Java installation when trying to load the specified class file, so it will not find the rogue class, that are not part of the API, i.e. just having the appropriate package name does not mean that it will be loaded by the bootstrap loader. Assuming that the rogue class is eventually loaded, the load will be performed by one of the user-defined loaders. Since each loader is associated with a separate namespace, the hostile class will belong to a different run-time package to the trusted classes. Consequently, it will not gain any special access privileges, by having that trusted package name. 80 Chapter 3. A Review of Java’s Security Features
As a second example, consider a class that has the same fully qualified name as a trusted API class. It hopes that its methods, rather than those of the trusted class, will be invoked by the application. Using the delegation model, the bootstrap loader will always be the first loader to be given an opportunity to load the class. Using the fully qualified name, it will search the Java installation for the class file, which it will find and then load. The trusted class, not the impostor, will be loaded. Thus the loading of an impostor class will not occur. These two examples considered access to trusted API classes. The argument ap- plies equally well to the protection of classes loaded by the other class loaders. For example, classes loaded by the API provided class loader (that only loads classes that are located on the classpath) will belong to different runtime packages to those loaded by the NetworkClassLoader that loads remote classes. Thus, the use of runtime packages that depend on both the package name and the class loader that performed the loading of the class, improves system security.
3.3.2.3 Runtime Data Areas
The virtual machine needs memory to store information relating to the program that it is executing. In the JVM specification, the storage requirements are described in terms of the following runtime data areas: (1) the method area — stores bytecode and other information from the class files, (2) the heap – stores instantiated objects, (3) the Java stacks – store the state of the (Java) method invocations, (4) the native method stacks — hold the stack frames of native methods and (5) the PC registers – hold the address of the next instruction. A Java program typically consists of multiple threads, so the organization of the data areas must reflect this property. The heap and method area are considered to be singular resources that are shared amongst all threads, e.g. multiple threads may reference the same object in the heap (see figure 3.3). However, each thread has a separate Java stack, native method stack and PC register, that is instantiated within the corresponding data area, when the thread is created. These data areas are described in an abstract way, within the JVM specification, so JVM implementation designers are free to implement the data areas however they wish. There are not even requirements that define whether or not, each data area needs to be contiguous or expandable. 3.3. The Java Virtual Machine 81
3.3.2.3.1 PC Registers When the thread is created within the Java program, a pro- gram counter (PC) register is created along with the execution engine instance. The PC registers are one word wide and while the thread is executing Java code, the PC register holds the address of the current instruction. Should a thread be executing native code, the PC register is undefined.
3.3.2.3.2 Heap The single heap is shared amongst all the threads in the Java pro- gram and is used for the storage of objects and arrays. Logically, the representation of an object consists of two parts. The first part is the set of instance variables, effectively an array of words, the memory for which is allocated on the heap. The second part is a reference to the class data that provides amongst other information, the code and static variables associated with the current object. As that class reference provides access to the runtime class object, not the declared type of the object, dynamic linking occurs naturally. The search for a method, will initially be carried out in that class and then in each of its super classes in turn. Thus, the latest version of any over-ridden methods will be found and invoked. That class information will also permit the validation of any explicit casts made within the Java source, and support operation of the instanceof operator. As objects are never explicitly deallocated within a Java program, the virtual ma- chine has no instruction to deallocate memory. However, any practical JVM imple- mentation will need to provide some form of automatic storage management that re- claims the memory allocated to non-reachable objects, e.g. a garbage collector. To support the operation of the garbage collector, it is highly likely that usage informa- tion will also need to be stored within the object data.
3.3.2.3.3 Method Area The method area is shared amongst all threads and is used to store the per class structures which include: the constant pool, field and method data, together with the code for each of the methods, constructors and special ini- tialisation methods associated with the class. The constant pool is derived from the constant pool table of the class file and has a similar function to the symbol table of a conventional programming language, but it stores more information. As well as stor- ing name, type and modifier information relating to the class itself, its methods and fields; the constant pool also contains references to all internal and external methods and fields referenced within the class. As immediate string and many numeric values are not stored in machine instructions, they too are stored in the runtime constant pool. In Java, all linking occurs at runtime. The data areas of the JVM are defined in 82 Chapter 3. A Review of Java’s Security Features terms of an abstract model, so a compiler can make no assumptions regarding how the contents of class files will be stored within a particular virtual machine implementa- tion. Thus, at compile time, there is not even a way to directly reference targets within Java class file being compiled, let alone those in other class file. Consequently, all linking occurs at runtime and all references within class files are symbolic. As the runtime, constant pool which is derived from that table in the class file, initially con- tains only symbolic references23 to the referenced entity. During symbol resolution, the symbolic reference is used to derive the actual location of the target. Potentially, this process could cause the loading of one or more other types (i.e. class files). As each symbolic reference is resolved, the symbolic reference will almost certainly be replaced by a direct reference.
3.3.2.3.4 Native Method Stacks The Native method stacks area is used to store the platform specific data structures, typically a contiguous stack, that is required to support function calls. A native stack is provided for each thread. These native stacks are used by the virtual machine to support both user supplied native methods, i.e. methods written in languages other than Java, and non-Java portions of the JVM im- plementation. If the particular implementation does not support native methods and does not require that area for its own operation, there is no need for this area to be provided. The Java Native Interface (JNI) is responsible for providing support for the trans- lation of the contents of a Java stack frame to those of the corresponding native stack frame and the conversion of values of Java and native types.
3.3.2.3.5 Java Stacks Java stacks serve a similar purpose to stacks in other lan- guages and here too, a separate stack is created for each thread. A stack frame is pushed onto the threads stack each time a Java method is invoked. The frame holds the local variables, operand stack and frame data for the invoked method.
3.3.2.3.6 Operand Stack The JVM has a stack-based architecture that uses a sep- arate stack to support the computation performed within each method and acts as the implicit source and destination for the operands of many instructions. It is effectively an array of words that is allocated within each stack frame24 which can only be ac- 23Symbolic references consist of the so called ‘binary representation of the name’. It is not binary in the normal sense, but is instead a shortened text representation of the fully qualified name of the target. 24The size of the methods operand stack is computed at compile time and provided as a method attribute within the class file. 3.3. The Java Virtual Machine 83 cessed using stack operations. The class verifier ensures that the operations performed on the contents of the operand stack follow the type requirements of the Java language. Since different instructions are used to push values of different types onto the stack and to perform computations involving different types, analysis performed during the loading of a class, ensures that transgressions such as pushing two ints onto the stack, and later using them as a value of type double in a computation, can not occur.
3.3.2.3.7 Runtime Organisation of the Data Areas The overall runtime organi- sation of the runtime data areas that have been discussed in the preceding sections is presented in diagrammatically in Figure 3.3. For simplicity the PC registers, native stack frames and the Java stacks for all but one of the threads, have been omitted.
Heap Object B handle method table Method Area method table ptr class data instance data ptr class & method other Object B code objects & instance other constant pool handles data classes Class A
this other param 1 other frames of param 2 Java call chain param 3 stacks temp / operand locals stack local variable array PC Registers A Java stack Current frame Java Stacks
Figure 3.3: Organization of the Java Stacks Data Area
Java Stacks The Java stacks area contains the stack frames for all active methods in all threads running within the JVM. Frame detail is only presented for the current frame for one of the threads, i.e. the frame of the currently executing method. The operand stack holds the data currently being operated on by the method. The current method is an instance method, so the first entry in the local variable array is a ref- erence to the object to which the method belongs (this), in addition to data which is 84 Chapter 3. A Review of Java’s Security Features
always present namely the parameters of the method, local variables and temporary variables required by the compiler. The this parameter, like all object references after they have been resolved, is a pointer to the relevant object within the heap. Some parameter types, e.g. strings, may be accessed via the constant pool. The remainder of the elements of the local variable array are primitive types, sufficiently small that their values are stored within the local variable array.
Heap The heap contains all the objects belonging to all threads within the JVM. In Figure 3.3, objects are assumed to be implemented via object ‘handles’, which in turn point to the object themselves25. The object itself is effectively an array of words in which the instance variables of the method are stored. Access to the code for the method is obtained via the other pointer within the object handle.
Method Area The method area contains the class information for all the classes that have been loaded into the JVM. Each ‘class object’ contains the class variables, the class and method code, and potentially other data structures such as a method table. In Figure 3.3, the handle for Object B provides a pointer to the method table which enables the quick location of methods and class variables associated with Object B.
3.4 Summary
This chapter has provided a reasonably in depth description of the security features provided by the Java language and development environment. Its intent was not to act as a definitive description of Java, which is already provided by numerous books on the subject, but instead to fulfil two objects: (1) to identify, especially for those readers who are not familiar with contemporary application development environments, the extent of the security features that are incorporated into development environments, and (2) to introduce those Java features that are used in the implementation of the prototypes developed to support this research (and will be used in the discussion in later chapters of the thesis). The information contained within the chapter should have shown that the SDO concept is indeed novel and represents a significant and beneficial paradigm shift for SAA developers. It is evident that the SDO concept both complements the existing
25This implementation was discussed in Section 3.3.1.2. 3.4. Summary 85 security features provided by development environments, and provides a framework for harnessing the power of low level security mechanisms. 86 Chapter 3. A Review of Java’s Security Features Chapter 4
Applying the SDO Concept
This chapter is primarily concerned with the mechanisms by which the SDO concept can be applied to the development of SAAs. Rather than describing how the SDO concept might be implemented in a particular object-oriented language, this chapter discusses the SDO philosophy and how it is applied in language independent terms. This chapter is complemented by the following two chapters, which discuss the im- plementation of the ideas introduced in this chapter using the Java programming lan- guage. When the design of a security aware application (SAA) is based on the SDO con- cept, the individual SDO objects that comprise the application are responsible for providing user-centric access control to their protected encapsulated resources. This change represents a significant shift in the way in which application developers view the software objects that comprise a program. Rather than merely acting as containers and dispensers of data, these software objects become actively responsible for the pro- tection of their security sensitive resources. Such an approach has been promoted for many years by Caelli, “The provision of mandatory security services will also form a basis for what may be called “self-defending objects”, a scheme whereby distributed object oriented systems may make intelligent security related decisions about requests made to them from remote and often unknown sites” [96]. When implementing the SDO concept, only those objects which encapsulate pro- tected resources need to be ‘self-defending’, i.e. the vast majority of objects forming the program are not self-defending. This observation has significant practical impli- cations on the usefulness of the SDO concept. The huge object libraries that accom-
87 88 Chapter 4. Applying the SDO Concept pany object-oriented language compilers within current software development envi- ronments (and which are essential for the production of modern applications), do not need to be discarded, nor modified, to allow the adoption of the SDO concept. Security experts argue that SAAs should not be constructed using off-the-shelf compilers and their associated run-time libraries [97] as their security and reliability characteristics are unknown. The stringent standards applied to the development of SAAs imply that any software tools or code whose behavioral and reliability character- istics have not established, or whose continued development is not subject to scrutiny, are unsuitable for SAA development. Open source tools arguably have a significant advantage over their propriety counterparts; their security models and tool implemen- tations are available for inspection. Having the source and system documentation publicly available leverages the benefits of making both the theoretical foundations for, and the implementation of, critical security components subject to the widespread and independent scrutiny of the wider security community. However, even if SAA developers are confident of the suitability of a particular environment, the problem remains that they have no control over the direction of its future development. Having raised these concerns related to the choice of a suitable development en- vironment and indeed, the expertise of application developers to make that choice, this aspect of SAA development will be ignored. The finding of solutions to these problems is well beyond the scope of this research. This research is confined to the evaluation of the SDO concept as a means of improving current application develop- ment paradigm, to better support the development of SAAs. An SDO defends its sensitive resources by requiring identification, authentication and then appropriate authorisation prior to accessing those resources, i.e. SDOs en- force Mandatory Access Control (MAC)1 on their protected resources. In response to a message requesting that an SDO perform a particular service, that request may be acted upon for some users (principals) but not others. The access control provided by SDOs is significantly different to that provided by equivalent access control constructs in an operating system. An SDO provides fine grained access control on application- specific resources, whereas an operating system provides much more coarsely-grained protection which is system wide. Despite these differences, the implementation mech- anisms, such as the use of access control lists or capability structures or profiles, that are employed by trusted operating systems are equally applicable to SDOs. The concentration of the security measures within an SDO parallels the approach
1Mandatory Access Control was discussed in Section 2.5.1. 4.1. A Human Resources Example 89 taken within trusted operating systems in which critical security related functionality is concentrated within the OS security kernel. Such localization of control within a monitor simplifies its implementation and underlies the establishment of trust in its correctness [37]. Similarly, the adoption of the SDO concept not only simplifies the construction of SAAs, but is also expected raise the level of trust in those SAAs. In trusted operating systems, the management of the MAC policy information has proved to be a major problem, due to its complexity and inability to support change [98]. The problem has been overcome to a large extent within trusted operat- ing systems, such as Trusted Solaris2, by providing support for an alternative model, namely role based access control (RBAC) [99]. Similarly, it is anticipated that for most applications, RBAC rather than classic MAC, will be used as the model of choice by SDOs. The ‘Orange Book’ [57] identified the generation of a complete audit trail as a critical aspect of the protection of sensitive resources. That requirement is as impor- tant at the application level as it is at the system level. To ensure all relevant access attempts are logged, access control mechanisms are intimately associated with the au- dit mechanism. Thus, making SDOs responsible for authorisation necessitates their acceptance of responsibility for generating that portion of the audit trail that relates to their protected resources.
4.1 A Human Resources Example
This section will introduce a simplified ‘Human Resources’ scenario, which will be used throughout the remainder of this chapter to highlight aspects of the application of the SDO concept and the implications of its use. In a hypothetical organisation, at least in regard to access control, employees are considered to form a three level hierarchy namely; employees, managers and execu- tives. The information maintained for each type of employee is:
• employee employee number, name, work phone number, position, salary and home phone number
• managers all of above, plus details of their supplied car
2Trusted Solaris is a trusted operating system developed by Sun Microsystems Inc. 90 Chapter 4. Applying the SDO Concept
• executive all of above, plus their performance bonus Employee information is only made available to authorised users of the HR Sys- tem that includes, but is not restricted to, the staff members of the Human Resources Department. As might be expected, since some personnel information is highly sen- sitive, different access rules will apply to different fields of an employee record and those rules will also depend on the employee’s position within the organisational hi- erarchy, e.g. access to executive information is more restricted than access to manager information, etc. (refer to Figure 4.1).
Employee Types RBAC Roles
Most Restricted hrmanager Most privileged Access Executive
Manager hradmin
Least Restricted hruser Access Employee Least privileged
Figure 4.1: A Simple Organisational Hierarchy
Authorised users and staff of the HR department are associated with one or more of the following RBAC roles: hruser, hradmin and hrmanager3. The roles were listed in order of increasing privilege, with each role encompassing the privileges of the preceding role. The role hrmanager has been allocated sufficient privileges to allow all personnel information to be viewed and updated4. In the remainder of the thesis, the term ‘user’ will be used rather than the correct term ‘principal’, that encompasses both users and processes. That decision was made because in relation to the prototype programs, the majority of the access control deci- sions made relate to operations initiated by the current user and the rights evaluated, relate to that user. Hence, the term ‘user’ appeared to be the more appropriate term to use in the context of this thesis. This scenario has been chosen because: (1) it is simple but still allows a wide range of conceptual SDO-based issues to be explored, (2) it includes a simple class 3An additional administration role, creator, is associated with the ability to execute the program. The privileges associated with that role are sufficient to execute the program and initialise its data structures, but do not allow a user acting in that role, to effectively use the program. 4It is recognised that the creation of such a superuser role breaches the ‘principle of least privilege’. However as only a prototype was being developed, the ease of validating the results of access control decisions was considered to be more important than the design of a ‘more realistic’ RBAC hierarchy. 4.1. A Human Resources Example 91 hierarchy so the interplay between SDOs and class hierarchies can be investigated, and (3) it represented the basis for a plausible distributed application in which some users might access the system as a Web service while others would use a more traditional distributed programming model. The scenario also acted as the basis for the distributed prototype that were developed to support this research. That prototype is discussed in depth in Chapter 6.
4.1.1 HR Example - Design Details
Employee information is encapsulated within SDOs that form an inheritance hierar- chy: Executive is a subclass of Manager, which is a subclass of Employee (i.e. an ex- ecutive is a manager, who is an employee). These classes are basically just containers for sensitive information, i.e. personnel records, with no protected functionality being provided by these classes. Being SDO classes however, their accessor and mutator methods that access protected data, enforce access control on that data. Consequently, they perform an authorisation check before performing any sensitive operations.
4.1.1.1 Presenting Data to the User
For both illustrative, debugging and research purposes, each type of GUI object in the developed prototypes: (1) use the same GUI to present information for all three employee types (irrespective of the role of current user), (2) tailor their behaviour to suit the role of the user and the type Employee object being displayed, i.e. if the GUI object knows that a user does not have the right to see a particular field, or the information cannot exist, the GUI object displays a distinguished value in its place, and (3) displays all information actually encapsulated within the SDO5, in the text box at the bottom of the frame. When an accessor method of an Employee SDO is invoked and that read access is disallowed by the security policy, a distinguished value is returned in its place6.Ina real application, the different distinguished values used by the GUI objects, the SDOs, and the value displayed if no data exists, would all be identical, i.e. for textual data, an empty string is likely to be used. Using this approach, the existence of sensitive information that is being withheld from them by the system is hidden from the user.
5That complete information is obtained by making a specifically added research/debug call that bypasses the SDO’s, otherwise complete access control mechanism. 6Discussion relating to why the prototype returns a distinguished value, rather than raising an ex- ception, appears in Section 4.5.2. 92 Chapter 4. Applying the SDO Concept
In contrast, within the prototype, being able to clearly distinguish between these three situations was considered to be essential. The distinguished string value used by the GUI is “****”, while Employee SDOs use the value “!!!!”. If no data is available, the field remains empty.
4.1.1.1.1 Presenting Data - An Example The ‘window capture’ showing the Edit employee details dialog from the prototype is presented in Figure 4.2. That figure shows the view that a user, acting in the role hruser, has of an executive’s information. It is apparent that not all information within the SDO has been made available to that user. In that example, information relating to the executive’s salary and car details have not been made available because a user acting in the role hruser does not have read access to those fields.
Figure 4.2: A hruser view of an executive’s record in the HR Prototype
The debugging information in the bottom panel clearly shows that the salary, car details and performance bonus fields all hold protected data. Both the salary and car details were successfully protected by the GUI object, which displayed its distin- guished value “****” rather than attempt to access the data in the SDO. However, due to a deliberately introduced error in that GUI object, it attempted to retrieve the protected value from the SDO and displayed the result that was returned. The SDO however, detected the security violation and so returned its distinguished value “!!!!”. Thus, provided that independent mechanisms are employed, having both the GUI ob- jects and the Employee SDOs both defending protected data, provides greater security 4.2. Implementing Authorisation 93 than either mechanism alone, i.e. they provide security in depth.
4.2 Implementing Authorisation
This section initially describes the advantages of having SDOs take responsibility for authorisation and then shows that SDOs can control access to their protected resources by performing ‘method authorisation’, i.e. controlling the ability of a user to invoke identified SDO methods7. Finally, the major problem associated with the use of SDO- based authorisation is discussed. The advantages of performing authorisation within actual objects (making them SDOs) rather than distributing the access control measures throughout the application, may be summarised as follows:
1. The structure that is imposed by the SDO approach makes it possible to system- atically apply authorisation measures within an application. By using the SDO approach the inclusion of the relevant authorisation checks within an SAA becomes quite rigorous. If a data member needs to be protected, authorisation is performed within the preamble of each of its accessor methods. Similarly, those methods that perform sensitive functionality also include an au- thorisation preamble. Importantly, the access control measures are applied when the developer is concentrating on the requirements for that object. The system- atic and consistent manner in which authorisation checks are included within the program source indicate that aspect-oriented programming languages, such as AspectJ (see Section 2.9), are likely to play a role in managing the required au- thorisation code being inserted into the SDO methods. In reality, its usefulness was found to be quite low (see Section 6.9).
2. The methods of an SDO provide the ideal location for applying access control measures. Since the methods of the SDO provide the only legitimate means within the ap- plication to access to the SDO’s encapsulated sensitive data, performing authori- sation at those points ensures the checks cannot be bypassed (using mechanisms provided by the SAA).
7Method authorisation (see Section 4.2.3.1), although sufficient to provide required access control, may be supplemented by ‘data authorisation’ (see Section 4.2.3.2). 94 Chapter 4. Applying the SDO Concept
3. The reliability of the application’s access control measures is increased by lo- calising access control measures within the encapsulating object. Over the last two decades, software engineering has experienced an analogous trend toward the localisation of all code that directly accesses data. Current best practice restricts direct access to data, to the object encapsulating that data. The adoption of this policy is widely accepted as being one of the key factors contributing to the increase in reliability of object-oriented programs.
4. The code performing access control is localised within the relevant SDO class file, so code reviews are more effective in identifying any flaws in the access control being enforced. The SDO approach enhances the effectiveness of code reviews. Although it could be argued that code reviews can be ineffective in identifying security violations [97], they remain an invaluable tool for identifying program flaws. The traditional approach in which the authorisation measures are distributed throughout the code of an SAA makes it extremely difficult for the code review to determine whether the authorisation measures taken are both appropriate and complete. In contrast, the localisation of the authorisation measures within the methods of those objects that provide access to the protected resources makes the validation of the authorisation measures relatively straight forward. Such ac- cess control can more readily be related to the real security requirements of any information system by the close proximity to the relevant data and model struc- tures. These gains closely parallel the gains in effectiveness of code reviews following the adoption of the object-oriented programming paradigm.
4.2.1 Authorisation Objects and SDOs
SDOs are expected to delegate the authorisation process to an associated authorisa- tion object. The major benefit of using the SDO approach is the increased separation of application and authorisation logic. The first level of localisation is achieved by moving the authorisation logic from the application as a whole, to SDOs, while a sec- ond level of localisation can be achieved if the SDO encapsulates or uses, a dedicated Authorisation Object (AO) into which the authorisation logic is moved. The extent of authorisation logic that is located within the SDO itself is then reduced to that needed to invoke the appropriate AO service. The advantages of using separate AOs were discussed in Section 2.6.2 of the literature review. 4.2. Implementing Authorisation 95
There are many ways in which an SDO’s AO could be implemented. In this sec- tion, two of these models will be introduced, viz either each SDO has its own internal, and all SDOs share a ‘centralised’ AO. Other models represent different degrees of compromise between these limiting approaches. In the prototypes, the ‘separate AO for each SDO’ model, and a variant of that model, the ‘separate AO for each SDO class’ model, were used.
4.2.1.1 A Separate AO for each SDO
In the first model, each SDO has an AO as one of its data members. That AO is dedicated to its associated SDO so has probably been specifically tailored to that SDO, e.g. the AO only contains authorisation information relating to that particular SDO. In the remainder of this section, the advantages and disadvantages of this approach will be presented.
4.2.1.1.1 Advantages When each SDO is allocated a dedicated AO, two signifi- cant benefits are obtained. Firstly, the AO’s access control policy need only apply to the single SDO. Consequently, during AO instantiation, the relevant access control list can be extracted from the application’s access control matrix. The use of an access control list is likely to result in significant efficiency gains over the use of an access control matrix. Also, as authorisation in SDOs is based on the ability to invoke SDO methods8, and the only operation permitted on a method is execute, the access con- trol list reduces to a list of principal-method pairs, offering the potential for additional efficiency gains. The second advantage of using dedicated AOs is that, when required by the secu- rity policy, the enforcement complex access control rules that require implementation in SDO-specific program logic can be facilitated. Typically an AO will be an in- stantiation of a single ‘authorisation class’ that uses an access control list9 to make authorisation decisions. If more complex authorisation rules apply to particular SDO classes, specialised authorisation classes can be constructed. These specialised AOs will typically extend the basic authorisation class, adding the dedicated program logic needed to support the associated SDO.
8Within the thesis, this process is referred to as ‘method authorisation’ and is discussed in detail in Section 4.2.3.1. 9During instantiation, the AO will be initialised with the relevant access control list for its associated SDO. 96 Chapter 4. Applying the SDO Concept
Importantly, because separate AOs are used, the enhanced access control seman- tics are obtained without increasing the complexity of the SDO code.
4.2.1.1.2 Disadvantages The major disadvantage of this approach is the additional memory requirements. Since each SDO has a separate AO, additional memory is allocated for each AO. Depending on the size of the access control lists and the number of AOs required, such additional memory requirements could be very significant10. The other major disadvantage applies to distributed applications. In the context of currently popular object-oriented languages, ‘distributed’ means that the application is distributed across multiple virtual machines, in addition to its normal meaning of being spread across multiple physical or real machines. The requirement to transfer the authorisation object, in addition to the SDO itself, will incur a performance penalty. The penalty is especially significant if the amount of authorisation information greatly exceeds the SDO’s information content11. That penalty is even larger if those virtual machines are hosted on different phys- ical machines. Then, the communications overhead, i.e. the transmission time and network bandwidth, become significant. The additional penalty incurred in the re- mote case, can be alleviated if sufficient trust exists within the distributed system. Provided that the destination can be trusted to provide valid and up to date authorisa- tion information for inclusion within SDOs sent to that site, the expense of sending authorisation information can be avoided.
4.2.1.2 SDOs Share a Single Authorisation Object
In this model, all SDOs within the program share the same AO. The sharing of AOs between SDOs has the advantages of simplifying the propagation of security policy updates12 and reducing memory usage. However, the huge number of authorisation requests originating from an SDO based application suggests that it is unlikely that SDOs can rely on a shared authorisation object that is located outside the virtual ma- chine13. It should be noted that in many cases the need to make such a large number
10Since code will be shared between all objects of the same class, having additional AOs does not change the memory for code storage (see Section 3.3.2.3). 11The difference arises because passing an SDO to a method in the same virtual machine only re- quired the passing of a reference, while passing the object between virtual machines will involve seri- alisation of the object, its transfer and finally its deserialisation within the destination virtual machine. 12The propagation of security policy updates is considered in Section 4.2.2. 13Making a ‘local’ authorisation call rather than a call between virtual machines (that potentially could require a remote access), will add to the cost of making that call. Although the difference in 4.2. Implementing Authorisation 97 of authorisation requests does not arise as a result of the adoption of the SDO concept. The authorisation requirements flow directly from the requirements of the security policy. The additional authorisation load may be incurred, if the SDO is part of an SDO inheritance hierarchy, is described in Section 4.4.1.1. Provided that all authorisation decisions are decidable using access control ma- trix14 lookups, a single AO could be shared by all SDOs within the same virtual ma- chine. However, this approach becomes less favourable if several SDOs require com- plex authorisation logic. Then, the need to support multiple authorisation mechanisms will add to the complexity of the authorisation object resulting in a corresponding de- crease in both its reliability and performance.
4.2.2 Propagating Policy Updates
One of the first tasks performed by an SAA is to load its security policy from persistent store, e.g. a database, into a ‘policy object’. That policy object will then act as the policy source for all the SDOs executing in that virtual machine. However, during the lifetime of that application, updates might be made to the security policy, so support for the propagation of these policy changes to the relevant SDOs is required. For applications in which each SDO has a separate dedicated AO, the propagation of policy updates occurs as three steps15: the propagation of updates between com- puters, the propagation of updates from the depository on the host computer to the application’s policy object, and finally from the policy object to the individual AOs. The first two stages are considered to be beyond the scope of this thesis. The adoption of the SDO concept does not impact those stages, so the mechanisms currently being used by SAA developers will continue to be used. However the propagation of pol- icy updates to individual AOs does not currently occur in SAAs, so that topic will be discussed and a potential implementation suggested.
4.2.2.1 Propagation of Policy Updates to Authorisation Objects
Depending on the lifetime of SDOs within a program, the propagation of policy up- dates to them may, or may not, be required. In the following subsections, both possi- bilities will be discussed. execution time for each call may not be large in absolute terms, the number of calls is potentially large, so any increase in authorisation efficiency becomes significant. 14Access control matrices are introduced in Section 4.2.3. 15If a centralised AO is being used, only the first two stages will apply. 98 Chapter 4. Applying the SDO Concept
4.2.2.1.1 No Policy Propagation If an SDO’s lifetime is short16, it is acceptable for the security policy that was current when the SDO and AO were instantiated, to be enforced. The lifetime of an SDO is considered to have expired when either: (1) the SDO is no longer required by the application (technically the SDO is no longer reach- able) so the object will be automatically garbage collected by the system runtime, or (2) the maximum lifetime specified when the SDO was instantiated has expired. In the latter case the SDO must take responsibility for its own destruction (see Section 4.4.2). It is unlikely that all of the SDOs in a program will be short-lived, unless the program itself is short-lived. For example, a client process may only be permitted to remain connected to the server for a short period of time, so policy propagation is unnecessary. For the majority of programs however, at least some AOs will be sufficiently long- lived, that support for the propagation of policy updates is required.
4.2.2.1.2 Propagating Security Policy Updates On receiving a policy update, the application’s policy object is responsible for propagating that update to the relevant AOs. One way to implement this requirement is to have the policy object to maintain lists of AOs for which policy updates are to be dispatched. That might be all AOs that have been instantiated, or possibly only certain AOs associated with long-lived SDOs. The particular list onto which an AO is placed, is determined by the subset of the application’s security policy which it enforces, and so what updates it must receive. A complicating factor is that even after a short period of time has elapsed, many of the AOs held on these lists will no longer have SDOs that rely on their services. This may occur because many SDOs are very short-lived, e.g. they might only be used to convey information between a datastore and a user, so they will no longer required, and will be discarded, after that protected information has been transferred. Logically, these AOs should be subject to garbage collection. However, since they are still on one of the policy object’s lists, they remain reachable (i.e. still in use), so are not subject to garbage collection. The policy object has no way of determining whether they are no longer required, so cannot remove them. Both Java and the .Net family of languages, provide a mechanism to overcome this problem, namely weak references. A weak reference is an object that does not prevent the object that it references from being reclaimed. “Suppose the garbage collector
16In this context, the term ‘short’ relates to a period of time during which the security policy is unlikely to change. 4.2. Implementing Authorisation 99 determines at a certain point in time that an object is weakly reachable17. At that time it will atomically clear all weak references to that object.” [90] Once a weak reference is cleared, the object is no longer considered to be in use. If the AOs are ‘weakly referenced’ from the policy object’s lists, when the policy object needs to send out updates, it can query each weak reference object to determine whether its associated AO still exists. If the AO still exists, it is sent the relevant policy update. If not, the weak reference object is removed from its lists.
4.2.3 Controlling Access
An SDO is like any other software object within the SAA, in that it provides func- tionality associated with its encapsulated data. SDOs differ however, in that they encapsulate resources that require protection from unauthorised access and they take action to provide that protection. As both data and functionality require protection by SDOs, it might be expected that authorisation service that an AO provides, would be based on the use of an access control matrix. An access control matrix is a “table in which each row represents a subject, each column represents an object and each entry is the set of access rights for that subject to that object” [37]. In the SDO environment, ‘subjects’ are likely to users, ‘objects’ are either SDO methods or data members, while the ‘access rights’ are either ‘execute’ for SDO methods, or ‘read’ and/or ‘write’ for data members. Thus, an access control list can be used to determine whether the current user is permitted to invoke the specified method, or access a protected data member in the requested manner. The protection of SDO’s sensitive resources can be achieved by controlling access to the methods of the SDO which access those resources, referred to as in this thesis as ‘method authorisation’; potentially supplemented by ‘data authorisation’, the con- trolling of access to the data members themselves. Inherent in the previous statement is the realisation that data authorisation alone cannot provide the required protection. After all, functionality as well as data requires protection by SDOs.
4.2.3.1 Method Authorisation
Good software engineering practice dictates that direct access to data from outside the encapsulating object should not be permitted. Data should only be accessed indirectly
17“An object is weakly reachable if it is neither strongly nor softly reachable but can be reached by traversing a weak reference.” [90] 100 Chapter 4. Applying the SDO Concept through methods. As best practice should be adopted by SAA developers, all access to protected resources should be via methods. Since access to methods will be used to protect both functionality and data, the access control matrix can be simplified as only one type of operation will be present, namely execute. The access control matrix reduces to a table of boolean values, i.e. for each user — method combination, access is either permitted or not. Complete mediation can be exercised by restricting access to those non-private methods18 of an SDO that provide access to protected resources. That mediation is achieved by inserting a preamble into all such methods, that initiates an authorisation check to determine whether the current user has the right to invoke that method, and if appropriate, logs that attempted access in the application’s audit log. To provide complete mediation of an SDO’s protected resources, the following categories of SDO methods are likely to require such authorisation preambles:
• methods providing protected functionality (that is unrelated to protected data). These methods provide protected functionality, so access to these methods needs to be restricted. An example of protected functionality, in a Human Resources context, is the transfer of moneys to the bank accounts of all employees.
• accessor and mutator methods19. Accessor and mutator methods enable the individual protected data members of the SDO to be accessed, so controlling access to these methods is essential.
• methods that modify multiple related data members. Such methods will typically enable the manipulation of ‘abstract objects’20,so are logically equivalent to mutator methods, and so also require protection.
• methods modifying multiple unrelated data members. Such methods are usually only used for convenience as equivalent semantics can be achieved through the use of multiple mutator invocations. The implementa- tion of such methods must allow for the possibility of authorisation failures for
18Non-private methods are those methods of a class that can be directly invoked by code outside the class. 19Technically, an ‘accessor’ is a zero parameter method of a class that returns its associated data member (i.e. data field). On the other hand, a ‘mutator’ is a single parameter method that overwrites the current value of the associated data member with the method parameter. By convention, accessors have names beginning with ‘get’ followed by the name of the data member, while mutators begin with ‘set’ followed by the data member name. 20Consider a list object that modifies an abstract unsorted list. It will have an insert operation which modifies a number of related data members, in order to add the element. 4.2. Implementing Authorisation 101
some updates but not others. Thus to achieve normal method call semantics (i.e. all changes made, or no changes made and an exception raised), the possession of all of the required permissions needs to be established before the update is commenced. Such semantics require the use of authorisation queries21 within the method preamble or elsewhere.
• the SDO constructors. Having the ability to instantiate a particular SDO, even though they are unable to invoke any of its methods, can provide an attacker with the opportunity to launch an attack on the system. They might, for example instantiate more objects of that type than the application can reasonably handle, and so either cause an error or a denial of service.
Thus, complete mediation of an SDO’s protected resources can be achieved by controlling access to selected methods of the object. That control is exercised through the inclusion of an authorisation preamble within those methods. Details of the im- plementation of method authorisation in Java are provided in Section 5.3.3.2.
4.2.3.2 Data Authorisation
Data authorisation is the complementary approach to providing protection to an SDO protected information resources. Essentially, for each of the SDO’s protected data members, the data authorisation policy specifies which operations can be performed for each user role. For simple data members such as numbers, strings and boolean val- ues, those operations are confined to ‘read’ and ‘write’, but for more complex objects, the operations will vary depending on the type of object. To control access to protected functionality, the corresponding method could be treated in a similar manner to a data member, but would be associated with the operation ‘execute’. The need to handle a wide range of potential operations associated with each subject — object combina- tion, although not complicating the logical operation of the access control mechanism, impacts not only on the complexity of its implementation, but more importantly on the complexity of the access control policy and the handling the complexity of the policy semantics within the SDO implementation. The other inherent problem with the generalised use of data authorisation, is that the authorisation mechanism does not reflect program behaviour. Program behaviour,
21Authorisation queries (see Section 4.2.4) are a way to determine whether a method can be invoked without that the permission check being added to the application log. 102 Chapter 4. Applying the SDO Concept especially within object-oriented programs, is based on performing operations on the manifestations of real-life ‘objects’. A very large proportion of such operations that objects provide, involve the modification of multiple related data members. Due to the complexity of basing SDO authorisation requirements on data autho- risation, the author submits that method authorisation should be used. Although not recommended, as it would require that sections of the security policy be expressed in two forms, data authorisation could be used to supplement method authorisation. An example of a possible use of data authorisation is discussed in Section 4.5.1.
4.2.4 Potential Problems with SDO-based Authorisation
A problem with the SDO approach is that the unnecessary authorisations are per- formed, as ‘the system’ moves protected information from one SDO to another. If the SDO concept was not being applied, the object performing the data transfer would have the necessary context information to decide whether authorisation needed to be performed. Of course, making the wrong decision would enable the leakage of sensi- tive information. Conversely, an SDO has no idea of why protected information is being accessed. When an access is requested on behalf of a user/principal, that access will always be mediated and logged. Consequently, more authorisation checks are performed than might be strictly necessary. Importantly, every sensitive access is guaranteed to be mediated. Some reduction in the number of authorisation events being logged can be achieved by not having the SDO make unnecessary data accesses. Although that statement is self-evident, it has some practical consequences. The use of ‘authorisation checks’ alone may require certain data accesses to be performed whose only purpose is to de- termine whether that data access is permitted. To cater for those situations, extending the services provided by the SDO to include a determination of whether an access would be permitted, will avoid the need to make unnecessary data accessed. The pro- vision of such services will not necessarily undermine the protection provided, as the data is not actually being released. Consequently, logging of those method invocations could be considered unnecessary22. Attempts to bypass the completeness of the protection afforded by the SDO para- digm, by other mechanisms are likely to result in the loss of integrity of the security
22In a high security context, it might be considered unreasonable not to log these events. Their omission from the audit trail might mask the occurrence of probing attacks. 4.3. Provision of a Complete Audit Trail 103 measures being provided. Two apparently secure ways of reducing number of autho- risations performed, or recorded in the audit trail, are:
• SDOs provide alternative access methods for ‘system use’ These methods do not perform authorisation before performing the requested access, i.e. the SDO effectively reverts back to a normal object when used for ‘system’ purposes. Protection of those methods could be provided by the pack- age protection mechanisms enforced by the virtual machine in which the ap- plication resides23. These protection mechanisms are currently considered to be effective in preventing any class that does not belong to that package from accessing those methods. However, any class that claims to belong to that pack- age, and is loaded by the appropriate class loader, e.g. the class is located in an appropriate directory, will be granted access (see Section 3.3.2.2 for details).
• Use a special system role for system use to avoid unnecessary logging Using a privileged role, not available to users24, is an effective mechanism for performing special tasks, that might include accessing a protected resources without the event being logged. However, should the required authorisation be forged, the consequences to the protection provided by application would be catastrophic. Not only would an attacker be able to access protected resources, provided that only the appropriate resources were accessed, no record would exist of the use of that credential.
The discussion of authorisation queries and whether they should be supported will be deferred to Section 5.3.3.2 of the next chapter.
4.3 Provision of a Complete Audit Trail
Apart from the provision of mandatory access control, the other major aspect of secu- rity that needs to be provided, at both the system or application level within a secure computer system, is the provision of a complete and secure audit trail. The US De- partment of Defence in the ‘Orange Book’ [57], describe the provision of an audit trail
23This requirement is met by the two major object-oriented development environments, Java and .Net. 24If the role were to be available to users, both the probability of compromise would be increased, and the security of the systems would depend on the trustworthiness of that administrator. With their ability to perform sensitive tasks, without the possibility of detection, no security guarantees relating to those tasks exist. 104 Chapter 4. Applying the SDO Concept as being an essential requirement for any secure computer system (even those that aim at being certified as being moderately secure). A critical requirement of any operating system is the ability to adequately protect the system, and application specific, audit trails. The key tenet of the SDO concept is that SDOs accept responsibility for defending their encapsulated protected resources by ensuring that authorisation always precedes a protected resource access. Security practice dictates that authorisation and the log- ging of those authorisation events, are intimately associated, to ensure the complete- ness of the audit trail. Consequently, SDOs must also accept responsibility for the logging of those authorisation events that relate to their protected resources.
4.3.1 Audit Log Overview
Within an SDO environment, the audit trail would be a collection of SDOs, within a specialised program that is only made available for use by auditors and security administrators. Each of these SDOs exploit their specialised knowledge of their log to provide their users with the means to efficiently view and search the content of that log. Being SDOs, they restrict access to each of those individual services to those authenticated users authorised to use the service. However to the applications, and system software, that run on that computer sys- tem, the audit log is manifested as an object, which only supports the appending of an audit record to the relevant audit trail. The ‘audit log’ object that is instantiated within an application is unlikely to be an SDO, because the append operation is safe25 and the appending records to the log will be initiated by the application processes, rather than a user. In line with security best practice, a separate audit policy is developed as an essen- tial component of the application’s security policy. If required by the application’s au- dit policy, the SDO must ensure that immediately following authorisation, and before access is granted, details of any attempted access to a protected resource are logged. The inter-dependence of these security functions is reflected in the requirement that the inability to log the authorisation event will necessarily result in an authorisation
25The only attack that could be mounted against the log, or the application itself via the log, is a denial of service. By flooding the log object with log requests, the log’s ability to handle legitimate requests would be reduced resulting in authorisation delays or even the depletion of the log’s storage. Naturally if the ‘log file’ is not adequately secured by the execution environment, false entries could be entered into the log, but such activities are beyond the control of the application. 4.3. Provision of a Complete Audit Trail 105 failure26.
4.3.2 SDOs and the Audit Log
Reflecting the need for SDOs to fulfill the application’s audit requirements, the autho- rization token passed to an SDO must supply sufficient information to support both the authorisation and audit processes. Consequently, the unique identity of the user, an essential component of an audit record, must be included within the authorisation token, even though it is unlikely to play a part in the authorization process27. Just as the SDOs delegate responsibility for authorisation to a separate authorisa- tion object, responsibility for the generation of the audit log is delegated to an audit log object. The interaction which occurs between an SDO, its authorisation object and the audit log object is presented in Figure 4.3. As shown, the making an authorisation decision by an SDO involves four steps:
1. The SDO sends a message to its associated AO requesting an authorisation de- cision.
2. That AO makes the authorisation decision based on the application’s security policy. A message is sent to the audit log object requesting that authorisation decision be logged.
3. The audit log object refers to the audit policy to determine whether that partic- ular event should be logged. If logging is required, it attempts to log the event, raising an exception in the event of failure.
4. The authorisation decision is returned to the SDO. If the logging of the decision failed, the authorisation decision returned to the SDO is failure.
The SDO then enforces that decision, by either performing the requested opera- tion or rejecting the request. The mechanism described will ensure that whenever an SDO’s protected resource is accessed, the request is authorised, and if required by the application’s audit policy, the authorisation event has been successfully logged, before an access is allowed. 26Exceptions to this general rule apply for both safety or mission critical software, where the need for reliability overshadows their security requirements. 27Mandatory access control in SDO-based programs is expected to be based on the RBAC model. 106 Chapter 4. Applying the SDO Concept
Security Audit Policy Policy
2 Authorisation Audit Log Object Object 3
4 1
SDO
Figure 4.3: Interaction with Audit Log
4.3.3 Problems with Auditing SDO-based Systems
Within traditional applications which have a single (logical) thread of control, the provision of access control is relatively simple. Access to a particular resource can be authorised at one point within the program (and the relevant audit data recorded), and the completeness of the coverage is known to be complete. The inherent asynchronous nature of object-oriented programs in the context of this research, complicates the provision of effective access control and the corresponding generation of a complete audit trail. In an SDO-based SAA, whenever a protected resource is accessed, the SDO will perform an authorisation check before the access is permitted. Thus, the SDO paradigm ensures that a protected resource can only be accessed (from within the program itself) following authorisation, and that the access attempt will be appropriately logged. A major problem is the number of audit records generated. All events in which an SDO’s protected resource is accessed, irrespective of whether they reflect the direct intention of the user or occur as a result of the peculiarities of the system, are logged28. The problem of generating a usable audit trail, in SDO-based programs and object- oriented programs in general, has no obvious solution. No solution to this problem was located in the literature and no attempt to solve this problem was undertaken by the candidate, as that problem was outside the scope of the research.
28For example, when the system copies protected information from one SDO to another, both a read from SDO and a write to the other, will be recorded within the audit trail. 4.4. Characteristics of SDO Classes 107
4.4 Characteristics of SDO Classes
The behaviour of an SDO is essentially the same as the other objects in an object- oriented program, except in one respect, an SDO accepts responsibility for protecting its encapsulated resources from unauthorised access. When a method is invoked, the SDO will either fulfil that request, or raise an exception (and not perform that opera- tion). In this respect, its behaviour is identical to its non-SDO counterparts. However if that method accesses a protected resource, the method may fail to perform the re- quested operation for an additional reason, an authorisation failure. Consequently, an SDO method will often declare that it throws an (additional) exception, which signifies that the requested operation could not be performed due to an authorisation failure. The provision of such behaviour is reliant upon the presence of an additional pa- rameter for each protected method, a developer-defined authorisation token29. To pro- vide consistency across SDOs, the convention of passing the authorisation token as the first method parameter is recommended. This section continues by discussing other effects that the adoption of the SDO concept, has on the construction of SDO classes.
4.4.1 Implementing SDO Inheritance Hierarchies
As outlined in Section 4.2.3, good programming practice dictates that no direct access to data should be permitted from outside the object. It is generally accepted however, that making data members directly accessible to subclasses, is acceptable. Thus, in most programs the data members of a class are generally only directly accessible from within the defining class and its subclasses. Gong [91] recommends that for security reasons, this restriction be tightened mak- ing data members are only directly accessible by the methods of the encapsulating class. If that practice is not adopted, Gong warns that subclassing provides a means by which rogue code can be constructed that has direct access to an object’s, otherwise protected data. To avoid this identified security problem, Gong’s recommendation must be adopted as ‘best practice’ by all software engineers responsible for the construction of SAAs.
29The need to add the additional parameter and authorisation preamble to the relevant SDO methods is both repetitive and error prone. An attempt was made to use AspectJ to automatically generate the required code but that approach was found to be ineffective (refer to Section 6.9). Unfortunately there was insufficient time to explore the alternative approachs such as providing a software tool similar to the CORBA IDL compiler, to perform that task. 108 Chapter 4. Applying the SDO Concept
Consequently, it will be assumed that all data members within an SDO that contain protected information will be declared as having the access specifier private. The adoption of Gong’s policy impacts on inheritance hierarchies of normal classes and in particular, SDOs. When the data members of superclasses are no longer visi- ble, subclasses like all other classes, must use the accessor methods of the superclass to gain access to its data, rather than accessing them directly. The main implications to SDOs are: additional authorisation checks may be required (when compared to those required in an non-SDO based SAA), and the use of cryptographic techniques is made more complicated. The effects on authorisation will be discussed next, while the effects on the application of cryptographic techniques is discussed in Section 4.7.2.3.
4.4.1.1 More Authorisation Checks May be Required
The key strength of inheritance in object-oriented languages is that the functionality of the superclass is inherited by the subclass. A subclass can override (replace) inherited methods to tailor the functionality provided to the subclass. Unfortunately, there is an impact on the number of authorisation checks that need to be performed when inheritance hierarchies and private data members are used in conjunction with the SDO concept. Within a hierarchy of SDO classes, more privileges may be required to invoke the over-riding method in the subclass. In terms of its implementation, the subclass method will perform the relevant authorisation check and then invoke the overrid- den method in its superclass. Such a requirement will potentially cause authorisation checks to cascade as the call is propagated up the inheritance chain. Consider the HR example introduced in Section 4.1. As stated in that section, the more privileges are required to gain access to the salary information of a staff member is higher up the corporate hierarchy. As different authorisation requirements apply to the salary information for both managers and executives, the getSalary method in these classes will be overridden to enable the enforcement of the relevant provisions of the security policy. The salary field is declared as being private within the Employee class and so that can only be directly accessed from within that class. To determine an executive’s salary, the getSalary method is invoked on the appropriate Executive object. Figure 4.4 shows the propagation of that getSalary call through the Employee class hierarchy. An authorisation check is performed in the Executive.getSalary method to ensure that the user is authorised to access executive salary information. Since the salary 4.4. Characteristics of SDO Classes 109
Employee Manager Executive
getSalary getSalary getSalary getSalary() checkAuthorisation checkAuthorisation checkAuthorisation return salary() return super.getSalary() return super.getSalary()
Figure 4.4: The propagation of an (Executive.) getSalary call data can not be directly accessed, the overridden superclass method is invoked. The superclass method (in Manager.getSalary) performs another (unnecessary) authorisa- tion check30 before invoking its superclass method. Finally, the Employee object is reached where, after performing yet another authorisation check, the salary can finally be accessed and returned. The salary information will propagate back up the call chain to the original caller. If SDOs were not being used, the need for multiple authorisation checks would not be required. The right to access executive salary information would be checked externally, and then the salary information would be requested from the Executive ob- ject but instead Employee.getSalary would be automatically invoked31. There would be only a single authorisation check performed externally and there would be no prop- agation of the getSalary call to up the call chain. Thus, unnecessary authorisation checking is performed as a result of the adoption of the SDO paradigm. This represents the worst case scenario. This problem only occurs if the access requirements in the subclass are different to those in the super- class. Consider instead, accessing an executive’s name. Since the same authorisation requirements apply throughout the inheritance hierarchy, the getName method is not overridden in the superclasses of Employee. Consequently, only the single authori- sation check is performed. The behaviour is the same as if non-SDO classes were used. In general, an authorisation check must be performed in the class in which the operation is actually performed and in any class in which additional access rights are required. Since there must always be an authorisation check performed before
30If the Executive object was provided with a means to avoid having to perform the Manager’s authorisation check, that same mechanism would be available to other subclasses, including malicious subclasses. 31This behaviour is based on the following assumption. In the SDO hierarchy, the getSalary method had only overridden in the superclasses to ensure the appropriate authorisation checks were performed. Consequently, in the non-SDO class hierarchy, that method would not need to be overridden. 110 Chapter 4. Applying the SDO Concept a protected resource is accessed, the performance penalty32 associated with the use of SDOs is only incurred each time there is a change in the rights associated with a method invocation.
4.4.2 Maximum Lifetimes for SDOs
SDOs, like all objects in a program, are instantiated when they are required. Once an SDO is created, there is no way for it, or any other object, to be explicitly destroyed. However, automatic garbage collection is performed in modern object oriented pro- gramming languages. Once an object is no longer referenced from within the program, the object is subject to garbage collection. Consequently, an object will cease to exist a non-deterministic amount of time after it is no longer required by the program. The corollary is, an object will remain in existence for as long as a valid reference to that object exists. This situation is undesirable for an SDO, which encapsulates sensitive resources, and which might be located within a hostile or insecure environment. A highly desirable feature for SAAs would be the ability to specify a maximum lifetime for an object, particularly an SDO, when the object is instantiated. Then, both the SDO, and more importantly its protected resources, would be destroyed at a time of the SDO creator’s choosing, reducing the likelihood of the resources being compromised. A related benefit is that neither information nor the security policy would become outdated before the SDO is destroyed. Unfortunately, there is no support for the concept of a maximum lifetime for ob- jects and it is unlikely that such a support will ever be provided due to its limited applicability. Much more importantly, its introduction would at best, contribute sig- nificantly to the complexity of programs as disappearance of objects at any instant, would need to be handled. At worst, the situation cannot be handled. The situation would be analogous to race conditions on shared variables between threads (or pro- cesses), that can only be solved through the use of atomic check and set machine instructions. The next section discusses a mechanism by which an SDOs protected content could be destroyed, without destroying the object. The requirement to restrict object lifetime is met, but without the associated problems.
32The size of the performance penalty is of course, application dependent. It is dependent upon the complexity of authorisation algorithm, the amount of authorisation information that must be searched, and other costs involved in making the authorisation request. 4.4. Characteristics of SDO Classes 111
4.4.2.1 Implementing SDO Lifetimes
The desired lifetime semantics can be approximated by making the object/ SDO re- sponsible for determining whether its lifetime has expired, and if required ‘destroying’ its protected content. There are several aspects of this situation that require consid- eration. How is the lifetime of an object to be specified? How does the object know when its lifetime has expired? How can an object destroy its sensitive content?
4.4.2.1.1 Expressing SDO Lifetimes The concept of lifetime is already being used in many areas including digital rights management, where a customer obtains specified rights to a work for a defined period. That period is likely to fall into three broad categories: usage is permitted for the lifetime of the media; for a specific period of time, e.g. a day; or some predefined number of uses, e.g. a single playing of the work. The first digital rights management case corresponds to the current situation in an object-oriented program, where objects remain available for as long as they are re- quired. The later two possibilities could be applicable within the SDO context. Thus, depending on application requirements, it could be optional for the creator of an SDO or other object, to specify its lifetime (using either of these methods), when the SDO is instantiated. One approach by which specified lifetimes could be implemented would involve a ‘still alive’ flag within the SDO, that identifies whether the SDOs lifetime has expired. While still alive, the SDO will verify its liveness before performing any requested operation. If it determines that its lifetime has expired, the sensitive resources are removed, and the SDO marked as being no longer alive. However, determining whether the SDO should be still alive, can be problematic. Firstly, an SDO can only determine whether it is still alive when one of the object’s methods are invoked. Only then is the object executing and so is able to take some ac- tion. Secondly, a lifetime based on a period of time is simple to implement on a single machine, but becomes problematic in a distributed environment when SDOs are short- lived, unless synchronised clocks are available. Providing a specified number of reads of its encapsulated content is easy, if only one piece of information is held within the SDO, but it becomes more difficult when more data items are encapsulated. However, a satisfactory approach must exist for a particular SDO in a particular application, otherwise that mechanism would not be considered. 112 Chapter 4. Applying the SDO Concept
4.4.2.1.2 Removing an SDO’s Encapsulated Resources An SDO, like any other object in an object-oriented program is unable to destroy itself, but its encapsulated sensitive resources can be destroyed. Although sensitive functionality cannot be re- moved from an SDO, after its lifetime has expired an SDO can behave differently when requested to perform sensitive functionality. An object can however ‘overwrite’ its protected data members and so protect that sensitive data from disclosure. For primitive types, the data can be overwritten. For object data, setting object references to null is sufficient. Although the data objects will continue to exist for some non-deterministic period of time after becoming un- reachable, that data is no longer accessible from the SDO. Thus the SDO, and therefore any part of the application, is unable to divulge that content. Within the virtual machine, although the memory reclaimed from objects is avail- able for reuse, programming language semantics guarantee that the memory will be initialised before use. The protection measures of the virtual machine are supple- mented and supported by the process isolation mechanisms of the underlying operat- ing system. Thus, the memory used by the virtual machine is protected from other processes, both while the virtual machine is executing and after it terminates. Thus, dereferencing a data object effectively destroys it.
A Non-effective Means of Destroying Protected Data If the protection pro- vided by the operating system or virtual machine, is believed to be insufficiently trust- worthy, SDOs could actively attempt to destroy all protected data which exists in their internal objects. If protected data is encapsulated within application specific objects, the functionality of those objects could be extended, enabling those objects to over- write their data content. From a programmer’s perspective, all data will eventually be reduced to either a primitive type, e.g. a numeric type, or textual data, i.e. a String. As already noted, primitive types can be overwritten, destroying their sensitive values. Strings however are immutable. In Java, an SDO could store all textual data in StringBuffer objects rather than String objects. Following this change, textual data can also be overwritten. Then SDOs can overwrite all of their protected data once their prescribed lifetime has ended. The classes provided by Java API use Strings, rather than StringBuffers, for pa- rameter passing, and textual information is stored internally as Strings. Taking this into account, a performance penalty and increase in code complexity, will be incurred as result of adopting this approach. Whenever textual data moves into and out of 4.4. Characteristics of SDO Classes 113 an SDO, that textual data will require conversion between its String and StringBuffer representations. At one stage, it was believed that such a mechanism would provide a significant improvement in the protection provided by SDOs, to justify the penalties incurred. Hence, that mechanism was implemented in an early version of the HR System pro- totype. However upon reflection, the benefits gained are likely to be less significant than originally anticipated. The far simpler approach of setting object references to null, will only become ineffective if the process separation provided by the operating system is incomplete. Then an attacker could gain access to the memory of the virtual machine, and po- tentially obtain the sensitive information. Using the (StringBuffer) approach being discussed, when the SDO’s lifetime expired, both protected textual and other informa- tion within the SDO, will have been overwritten and so cannot be extracted from the SDO. Apparently, the protection is complete. Unfortunately, the protected information can be obtained from elsewhere within the virtual machine. As already noted, the objects of the Java API (and probably many of those in the application) use Strings. Should an attacker be able to read the memory of the virtual machine, despite the SDO having removed all trace of protected information that it encapsulated, that same information is likely to exist in other parts of the virtual machine33, remnants of its transfer between the SDO and the GUI object which presented the data to the user, would remain. Thus, the performance penalty and increase in code complexity provides no significant increase in security34. Also from a practical viewpoint, surely if an attacker has the ability to gain access to the memory of a process, they would not bother attacking the application’s virtual machine. Surely, the database management system, or the database itself, where more or all of the sensitive data resides, would be a more attractive target.
4.4.2.2 The Value of Using SDO Lifetimes
The use of defined lifetimes for SDOs is believed to significantly enhance the value of the SDO paradigm. Restricting the lifetime of SDOs will help to ensure that only current protected information is made available to users and that that release is in
33If the data no longer exists within the virtual machine, because the objects containing the sensitive data have been garbage collected and reused, it is also likely that the corresponding objects that would have been dereferenced within the SDO, would also have been reused. 34The use of encryption also provides little additional protection from such attacks. If that data had been accessed recently, it is likely to still exist in plain text somewhere in the virtual machine’s memory. 114 Chapter 4. Applying the SDO Concept accordance with the application’s current security policy. Having SDOs overwrite their protected textual data once their lifetime has expired appears to be of limited benefit. Dereferencing internal objects containing protected information appears to be just as effective and is far simpler to implement.
4.5 Using SDOs
In an SDO-based application, when sensitive information is requested by an authorised user, the objects used to return this information should be SDOs. The advantage of returning SDOs is that access control continues to be enforced until the information is finally received by an authorised user. Typically, this will be in the form of a display on a computer screen. If SDOs are not used, such continued enforcement of the security policy require- ments is likely to be impossible. Once protected information leaves its source, at the request of an authorised user, the data is assumed to have been delivered to that user. Access control is no longer applied, so an error in many parts of the program could result in the unauthorised disclosure of that information. The remainder of this section is devoted to: (1) demonstrating that the SDO con- cept can be applied to common situations that arise during software development, and (2) to identify any peculiarities that arise from the use of SDOs. Although the discus- sion will include particular examples to identify the issues involved, those examples are kept as general as possible, so that any observations made will be generally appli- cable.
4.5.1 Authorising Access to an SDO’s Protected Content
As discussed in Section 4.2.3, access to an SDO’s protected resources is controlled by restricting its methods. Although the SDO is responsible for initiating the access control request, its associated authorisation object (AO) is responsible for performing the authorisation check. When determining the right of a user to invoke an SDO’s protected method, the AO is likely to perform a access control list lookup35. In some circumstances, a single authorisation check is insufficient to permit an authorisation decision of sufficiently fine granularity, to be made. Consider the HR
35An attempt is made to find the combination of the user’s role and SDO method being invoked, in the AO’s list of allowed role—method pairs 4.5. Using SDOs 115 scenario and the organisation’s personnel records. Logically at least, the information is held as a collection of Employee objects36. One of the operations that can be performed on the collection is the insert oper- ation. Authorisation for an insert method that only takes into account the role of the user, is unlikely to be sufficient to provide the fine-grained protection required in this case. The security policy is likely to dictate that different permissions will be required to add personnel records for different kinds of employees. A user acting in a particular role might be able to insert an Employee object into the personnel collection, but is not permitted to add an Executive object. Authorisation in this and analogous situations, can be performed in at least two ways: program logic can be used to make a secondary authorisation decision based on the type of object being inserted, or a different type lookup could be performed, one that uses of an access control matrix. In this particular access control matrix, the entry associated with each method-role combination, is a list of permitted Employee classes to which the operation can be performed. The increase in complexity of the authorisation process has no effect on the com- plexity of the SDO itself. The separation of the SDO’s core functionality, from the separate but vital authorisation task, has avoided the introduction of that complex- ity. The making of the authorisation decision, irrespective of its complexity, is the responsibility of the SDO’s AO. The SDO’s authorisation preamble merely makes the appropriate call to its associated AO. Those authorisation objects are instantiations of a small number (possibly one) of authorisation classes that perform authorisation in the different ways required by the program.
4.5.2 Accessing Protected Resources
This section is concerned with how an SDO should react when an authorisation check fails. One approach would be to raise an exception. That approach is generally applica- ble as it can be used irrespective of the type of the method return value, including void (no return value). The type of exception raised identifies the cause of the exception and specific details can be returned as a message encapsulated within the exception object. From experience gained from the use of SDOs, this mechanism tends to be used on most occasions. 36As a point of interest, both the record collection and the individual personnel records in the collec- tion, would be SDOs. 116 Chapter 4. Applying the SDO Concept
The alternative approach is to return a value which indicates that the operation could not be performed. The main deficiency of this approach is that the cause of the failure cannot be indicated. There is one situation when this appears to be the most useful mechanism to use. When an accessor method of an SDO is invoked, it is often easier to return a special return value, rather than raise an exception, especially if that information is likely to be presented to the user. The accessor method will only fail if there is no value available, or the user is not permitted to receive that data. In an SAA, the user should not be made aware of which situation applied. Consequently, the special value returned in event of a authorisation failure, should be the same as that which would be returned in event of no data being available, e.g. “” for text and zero for numeric data37. A side effect of this approach is that no special handling is typically required to handle either special cases or any exceptions raised, e.g. if the data is destined for display, the result obtained from the SDO can be displayed to the user irrespective of whether the SDO had no data, had data and returned it, or had data and refused to return it.
4.5.3 Returning an SDO from a Method
One of the more common return types for methods is an object. In an SDO based application, many of the objects returned will be SDOs. Most SDOs encapsulate mul- tiple protected data members, and those data members normally have different access rights associated with them. From a security viewpoint, an important issue when re- turning an SDO is exactly what protected information the returned SDO should con- tain. Should it contain all the information available or should it only contain that information which the requesting user is permitted to access. Although that decision is application dependent, the issues involved in making that decision will be discussed in the remainder of this subsection.
4.5.3.1 Include all information
On most occasions within an SAA, the SDOs returned should encapsulate all the infor- mation available. The trust between the nodes on which the distributed SAA executes should be sufficiently high to ensure that users at the destination will not be hostile38.
37In the prototypes, because the reason for developing those prototype was to perform research, not to create a good SAA implementation, a different easily identified distinguished values were returned, when authorisation failed. 38It is also reasonable to assume that the security configuration of the system should be such that the probability of viruses and other malware being active at the destination, is low. 4.5. Using SDOs 117
Under such conditions, the authorisation provided by the SDO will be sufficient to ensure that the encapsulated protected information will only be made available to au- thorised used.
4.5.3.2 Include partial information
Potentially, the SDO might eventually end up in a hostile environment. There the SDO may be subjected to the types of attacks to which mobile agents are potentially subjected, e.g. code analysis and the like (see Section 2.8.3 for details). Under such conditions, the access control measures implemented within the SDO are ineffective. The SDO could employ techniques used by mobile agents to defend against such attacks, however such techniques are ineffective in providing long-term protection for encapsulated resources. Under such circumstances, a (partial) solution might be to limit what sensitive information is contained within the SDO to an absolute minimum. When the SDO only contains the relevant subset of available information, the in- formation that the requesting user is not entitled to access in any way will be replaced by the same distinguished dummy values that would be returned in event of an au- thorisation failure. For a data member of type String, the true information might be replaced by an application-defined string which indicates that no value is available, e.g. an empty string, “****”, or a null value39. The use of this technique, should not be perceptible by either the user or the remainder of the application. The remainder of the application will still only see what the SDO would normally return. However if the SDO is attacked from outside the application, only the user’s subset of the available information can be disclosed. This technique is another example of the security principle of ‘defence in depth’40 being employed. There is a huge restriction placed on the design of applications inherent in the adoption of this approach (rather than having SDOs encapsulate all the available in- formation). The approach of encapsulating partial information cannot be used if an SDO can be accessed by users having different privileges, e.g. users acting in differ- ent roles. Then, should the SDO containing only ‘partial information’ be accessed by a user who possess sufficient rights to access the excluded information, that user would
39The use of a null value might be the least desirable of the alternatives as additional code will be required to ensure that the returned null value is not dereferenced. That approach is also not applicable to primitive types, e.g. the types int and float. 40The principle of ‘defence in depth’ suggests that effective security is best provided by using mul- tiple independent mechanisms, organised in such a way that they provide layered protection. If one protection mechanism fails, protection is still by the remaining mechanisms. 118 Chapter 4. Applying the SDO Concept be led to believe that the excluded information (which they are entitled to access) does not exist.
4.5.4 Returning the Information in a Collection of SDOs
In an object-oriented program, when a list of data records (effectively a table of infor- mation) is to be returned by a method, or server, that information could be returned as either a collection of objects (with each object encapsulating a data record) or as a single object that contains that table of data (with each row containing the information from a data record). Using the SDO paradigm, the same two approaches can be used, except that instead of returning normal objects, the objects returned are SDOs.
4.5.4.1 A Collection of SDOs is returned
From an SAA developers perspective, the major difference between these two ap- proaches is likely to be the granularity of the protection provided. When a collection of SDOs is returned, each SDO will enforce the security policy relating to its protected content. Fine grained protection, down to the level of each protected field within each record, is being provided. Whether the SDOs that are returned contain the full comple- ment of information that is available, or only that subset of fields which the requesting user is entitled to access, is a design decision for the development team. Another advantage of this approach is that each SDO carries the relevant usage rights for its content, so they too apply to the individual records. Usage rights specify how the user is permitted to use the SDO’s information once the SDO passes the information onto other objects acting on behalf of the user, e.g. are they permitted to print the information. Refer to Section 4.6 for a discussion of usage rights and how they might be enforced within an SDO-based SAA. The disadvantage of returning an actual collection of SDOs is the inefficiency involved in extracting information from that SDO collection. Each time an access is made to an item of protected information within an SDO, the operation needs to be authorised, e.g. for a GUI to display the information contained within the collection, to the user, authorisation must be performed for each piece of protected information being displayed. 4.6. Handling Usage Rights 119
4.5.4.2 A Table of Information in an SDO is returned
In the second approach, an SDO containing a table of information is returned. Like all SDOs, access control will be enforced on its protected content, namely the table of data. The granularity of that protection will be at the table level, i.e. the SDO will exert control on who can access the table and in what manner, rather than restricting access to the individual rows, and/or columns, of the table. Thus, this approach yields a significantly more coarsely grained level of control. The security policy is likely to require a much finer level of control, than is being enforced by the SDO, i.e. a particular user is likely have different access rights to different records. That level of control will need to be exerted when the table SDO is instantiated. Each row of the SDO’s table will only be populated with the information which the requesting user is permitted to access, with restricted information being replaced by dummy values. The major advantage of this approach over the previous approach is that access to the information is likely to be more efficient. The SDO is likely to provide a method by which whole rows of information, or the whole table can be accessed. Thus only a single authorisation check would be required to access these information blocks. These improvements in efficiency are however offset by the need to perform a separate authorisation check to each element in the table during the instantiation of the table SDO41. A disadvantage of this approach is that usage rights are also applied at the table level. Usage rights will be discussed in the next section.
4.6 Handling Usage Rights
Within an SDO-based application, sensitive information remains encapsulated within SDOs as it is moved between the objects of the application. The information should only leave its encapsulating SDO when it is finally presented to the user, or is being transferred to another SDO. Reluctance to remove information from SDOs should be adopted because the non-bypassable access control afforded by SDOs, can only be applied to protected information while it remains within an SDO. A second orthogonal aspect to the protection afforded to information by an SDO- based SDO, is to (indirectly) determine its allowed usage after the protected informa-
41Depending on the result of the authorisation, either a piece of protected information or the appro- priate dummy value, was copied into the table. 120 Chapter 4. Applying the SDO Concept tion leaves the SDO. Possible forms of usage include the ability of the user to view42, print or save that information. It is envisaged that a single usage right applies to all the SDOs’ information (to which the user is granted access), e.g. should the user attempt to print the currently displayed data record, either all or none of the displayed infor- mation will print43. Both the usage and access control information are incorporated within the SDO by the ‘information owner’ during SDO instantiation. An SDO is unable to enforce usage rights as it cannot restrict the usage of informa- tion once it has left the SDO. Within an SDO-based application, the responsibility for the enforcement of usage rights passes to those objects which acquire the protected information. Those objects are often the application’s GUI objects44, which are the appropriate place to enforce usage rights. After all, the primary responsibility of GUI objects is the presentation of information to the user, but might also enable the user to use that information in a controlled manner. The sample frame from the HR System prototype that was presented in Figure 4.2 (Section 4.1), illustrates the use of a GUI object to enforce usage rights. Although a ‘hruser’ is permitted to view the displayed information, they are not permitted to print that information. The GUI object enforces that requirement by disabling the ‘Print’ button. The implementation of usage rights is dealt with in Section 6.8.1, where the en- forcement of usage rights in the HR System prototype is discussed.
4.7 SDOs and Cryptography
To secure their sensitive resources, SAAs are likely to use the orthogonal approaches of SDOs and cryptographic techniques. SDOs provide a framework for the enforce- ment of the application’s access control measures, while cryptography is used to en- sure the confidentiality and integrity of data while the data is in transit between com- puters, and potentially to secure the data resident on a single computer. Confidentiality is preserved through the encryption of data. Provided a secure encryption algorithm is employed and encryption keys are not compromised, encryption ensures that infor-
42When the right to view the information is not permitted for that particular user, the information can only be used by that user for the generation of statistical data. 43Should specific application requirements dictate that usage rights be applied at a finer level, usage rights could be associated with the individual data fields of the SDO. The application of usage rights at that level was not investigated as part of this research. 44Alternatively, the information should be transferred to another SDO, which will also encapsulate the relevant usage rights. 4.7. SDOs and Cryptography 121 mation is kept confidential. On the other hand, integrity is maintained through the use of cryptographic message authentication codes (MACs). The use of MACs do not prevent the loss of integrity of data, rather they ensure that any loss of integrity, is made evident. While data is active45 within an object-oriented program, that data should be en- capsulated within SDOs. In the remainder of this section, the relevance of MACs and encryption to SDO-based applications will be discussed.
4.7.1 Protection of Data in Transit
In object-oriented applications, when data is being transferred across a network, on most occasions, that data will be encapsulated within an object46. If that data is sensi- tive, it should be encapsulated within an SDO. The protection of data while it is in transit, is the province of cryptography. In a distributed SAA, cryptographic techniques are often applied within multiple layers of the communications stack. Transport level cryptography is usually used to provide point to point security. For example, the Secure Sockets Layer (SSL) protocol em- ploys both encryption and MACs to guarantee both the confidentiality and integrity of a message as it makes each hop between hosts. Importantly in this protocol, cryptog- raphy is only used to secure the message while it is in transit between hosts. While at an intermediary host, the message is temporarily held in plain text. However, an intermediate node could be compromised (by an attacker) or it could act maliciously. Consequently, the use of transport level security alone, does not necessarily prevent the loss of confidentiality and/or enable the detection of integrity loss. To alleviate this deficiency, transport level protection is often supplemented by ap- plication level protection. Using cryptography at the application level provides end- point to endpoint security. When encryption is employed at both levels, only the application-level encrypted message is exposed at intermediate hosts after the trans- port level encryption is removed. Provided that the application-level cryptographic algorithms are secure, loss of confidentiality will not occur and any loss in integrity will be evident to the receiver. 45Active in this sense implies that the data is encapsulated within a software object, and so that data has the required functionality associated with it. When non-active, the data is likely to be resident within a database or a file. 46When an object is being transferred between hosts, in reality the object itself is not transferred. Instead the object is serialised, and the individual data members transferred. At the destination, an object of the required type is automatically instantiated from that data. 122 Chapter 4. Applying the SDO Concept
In a Web services environment, the WS-Security Standard (see Section 2.2.4) de- fines mechanisms for implementing application-level encryption and/or signing, of all or selected parts, of SOAP messages. Software tools that implement the functionality defined within this standard are readily available. In traditional distributed applica- tions, application-level encryption and/or signing can also be used to secure objects while they are in transit, however such mechanisms are usually proprietary. In Java, the cryptographic primitives that are supplied as part of the development environment can be used to provide the required protection. Alternatively Java’s Signed and/or Sealed objects (see Section 3.2.7.1) could be used. From the discussion, it is apparent that cryptographic techniques definitely have a part to play in securing SDOs as they are transferred across the network. In the next section, the role that cryptography plays in the securing of sensitive data while the encapsulating SDO is resident within a single virtual machine, will be discussed.
4.7.2 Protection of Data within SDOs
Unlike the securing of data while in transit, where the use of cryptography is effec- tively mandatory, the use of cryptography to secure SDO data while the SDO is within a single virtual machine, is to a large part, discretionary. Obviously the need for cryp- tographic techniques will depend on the application, the sensitivity of the data being managed, and importantly the level of protection provided by the support environment, in particular operating system protection.
4.7.2.1 Message Authentication Codes (MACs)
Where the protection provided by the operating system is inadequate to guarantee process isolation, the use of MACs to provide integrity guarantees might prove useful. However, the generation of imperceptible changes to an SDO’s data is difficult. An SDO is after all, an object within a object-oriented program, that is being executed within a virtual machine. Consequently, it would be difficult to modify the SDO’s encapsulated content, through modification of the virtual machine’s memory, without causing some form of corruption that would be detected by, or cause the malfunction of, the virtual machine. Where the sensitivity of the data is sufficiently high, the use of encryption to ensure privacy, and/or MACs to detect any loss in integrity, could be justified. Assuming MACs are being employed and an integrity violation is detected, the 4.7. SDOs and Cryptography 123 action to be taken by the SDO would be application specific. However that response is likely to involve: (1) the inclusion of details of the integrity violation (i.e. a potential security breach, within the audit log, (2) informing the user of the corruption of data, and (3) the SDO effectively destroying itself47. A significant loss in performance could potentially restrict the usefulness of MACs within an SDOs. That performance loss results from a combination of the following factors: the verification of the SDO’s MAC is computationally quite expensive (even compared to the (locally-based) access control measures) so the access time increases dramatically, and under certain circumstances, e.g. the displaying of data record or lists of records, a large number of such MAC verifications may be required.
4.7.2.1.1 MACs and Mutator Methods If MACs are being used, whenever a mu- tator method48 modifies data members, obviously a new cryptographic MAC will need to be computed. What may be less evident is that the integrity of the SDO needs to be established, before the SDO’s new MAC is computed and used to replace the current MAC. If the integrity of the SDO is found to have been compromised, the requested operation is aborted and the integrity compromise is processed as previously outlined. If the integrity check is not performed prior to the MAC being updated, the presence of malicious change made by an attacker, is likely49 to be obscured by the replacement of the MAC. Fortunately, updates are relatively infrequent so the impact on performance is acceptable.
4.7.2.1.2 MACs and Accessor Methods The fetching of data values from an SDO (or a ‘normal’ object for that matter) occurs much more often than updates to that data. Consequently a large number of MAC verifications might be performed if the naive approach of requiring all accessor methods to perform an integrity verification, is adopted. Recall that an SDO is just an object within an object-oriented program (that hap- pens to enforce access control), so it will potentially receive numerous messages re- questing data values. Consider the HR scenario, that was introduced in Section 4.1, for an example. An Employee SDO has several data members each of which is accessed by a dedicated accessor method. When all of the SDO’s encapsulated data is fetched
47Refer to Section 4.4.2.1.2 for a discussion of how an SDO might attempt to destroy itself. 48In this context, a mutator method is meant to include methods that modify more than one data member, i.e. any method that causes the internal state of the SDO to be modified. 49Refer to Section 4.7.2.3 for details of why the update of the MAC will not necessarily obscure the integrity violation. 124 Chapter 4. Applying the SDO Concept for an authorised user, e.g. to display the information on the computer screen, each of the SDO’s accessor methods will be invoked. With a naive approach, each method invocation will require the integrity of the SDO data being verified. To fetch all six data members of an ‘Employee’ object, the integrity of the object will be established six times on rapid succession. The number of integrity checks becomes significant if a list of employee details is being displayed, rather than those of an individual object. The number of data verifications can be significantly reduced by taking a more pragmatic approach to the integrity checking regime. One approach would be to only perform an integrity check in a subset of accessor methods, e.g. when the ‘key’ for the data record and when critical data fields are accessed. The resulting reduction in the number of verifications performed, makes that use of cryptographic MACs for accessor methods feasible.
4.7.2.1.3 Computing and Checking MACs The computation of MACs and the checking of SDO integrity are not performed by an SDO itself, but instead delegated to the SDO support environment50, due to the security ramifications of having crypto- graphic keys stored within mobile code. Again to ensure the security of cryptographic keys, the SDO support environment, in turn, is expected to use the hardware facilities for the secure storage of cryptographic keys and for computational efficiency. Such facilities are provided by the low cost and increasing adopted TCG Trusted Platform Module (see Section 2.7). The SDO environment provides two core cryptographic functions for MAC com- putation and integrity checking: sign that returns the MAC computed for provided content using the specified key51, and isValidSignature that determines whether the provided MAC is the correct MAC for the provided content and specified key. To enable integrity checking, an SDO is only directly responsible for collecting the data whose integrity is to be monitored in a suitable form and storing its associated MAC.
4.7.2.2 Encryption
While SDOs and their protected content remain within a single virtual machine, the need for encryption and decryption is analogous to that which applies to the com- putation of MACs. Consequently, SDOs are unlikely to use encryption to ensure the
50The functionality performed by the SDO Support Environment is the topic of Chapter 7. 51As previously stated, the SDO does not store the cryptographic key, only the identifier for the externally stored key is provided to the method. 4.7. SDOs and Cryptography 125 confidentiality of their protected data when numerous separate pieces of protected data are being used. As outlined in Section 4.7.2.1, there are likely to be a large number of calls made to an SDO. If all protected data was stored as ciphertext, i.e. the data is encrypted, most of these calls will require the decryption of data. Although encryption and decryption rates are very high when large amounts of data is being processed, SDOs ofter en- capsulate ‘small fields’ so small amounts of data will need to be encrypted/decrypted on many occasions, incurring a significant performance overhead. Consequently, for most applications, the use of encryption will be confined to highly sensitive data fields where the need to maintain confidentiality justifies the loss in performance. Addi- tionally as highly confidential information is unlikely to be accessed often, the overall performance penalty for the application will remain low. Cryptography might also be used in related cases where an SDO encapsulates only a single, or small number of protected fields. A prime example is a health record. There the information is likely to consist of a small number of information blocks that are accessed separately. In such situations, it would be feasible to separately encrypt each sensitive data block while leaving other blocks unencrypted. Only after authorisation, would a particular field be decrypted and made available to the user. For efficiency, it is likely that private key encryption52 will be employed. This is an analogous approach to that taken with regard to the computation of MACs, where the integrity of the SDO was only validated when selected methods were invoked. In both cases the overall aim is to reduce the frequency with which the cryptographic functionality is invoked, while still achieving the desired security enhancements. The SDO environment provides to two core encryption related functions: encrypt that returns the ciphertext computed from provided plaintext using the specified key, and decrypt that returns the plaintext derived from the provided ciphertext using the specified key. From the preceding discussion, it is apparent that both the use of MACs to provide integrity guarantees, and encryption to provide confidentiality guarantees, can have a role to play in the protecting of an SDO’s content from access by means other than through the application defined mechanisms. In the next section, the implications that making all the SDO’s data members private53 have on the application of cryptography
52There is no requirement to use the less efficient public key encryption as only the SDO will be encrypting and decrypting its protected content. 53Refer to Section 4.4.1 for a discussion of why data members should be declared as being private. 126 Chapter 4. Applying the SDO Concept within SDOs, will be discussed.
4.7.2.3 Inheritance Hierarchies and Cryptography
The adoption of the policy of making all data members private has implications on the provision of cryptographic protection within a hierarchy of SDO classes. Since data members are only visible within the class in which there are declared, any cryp- tographic technique that is applied to a data member, must be performed by a method of that class. This restriction, naturally applies to all classes within the hierarchy.
4.7.2.3.1 Integrity Checking Integrity checking is performed using cryptographic checksums. It is only possible to compute a ‘single MAC’ for an SDO if that SDO class is the base class for the SDO inheritance hierarchy54. For all subclasses of that ‘base class’, the MAC consists of an ordered list of separate MACs. One of those MACs is contributed by each class in the hierarchy, and is computed from all of the protected data members declared in that class. Provided that the MAC algorithm is secure, providing the list of MACs to a sub- class, or indeed any other class, does not constitute a security risk. The alternative approach of providing the protected content to the subclass so that a single MAC could be computed, suffers from the same security problem as providing the subclass with direct access to the data. For consistency, all SDOs whether or not they are currently part of an inheritance hierarchy, should adopt the use of a list of sub-MACs to represent their MAC. 55 For the remainder of this discussion, the term ‘SDOMAC’ will be used to denote the ordered list of MACs associated with an SDO. The core methods that each SDO class in the hierarchy will need to provide to sup- port MACs are likely to be checkMAC, getMAC and setMAC. The method checkMAC allows the SDO to verify its integrity. The methods getMAC and setMAC are required for distributed applications to permit the SDO to be transmitted to a remote virtual machine. Each of these methods is recursive-like, performing the required operation on its local MAC and indirectly, those of its superclasses. The maintenance of the valid checksum is straight forward. Any method that
54In many object-oriented languages, including Java, all classes derive from a single system-supplied base class, usually called Object. In this context, the description ‘the base class for the SDO inheritance hierarchy’ means, the SDO class which is the superclass for all of the other SDOs in that class hierarchy. 55Thus an ‘SDO’s MAC’ will always be a list of MACs, rather than sometimes being a list and other times a single MAC. 4.8. Summary 127 actually modifies a protected data member, is also responsible for validating and then recomputing the checksum for those data members that were defined within that class.
4.7.2.3.2 Providing Confidentiality If encryption and decryption of protected con- tent is being supported, that process is handled in a similar manner to the provision of checksums. Any accessor method will need to decrypt the protected data members defined in that class and then return the required value. A method that modifies a pro- tected content, must initially decrypt the protected data members defined in that class, update the data member (or members) and then re-encrypt the data. If encryption is being employed, it is highly likely that integrity checking is also employed. After decrypting the data and before performing its required operation, the integrity of the decrypted data will be validated using the checksum.
4.7.2.4 Key Management
The management of the cryptographic keys used for both SDO MAC computation and encryption is considered to be beyond the scope of this research. The management of cryptographic keys is still a research problem, with most research investigating how to more practically exploit the potential provided by Public Key Infrastructure (PKI). With regard to SDOs, the current security practice of using separate keys for encryption and MAC generation, and for each application or application domain to use dedicated keys, is expected to be adopted.
4.8 Summary
The adoption of the SDO paradigm ensures that the fine grained application specific mandatory access control required of an SAA is implemented in a manner which en- sures that the access control performed is appropriate, non-bypassable and audited. The methods of an SDO which provide the only access to its encapsulated sensitive data, also ensure the protection of that data from unauthorized access. In this chapter, the application and implications of adopting the SDO concept have been discussed in general terms. Specifically, mechanisms by which authorisation might be performed were presented, the importance of providing a complete audit trail identified and the minimal impact that the adoption of the SDO concept has on current development practices discussed. 128 Chapter 4. Applying the SDO Concept
While this chapter has avoided as far as possible, any discussion of language- specific implementation details, the next two chapters deal with implementation of the SDO concept within Java based SAAs. The next chapter, Chapter 5 discusses the development of a non-distributed prototype that acted as an initial proof of concept and presents the lessons learned from its development. Chapter 6 discusses the application of the SDO concept to distributed SAAs and the implications of adopting the SDO paradigm. Chapter 5
The SDO Concept in Java Non-distributed Applications
Both this chapter and the next are intended to perform two functions. Firstly, they detail research which was conducted as part of this PhD research, and secondly they act as a technical tutorial describing how the SDO concept can be applied. The tutorial is intended to aid future researchers and/or developers interested in exploring the SDO paradigm, so is necessarily quite technical in nature. This chapter deals with how the SDO concept can be applied to the development of non-distributed security aware applications (SAAs), while the following chapter concentrates on its use within distributed SAAs. Because the material dealt with in this chapter is equally applicable to the individual nodes of distributed applications, the next chapter is mainly concerned with how SDOs can be transferred between sites and any ramifications the distributed nature of the system has on the implementation of the SDO concept. It then looks at other issues of a general nature that were not investigated in the first stage of the research. By considering the application of the SDO concept to non-distributed SAAs, this chapter deals with the outcomes of the first stage of the research whose primary aim is to demonstrate the feasibility of developing SAA using the SDO concept and to gauge the benefits of employing that approach. A subsidiary aim was to determine whether the SDO concept was sufficiently powerful to allow it to be used to retrofit an existing non-security aware Java application, to make it security aware. The development of a prototype was undertaken to achieve those goals.
129 130 Chapter 5. The SDO Concept in Java Non-distributed Applications
The earlier parts of this thesis, in particular Chapter 4, have described the research that provided the theoretical foundations that guided the development process. The prototype was created by modifying an existing GUI-based, non-distributed program, ‘CD Catalog’, that was hypothetically being made available to the customers of a music store. The successful application of the SDO concept to the development of the prototype suggested that the SDO concept was viable as a software development paradigm. To demonstrate its more general applicability, further research was conducted using that prototype, experimenting with different ways of implementing the SDO concept and to provide an acceptable audit facility. These investigations resulted in the development of a series of prototypes1. Development of the CD Catalog prototypes was carried out using several versions of Sun’s Java Development Kit, with the final combined prototype being developed using Sun Microsystem’s JavaTM 2 Platform Standard Edition 5.0. Development was carried out on a Pentium based system running Windows XP. This chapter will continue with a discussion of the first stage of the research and the CD Catalog prototypes developed to support that research.
5.1 The CD Catalog Prototypes
The CD Catalog prototypes were created by retrofitting an existing program rather than developing a purpose-built application. That decision was primarily influenced by two factors: (1) the prospect of simultaneously meeting two of the aims of the first stage of the research, demonstrating the applicability of the SDO paradigm and that the SDO paradigm could be applied retrospectively to an existing application to an SAA; and (2) the time restrictions imposed by a PhD program meant that care should be taken to reduce time wastage on unnecessary prototype development2.
1Although that was initially correct, the very large amount of code duplicated within the prototypes resulted in significant maintenance problems. The different prototype versions were eventually com- bined into a single configurable program. However, for simplicity of explanation, the discussion will be in terms of the series of prototypes. 2That time is better spent on the research component and development directly related to that re- search. 5.1. The CD Catalog Prototypes 131
5.1.1 The Starting Point for the Prototype
With the widespread adoption of GUI based applications, it was considered essential that the prototype be GUI-based. Then, any limitations of the SDO concept, that only apply to GUI environments would become evident early in the research, allowing suf- ficient time for them to be addressed. In contrast, it was considered unlikely that there would be any limitations that would be peculiar to non-GUI applications. However having made this decision, time constraints prevented an investigation into the appli- cability of the SDO concept to SAAs that relied on complex application interaction. That topic requires future research. There were essentially three development strategies that could be used to develop the first SDO-based prototype: develop a purpose-built prototype (from scratch); mod- ify/extend an existing application whose code and design documentation were avail- able; or modify/extend a suitable application that the candidate had recently devel- oped. Time restrictions tended to eliminate the first two choices. The time required to develop a GUI-based application from scratch would be considerable and so should be avoided if possible. Similarly, considerable time would be required to become fa- miliar with the design and implementation of an application sourced from elsewhere. Thus, provided the candidate had recently developed a suitable application, modifying that application seemed to be the best choice. The application chosen was a Java application that the candidate had developed as a teaching vehicle for an advanced Java course. Although the program should have been security aware, that facility had not been provided in the original program. Not being security aware was not considered to be a major deficiency. The lack of authentication and authorisation code would be offset to some extent by not having to redesign the SAA aspects of the program to make it compatible with the SDO paradigm. The existing ‘CD Catalog’ program was considered suitable and was chosen to act as the starting point for the prototype. That choice was based on the following considerations:
• the fully tested application had only recently been developed by the candidate, so he was familiar with its design and implementation;
• the application was typical of the large class of security aware applications that provide the users with view and maintenance services on information stored within a database (or other persistent store); 132 Chapter 5. The SDO Concept in Java Non-distributed Applications
• the application was GUI-based and included facilities for presenting both lists of information to the user, as well as enabling them to perform maintenance at the data record level.
• the information being maintained by the application was minimal, so the devel- opment could concentrate on achieving the research aims rather than concen- trating of completing a difficult development task; and
• the application was distributed and used the classic client-server model3.
5.1.1.1 The Original CD Catalog Program
The information system stores the details of the CD collection of a fictitious music store, and permits transactions of that collection. The application was supposedly intended for use by store customers, rather than store staff, so only very limited in- formation was maintained for each CD, namely: the product code, title, artist, year of release, the quantity on hand, the filename of the CD cover image and the cover image. A simple graphical user interface provided support for the following functionality:
• Display the information for a CD (including a CD cover image). An option is available to print that information.
• Update information for a compact disc.
• Add or Remove a compact disc from the collection.
• Display the information on all the CDs in the catalog, in a tabular format. The sort order can be changed by clicking the column headers and printing is sup- ported.
• Search for CDs using a product code range, or substring matches in the artist or title fields. Printing is supported.
• Selection of CD cover image files from the local file system.
• The playing of songs.
3Although not required for the initial prototype, having existing code to support the distribution of that application was expected to be extremely valuable during the second stage of the research, that would concentrate on the role of SDOs in distributed applications. The program’s modular design meant that these features could be easily removed, and later reintroduced when required. 5.1. The CD Catalog Prototypes 133
Since the CD collection is small, at startup, the system application loads the CD information from persistent store (a database) into a memory based data structure. That store is then used to service information retrieval requirements of users. When changes are made to the information, i.e. ‘add a CD’, ‘delete a CD’ and ‘update a CD’, the changes are immediately committed to the both the memory based data structure and the database. A screen capture showing part of the GUI provided by the application is presented in Figure 5.1.
Figure 5.1: The Original CD Catalog GUI
5.1.1.2 Class Design Overview of the CD Catalog Program
The class overview for the application is included to make the reader familiar with the main objects within the system, so that later discussion relating to the mapping of the SDO concept onto the existing application, will be more meaningful. The list of classes used in the original application is presented in Table 5.1, and a brief description of each class follows:
• The functionality required of a persistent store is defined by the interface DataS- tore. In the original program, that interface was implemented by several classes including DataStoreRDB4, that employed a Java JDBC to provide the services required to manipulate the Microsoft Access database containing the CD infor- mation. For brevity, the persistent store will be referred to as the ‘datastore’.
4A factory class, DataStoreFactory, is used to select the appropriate DataStore implementation. In the SDO prototype, only the DataStoreRDB was retained. 134 Chapter 5. The SDO Concept in Java Non-distributed Applications
Package Name of Class Package Name of Class catalog CDProgram catalog.guistuff AboutDialog CatalogModel EditGUI CatalogModelListener FindGUI CDSelector ListGUI ByArtistOrTitleSelector ListGUIModel ByPCSelector MainGUICore MainGUIFrames catalog.compactdisc CompactDisc MainGUISPanel PrintingMethods catalog.datastore DataStore ReportHeader DataStoreRDB WindowCloser DataStoreFactory GraphPaperLayout DataStoreException SingleComponentLayout CDFileFilter catalog.guistuff PreferencesDialog FilePreviewer AudioPlayer Table 5.1: Class List for the original CD Program
(Note that the CD cover images are stored as separate .gif or .jpg files, rather than in the database.)
• The memory-based data structure was implemented by the class CatalogModel. This memory-based data structure will be referred to as the ‘datamodel’.
• The details of a single CD are encapsulated within a CompactDisc object.
• Whenever either a single CompactDisc object or collection of CompactDisc objects is returned by the datamodel, copies of the relevant objects (rather than references to the existing objects) are returned. This approach has the advantage of being suitable for both local and distributed applications.
• When the user provides the criteria for a CD search, either a ByArtistOrTitleS- elector or a ByPCSelector object is instantiated, and passed to the datamodel. Those objects implement the user-defined CDSelector interface, that allows the datamodel to determine which CDs match the selection criteria.
• The ‘List of all CDs’ dialog is displayed by the ListGUI object, which in turn uses a Java supplied table GUI object, a javax.swing.JTable.
• Even though not all the GUI objects are visible at all times, the objects still exist, but are invisible. Hence, retaining consistency of data within the GUI objects is a problem. The problem is overcome by having the GUI objects implement the CatalogModelListener interface, enabling them to be notified of changes made to the datamodel, and so reflect those changes in their displayed information. 5.2. Applying the SDO Concept 135
Thus the information presented in each of the GUI objects reflects the current state of the datamodel.
• GraphPaperLayout and SingleComponentLayout are layout managers needed to support the program’s GUI.
• MainGUICore provides the majority of the code needed to support the main GUI object that holds the menus and toolbar. Classes such as MainGUIFrames and MainGUISPanel, extend that class to support each of the GUI interfaces provided. The GUI presented in Figure 5.1 is the multiple frame version of the GUI.
• The classes CDFileFilter, FilePreviewer were used to support the file searching using Java’s file dialog support.
• The Java Media Framework was used to support the playing of the songs with the support from the class AudioPlayer.
• PreferencesDialog allows the user to select program preferences that include the type of GUI and the datastore implementation to be used.
• The system was packaged as a Java jar file.
5.2 Applying the SDO Concept
In this section, the process used to convert the CD Catalog program, described in the previous section, to an SAA will be outlined. Before that conversion was undertaken, a decision was made to remove some of the superfluous ‘teaching related’ function- ality from the application prior to its conversion to an SAA. They include support for the playing of songs, the implementation of multiple data store implementations, the setting of user preferences, multi-language support, support for several views of the GUI. Although research and practical experience of the security community has estab- lished that effective security cannot be retrofitted to a software package, it was be- lieved that the modular design of the application, its simplicity and the properties of the SDO paradigm, would allow mandatory access control to be retrofitted to this ap- plication program. Further, it was believed that the security related functionality could 136 Chapter 5. The SDO Concept in Java Non-distributed Applications be added without significantly modifying the application’s overall design 5.
5.2.1 The Conversion Process
After having conducted the initial research into how the SDO concept might be im- plemented and having designed the interface to the authentication and authorisation subsystem, it was time to determine whether those ideas could be implemented. The actual conversion of the standard application to an SAA involved the following steps:
• Develop a security policy for the SAA.
• Identify the SDOs.
• Design the SDO Class Change Requirements.
• Create the SDOs and modify the application to reflect the new invocation syntax and semantics of their methods.
• Develop the authentication, authorisation and audit classes.
5.2.1.1 Develop a Security Policy for the SAA
In previous chapters, the provision of mandatory access control (MAC) within an SDO-based SAA has only been discussed in general terms. The only specific state- ment made was that the RBAC model would be enforced, rather than classic MAC. As the purpose of the development was to test the feasibility of using the SDO concept, rather than attempting to develop a practical RBAC system, it was decided that initially only a few roles would be associated with the application program. The not completely realistic roles were: creator, the role that was assumed to execute the program (but not use the program); hruser, the role assumed by customers and staff who were only permitted to view the information; hradmin, the role assumed when updating CD information (including the ability to add but not remove a CD), but is unable to update the ‘quantity on hand’ field qoh, and to terminate the program; and hrmanager a similar role to hradmin, but with the added privileges allowing the update of a CD’s qoh and the removal of a CD. More detail relating to the permitted operations associated with each role is presented in Table 5.2.
5Several additional classes were required to support the imposition of mandatory access control, i.e. provide support for user authentication, authorisation and audit log generation. 5.2. Applying the SDO Concept 137
Role Resource Permitted Operations creator a CD record instantiation, read on all fields data model instantiation, close, get CD list, get CD count, add a model listener data store instantiation, open, close, load hruser a CD record read on all fields data model get a CD’s info, get CD list, get matching CDs, get CD count data store hradmin a CD record instantiation, copy CD, read on all fields, write on all fields except qoh data model get a CD’s info, add CD, remove CD, update CD, get CD list, get matching CDs, get CD count, close data store add CD, update CD, close a file dialog able to traverse the file system (to look for CD covers) hrmanager a CD record instantiation, copy CD, read and write on all fields data model get a CD’s info, add CD, remove CD, update CD, get CD list, get matching CDs, get CD count, close data store add CD, remove CD, update CD, close a file dialog able to traverse the file system (to look for CD covers) Table 5.2: Application-Level Access Control Rules
At the time of writing the security policy, the minimum system-level privileges needed to allow the application to run were unknown. During the development pro- cess, the minimum privileges required were established6. The policy file that grants those minimum privileges to the program, is presented in Listing 5.1. The reader should refer to Section 3.2.5 for details of the syntax of the grant statement used in that file.
5.2.1.2 Identify the SDOs
The classes that will become self-defending are those classes within the program that provide functionality or access encapsulated information, which the security policy identifies as requiring protection. The identification process of the SDOs should be straight forward, as the relevant objects and the resources they encapsulate, are enu- merated within the program’s security policy. The only complicating factor will be determining the mapping between the name of an object in the security policy and its manifestation within the program. However for this simple program, that process too, was straight forward. The candidate classes were identified as being DataStoreRDB (the datastore), CatalogModel (the datamodel), CompactDisc (a CD) and CDFileFilter (a file dialog).
6Each time the application could not run due to the lack of a specific privilege, that additional privilege was granted. 138 Chapter 5. The SDO Concept in Java Non-distributed Applications
Listing 5.1 Security Policy for CDProgram grant codebase "file:./CDProgram.jar" { // for JAAS authentication permission javax.security.auth.AuthPermission "createLoginContext.catalogSDO"; permission javax.security.auth.AuthPermission "modifyPrincipals";
// for database access permission java.lang.RuntimePermission "accessClassInPackage.sun.jdbc.odbc";
// general purpose permission java.util.PropertyPermission "file.encoding", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read";
// to read images for CD covers and toolbar permission java.io.FilePermission "-", "read";
// for printing permission java.lang.RuntimePermission "queuePrintJob"; };
5.2.1.3 Design the SDO Class Change Requirements
The access control provided by SDOs can be achieved by using two mechanisms, method authorisation and data authorisation7. Earlier in this thesis (Section 4.2.3), method authorisation was identified as be- ing sufficiently powerful to provide support all of the access control requirements of SDOs. For the majority of methods, method authorisation within the preamble works effectively to provide the required degree of access control. However, in some meth- ods, such as CatalogModel.update, method authorisation alone is insufficient. The problem arises because a user might have the right to update the information stored in the data model about a CD, but is unable to update all fields. The role, admin fits into this category. Users associated with that role have the right to update CD information, but are unable to update the qoh field. To successfully update a particular CD field, the user must have been granted the
7The term ‘method authorisation’ is used to denote the controlling access to an SDO’s resources by controlling access to its methods. ‘Data authorisation’, on the other hand, denotes the controlling of access to protected data members by performing authorisation before an SDO method directly accesses any of those data members. 5.2. Applying the SDO Concept 139 permissions needed to invoke the update methods of both the data model and data store, and to update the individual data field. To try to gain experience in using both method and data authorisation, both were used in the prototype. Data authorisation was only used in the CatalogModel.update and DataStoreRDB.update methods, i.e. the methods which update the data held on individual CDs within the data model and the data store respectively8. To support these two forms of authorisation, the authorisation object will need to provide two authorisation checking methods. Since method authorisation will involve determination of whether the user9, is permitted to invoke a particular method, the method which used method authorisation requires those two pieces of information to be passed as parameters, the authorisation credential and the name of the method being invoked. When data authorisation is used, method determines whether the particular user is permitted to perform the specified operation on the particular data member, so those three pieces of information need to be passed as parameters. Listings 5.2 and 5.3, present the public method signatures10 for the class Cata- logModel before and after the design process. Since all public methods of the Cata- logModel performed functionality that required protection, all of their SDO methods equivalents have an authorisation token as an additional (and first) parameter. That au- thorisation token, which is an object of class UserID, is discussed in Section 5.3.2.1. As many of the SDO’s public methods need to perform an authorisation check, within the method’s preamble, a private method was added to each of the SDO classes to reduce the amount of duplicated code11. Listing 5.4 presents the quite trivial imple- mentation of that method. It makes a call to the SDO’s authorisation object to deter- mine whether the invocation of the relevant SDO method is permitted by the security policy. Should authorisation fail, a user-defined exception of class SDOSecurityEx- ception is instantiated with the appropriate error message, and thrown. A typical code
8Both of these methods did not need to perform that checking. The duplication was introduced, as the use of SDOs in distributed environments was to be investigated later in the research, and that approach will map onto a distributed application. 9More correctly, it is the role in which the user is acting that is important for authorisation purposes. Their identity is only required to generate the associated audit record. 10The code presented in the listing is not code that actually appears within the application program’s code. Since the intention is to present only the signatures of public methods of the class, they have been expressed using the syntax for a Java interface. Throughout the remainder of this thesis, this approach will be taken whenever presenting the procedural interface of a class. 11The decision was made to duplicate the code for the permission check methods within each of the class, and modifying the code to include the appropriate class name, i.e. CatalogModel in the sample code. Alternatively, a single copy of those methods could have been moved into a separate class, and then imported into each of the SDO classes. Taking that option would have required the passing of an extra parameter to the methods, the name of the SDO class. 140 Chapter 5. The SDO Concept in Java Non-distributed Applications
Listing 5.2 Method Signatures for class CatalogModel public static CatalogModel getInstance( CDProgram catalog); public void addCatalogModelListener( CatalogModelListener listener); public CompactDisc get(int productCode); public boolean update(CompactDisc cd); public boolean add(CompactDisc cd); public boolean remove(int productCode); public Collection getAllCDs( ); public int getNumCDs( ); public void close( );
/** return the collection of all CD objects accepted by selector */ public Collection getMatchingCDs(CDSelector selector);
Listing 5.3 Method Signatures for the SDO class CatalogModel public static CatalogModel getInstance(UserID uid, CDProgram catalog); public void addCatalogModelListener(UserID uid, CatalogModelListener listener); public CompactDisc get(UserID uid, int productCode); public boolean update(UserID uid, CompactDisc cd); public boolean add(UserID uid, CompactDisc cd); public boolean remove(UserID uid, int productCode); public Collection getAllCDs(UserID uid); public int getNumCDs(UserID uid); public void close(UserID uid); public Collection getMatchingCDs(UserID uid, CDSelector selector); 5.2. Applying the SDO Concept 141 fragment showing the use of doMethodPermissionCheck, this one from the method CatalogModel.update, is also presented in Listing 5.4.
Listing 5.4 Typical SDO Code used to Perform Method Authorisation \\ for method authorisation private static void doMethodPermissionCheck(UserID uid, String method, String details) { if (uid==null) { throw new SDOSecurityException("Model: nullUser no " + method); } if (! authorisor.isAllowed(uid,"CatalogModel",method, details)) { throw new SDOSecurityException("Model: " + uid.getRole() + " no " + method); } } // doMethodPermissionCheck () public boolean update(UserID uid, CompactDisc cd) { doMethodPermissionCheck(uid,"update",""+cd.getProductCode(uid)); ...
Although the idea behind isFieldAccessAllowed, the data authorisation version of doMethodPermissionCheck, is almost identical, for completeness the code for that method, together with an example of its use, are presented in Listing 5.5.
Listing 5.5 Typical SDO Code used to Perform Data Authorisation public static void isFieldAccessAllowed(UserID uid,String field, String operation){ if (!authorisor.isFieldAccessPermitted(uid,field,operation)){ String msg = "CD: "+uid.getRole()+" no cd."+field+ ":"+operation;
throw new SDOSecurityException(msg); } } // isFieldAccessAllowed private boolean fieldUpdateRequired(UserID uid, int currValue, int newValue, String field) { if ( newValue!=currValue && newValue!=CompactDisc.invalidInt) { CompactDisc.isFieldAccessAllowed(uid, field, "write"); return true; }//if return false; } // fieldUpdateRequired ()
The method fieldUpdateRequired, is a method of the CatalogModel class. Before any updates are performed by update, that method is invoked to determine whether all 142 Chapter 5. The SDO Concept in Java Non-distributed Applications of the requested updates are permitted. Specifically, it initially determines whether the user has requested an update to the specified data member, and if so, whether that user has the necessary permission to update that data member. The permission check is performed by invoking the method CompactDisc.isFieldAccessAllowed12. The three outcomes are: false - no update required, true - a update is required and the user is permitted to make such an update, or an exception is raised because the user has attempted to update a data member for which they do not have the relevant permission.
5.2.1.4 Create the SDOs and Modify the Program Accordingly
This stage involved the progressive conversion of each of the identified classes, one class at a time, to an SDO by (1) adding the permission checking method doMethod- PermissionCheck (and possibly isFieldAccessAllowed) to the class file, (2) changing the method signature for each of the identified methods and then adding its authorisa- tion preamble, and (3) making modifications to those methods that need to supplement the authorisation performed by the method authorisation preamble. At this stage, the authorisation objects only provide method stubs rather than making policy based au- thorisation decisions. In parallel, changes are made to those other objects in the remainder of the program that either directly or indirectly made use of the SDO services. These changes are not particularly significant to the thrust of this thesis. They merely reflected: the changed syntax within the application (the presence of an additional parameter that is passed to the SDO methods); the changed semantics of the SDO methods (now, they potentially throw a SecurityException, that needs to be appropriately handled); and the need to support user authentication13.
5.2.1.5 Develop the Authentication and Authorisation Classes
A detailed discussion of the implementation of authentication and authorisation in the initial CD Catalog program will be deferred until Section 5.3. The emphasis of that section is not the actual implementations of the relevant classes, but instead concen- trates on the requirements for implementing the authentication and authorisation in a
12The method isFieldAccessAllowed differs from its doMethodPermissionCheck counterpart in that former method does not log the event, while the latter does. 13The username-role-password mechanism used for authentication in the prototype, was made JAAS compliant. The JAAS architecture and requirements for an authentication mechanism to be JAAS compliant are outlined in Section 5.3.1. 5.2. Applying the SDO Concept 143
Java development environment, and uses the actual implementation as an example of how those requirements might be met.
5.2.2 The Self-Defending CD Catalog Prototype
The GUI for the CD Catalog prototype is presented in Figure 5.2. The operation of the SAA, is essentially the same as the original program except that it is now security aware. As can be seen by comparing Figure 5.2 with Figure 5.1, the basic GUI remains unchanged. Significant features of the SDO-based prototype which were not present in the earlier program are identified in the following paragraphs.
Figure 5.2: CD Catalog Program GUI
The role in which the user is acting, i.e. user, is displayed to the right of the tool bar, and the ‘look and feel’ of the whole GUI reflects that role. The three roles in which which users may act while using the system, user, admin and manager,have different ‘look and feel’s. The fourth role, that of creator, that must be assumed to execute the program, shares the manager ‘look and feel’. Details of the privileges associated with each role are shown in Table 5.2. The ‘Edit a CD’ dialog (the EditGUI object), presents the information relating to the CD ‘Revolver’. The user has just attempted to modify the artist field, for which they do not have the relevant permission. The message “Security Violation: Model: user no update” which is displayed, reflects the ‘research prototype’ nature of this 144 Chapter 5. The SDO Concept in Java Non-distributed Applications
program. The message indicates that a security exception was thrown within the data model object, when the user who is acting in the role user, attempted an update op- eration for which they were not authorised. The violation was detected as a result of a method authorisation check that was performed within the ‘authorisation preamble’ of the model’s update method. The quantity on hand value of -1000 which is displayed in both the ‘Edit a CD’ and ‘List All CDs’ dialogs, indicates an error in those GUI objects. The error was deliberately introduced for illustrative purposes, by making the data and method au- thorisation policies inconsistent. The method authorisation policy does not permit the invocation of getQOH while the data authorisation policy permits the ‘read’ opera- tion on the field qoh. The GUI objects use the data authorisation checks to determine which fields the user is permitted to view. Those fields for which the information should not be displayed, display distinguished ‘invalid data’ values. For an integer that value is -999. On the other hand, SDOs base their authorisation on method autho- risation. When the CompactDisc object, which encapsulates the information for the Revolver CD, performs an authorisation check in the preamble of getQOH, it fails. The CompactDisc accessor methods, return the appropriate the distinguished ‘invalid data’ value when authorisation fails. For research and debugging purposes, the Com- pactDisc accessor methods return different ’invalid data’ values than that used by the GUI objects (which import the value from the CompactDisc class). Thus, depending on the distinguished value displayed, the source of the authorisation failure can be derived.
5.3 Authentication and Authorisation in the CD Catalog Prototype
This section details the implementation of authentication and authorisation in the CD Catalog Prototype. In the initial prototype, an attempt was made to keep the imple- mentation as generic as possible, rather than relying on any Java specific services such as those provided by JAAS (see Section 3.2.6 for details). Consequently, authorisa- tion relied on a purpose built authorisation class rather than attempting to extend the services provided by JAAS to provide the required authorisation. An overview of the design of CD Catalog prototype is presented in Figure 5.3. The SDOs present within the prototype were: numerous CompactDisc objects, a Cat- alogModel object, a DataStoreRDB object and (when required) a CDFileFilter object. 5.3. Authentication and Authorisation in the CD Catalog Prototype 145
Essentially, the user authenticates to the SDOAuthenticator, and the relevant authori- sation credential is generated.
CatalogModel CD Client GUI DataStoreRDB Catalog SDO SDO
Main Security Policy
CompactDisc Edit Objects SDOAuthorisation Object/s Audit Policy List CompactDisc Objects Application Log SDOAuthenticator SystemLog Find CDFileFilter Object Class
Authentication Data
User
Figure 5.3: Overview of the Self-Defending CD Catalog Prototype
All SDOs delegate their authorisation decision making to their associated SDOAu- thorisation object that makes that decision on the basis of their subset of application’s security policy. The authorisation object always invokes the addToLog method of the SystemLog class to have the event logged. If required by the audit policy, the System- Log class will log the relevant authorisation event. In the following subsections, the key components of the access control subsys- tem are individually discussed, namely: the authentication mechanism, the credentials used for SDO-based authorisation, the authorisation mechanism, and the provision of audit services.
5.3.1 JAAS Authentication
Authentication in the CD Catalog program is based on the user providing a username- role-password triplet (by typing them into a dialog box). Upon successful authentica- tion, an UserID object14 is generated by the authentication subsystem, for use as an authorisation token on behalf of that user. Since the class structure and the authen- tication mechanism originally developed, closely mirrored the structure used within JAAS, the authentication subsystem was made JAAS compliant. In that way, the pro- gram would meet the standard normally associated with a Java SAA, without losing generality. Making the program JAAS compliant, has the added advantage that the
14The UserID authorisation tokens are discussed in Section 5.3.2.1. 146 Chapter 5. The SDO Concept in Java Non-distributed Applications
program could later be used to investigate the feasibility using JAAS authorisation as an alternative means of providing the authorisation services required by SDOs. The outcomes of that research is presented in Section 5.4. In the remainder of this section, the major components of the JAAS Authentication framework are identified, how those components work together is outlined, and finally how the CD Catalog program used JAAS authentication to authenticate its users is described. As already identified (Section 3.2.6.1), the JAAS framework is based on the con- cepts of principal, a name (possibly one of many) associated with a particular user, and subject, that encapsulates the collection of both principals and security credentials that are associated with a particular user. Within the SDO prototypes, each Subject object encapsulates a single UserID object (that implements the Principal interface). The most important information encapsulated in a UserID object are the unique identifier for the user and the role in which they were currently acting. Each time a user or their role changes, a new subject object (and its encapsulated Principal) is instantiated for that new role using the JAAS Authentication mechanism. The major components of the JAAS Authentication are:
• a LoginContext object the Java API provided class with which the application program interacts to facilitate the authentication of a user.
• a login module an authentication technology provider’s implementation of the LoginModule in- terface that supports their particular authentication technology, e.g. username- password, smart card or finger print scan.
• callback handler typically an application developer supplied class that enables a login module to communicate with the user to obtain authentication information.
• a login configuration file a configuration file that configures the LoginContext, identifying the one or more authentication technologies (LoginModules) to be used in association with the program and how they are permitted to interact with one another.
The key feature of the JAAS framework is that the program remains indepen- dent of the authentication mechanisms. This independence allows the application’s 5.3. Authentication and Authorisation in the CD Catalog Prototype 147 authentication mechanism to be changed, or even multi-factor authentication intro- duced, without having to make any changes to the application code. To achieve these benefits, the program is required to interact with the LoginContext, rather than directly interacting with the authentication service (or services). The single line command issued at the command prompt that is used to run CD- Program is shown in Listing 5.6. The command argument that appears on the second line of that listing, specifies that the JAAS configuration is contained in the file ‘lo- gin.config’.
Listing 5.6 Running the CD Catalog application catalogSDO.CDProgram java -classpath CDProgram.jar;. -Djava.security.manager -Djava.security.auth.login.config==jaas.config -Djava.security.policy==catalogSDO.policy catalogSDO.CDProgram
The contents of that file are presented in Listing 5.7. That configuration which has the name catalogSDO, specifies that the program: only requires single factor authenti- cation, that support for that authentication mechanism is provided by the login module common.security.SDOLoginModule, that the user must successfully authenticate with that login module for the authentication to be successful, and finally that no debug information should be written to the command console during the authentication pro- cess.
Listing 5.7 JAAS Configuration File jaas.config catalogSDO { catalogSDO.security.SDOLoginModule required debug=false; };
To complete the setup of JAAS authentication, the code within the program (CD- Program) must instantiate a LoginContext object, supplying as arguments to its con- structor: the name of the configuration, i.e. catalogSDO, and the required callback handler provided by the application to enable the login module to obtain the required authentication information from the user. A callback handler is any object which implements the interface javax.security .auth.callback., for this prototype a PasswordDialog object. An PasswordDialog ob- ject is manifested as the dialog, illustrated in Figure 5.4, which obtains a username- role-password triplet from the user. 148 Chapter 5. The SDO Concept in Java Non-distributed Applications
Figure 5.4: Dialog used for User Authentication - PasswordDialog
The code required to perform this instantiation of the login context, and then use that login context to authenticate the user is provided in Listing 5.8. The application is required to supply the callback handler because only the application knows how to communicate with the user. The callback handler for a non-GUI based applications might issue a username-password challenge on the command console, while a GUI based application might obtain the same information using a dialog box.
Listing 5.8 Code required to authenticate a user using JAAS Authentication // instantiate the callback handler PasswordDialog pd = new PasswordDialog(parent,windowTitle,message);
// instantiate login context, JAAS configuration name: catalogSDO lc = new LoginContext("catalogSDO", pd);
...
try { lc.login(); // attempt authentication return lc.getSubject(); // succeeded, return subject } catch (LoginException le) { return null; // did not authenticate user, return null } // try catch
Whenever a user needs to be authenticated, the application invokes the login method of the LoginContext object, which returns a Subject object containing the relevant au- thorisation credentials derived through the authentication process. In the case of the CD Catalog prototype, a Subject object encapsulating a single authorisation credential of type UserID, is returned. That authorisation credential is discussed next. 5.3. Authentication and Authorisation in the CD Catalog Prototype 149
5.3.2 Authorisation Credentials
Within an SAA, the identity of a user is established through the authentication process, and results in the creation of an authorisation credential that can be used to determine which of the application’s protected resources that user is permitted to access. Since the information within that token will not only be used for authorisation but also for audit purposes, as a minimum that credential must provide the following information: the unique identity of the individual user; if RBAC is being used, the role in which that user is currently acting; a non-forgeable signature attesting to the validity of the token; and finally the expiry date of the token. Depending on the particular requirements of the application program or the application domain, the token may also include other information deemed necessary. An identifying feature of SAAs which employ the SDO concept is the presence of an authorisation credential as a parameter, by convention as the first parameter, to any SDO method that accesses a protected resource. Within the SDO, that token’s infor- mation will always be required for audit purposes and, depending on the authorisation mechanism being employed, it may also be used by the SDO’s authorisation object (AO), to make the authorisation decision. Since Java programs are being considered there may be an additional requirement that the authorisation token is able to be used by a Java security manager to mediate access to system level resources. For SAAs, in which user-based authorisation plays a critical role, this requirement translates to compatibility with JAAS.
5.3.2.1 Authorisation Credentials used in prototypes
Candidates for use as an authorisation credential fall into two categories: user-defined tokens, or standardised tokens such as digital certificates or a Kerberos tickets. Within the prototypes developed by the candidate, a user-defined tokens is used. As the pur- pose of this research is to investigate the feasibility and then the implications of using the SDO concept, that design decision was made in an attempt to keep the prototypes as simple and flexible as possible. The use of a very simple token was adopted. The public methods of the class UserID, are presented in Listing 5.9. Only information considered essential for support both authorisation and audit, namely the identity of the user and the role in which they were acting, together with integrity related data in the form of a creation time, expiry time and a digital signature, were included in the 150 Chapter 5. The SDO Concept in Java Non-distributed Applications token15.
Listing 5.9 Public methods of the authorisation token class UserID.java public class UserID implements Principal { public UserID(String userName, String role, String timeStamp, String signature, String expiryDate); // getName needed to implement Principal (since RBAC return role) public String getName();
public String getUserName(); public String getRole(); public String getTimeStamp(); public String getExpiryDate(); public AccessControlContext getACC(); public void setACC(AccessControlContext acc);
public String toString(); // for debugging only! } // class UserID
Considering the importance of the UserID authorisation token, it would be ex- pected to do integrity checking before returning its encapsulated information, i.e. checking that it had not expired and validating the integrity of the digital signature. To ensure the confidentiality of cryptographic keys, the validation of the signature cannot be performed by UserID class, instead the cryptographic services provided by the SDO support environment are employed. The support environment, in turn, is likely to rely on support provided by dedicated hardware for the secure storage of cryptographic keys and related cryptographic computation. For efficiency reasons, it is unlikely that the computational expense of the perform- ing a digital signature check would incurred each time one of the UserID accessor methods is invoked. Rather, such computation would be used sparingly considering the number of authorisation checks being performed. Assumed that RBAC is being used, at most, integrity checking would be performed during object instantiation and within the getRole and getName methods (both methods return the user’s role). Con- sidering that only non-distributed SAAs are currently being considered, depending upon the sensitivity of the resources being protected, either no signature checking, or only checking on instantiation, might be performed. Where the sensitivity of the resources being protected is sufficiently high (or in distributed applications), preserving the confidentiality of such tokens might also be considered justified, i.e. the encryption of the tokens could be performed. In those
15The setACC and getACC methods relate to a particular mechanism for providing authorisation. At this stage, they can be ignored. Their significance will become apparent in Section 5.4.1.2.2. 5.3. Authentication and Authorisation in the CD Catalog Prototype 151 situations, the token passed to the SDOs might be a SealedObject (see Section 3.2.7.2), which encapsulates the ‘real’ authorisation token. No integrity checking was implemented in the CD Catalog prototypes, but in- tegrity checking was implemented in the distributed HRSystem prototype(see Sec- tion 6.4.2.2).
5.3.3 The Authorization Process
The resources that require protection within a program can be classified as either system-level or application-level resources. Within Java programs, the Java secu- rity framework is responsible for, and provides, the mechanisms required to secure system-level resources. Since such protection permeates the Java environment, in- cluding its integration into the relevant methods of the Java API, it is unlikely that an SAA developer will choose to use an alternative approach. The protection of application-level resources is however, somewhat different, in that the Java security framework is unaware of application-specific protected resources. SAA developers, consequently have the choice of either implementing an application- specific authorisation mechanism or tailoring the JAAS framework to extend its cover- age to include the required application-specific resources16. In this section, the former approach, that was taken in the initial version of the CD Catalog prototype will be discussed. The later approach is explored in Section 5.4. The protection of resources provided by SDOs is at the level of individual method calls and data member accesses. Because of the low-level nature of this protection, the number of authorization decisions required is potentially very large, so the autho- rization mechanism needs to be as lightweight as possible.
5.3.3.1 Providing Authorisation
An SDO’s associated AO is responsible for making authorisation decisions on behalf of the SDO. In the CD Catalog prototype, only one authorisation class was developed. Still, individual AOs are tailored during instantiation, to their particular SDO type. They are initialised with only that portion of the application’s security policy that is relevant to their associated SDO object. As discussed earlier in this chapter, both method and data authorisation are being used by SDOs within the prototype. One might expect that the AO would only pro-
16The third possibility of purchasing a third-party authorisation mechanism will be ignored, as from an application programmer’s perspective, it is likely to appear similar to an in-house developed system. 152 Chapter 5. The SDO Concept in Java Non-distributed Applications
vide two authorisation checking methods, one for each mechanism. These isAllowed methods are used by SDOs before they access a protected resource. As described in Section 4.3 and illustrated in Figure 4.3, whenever such an authorisation decision is made, details of the event are unconditionally sent to the audit object. The audit log object is responsible for determining whether the details should be recorded or discarded in accordance with the requirements application’s audit policy. That mech- anism will ensure that any access to an SDO’s protected resource, will be authorised and logged in accordance with the application’s security policy, prior to the access proceeding.
5.3.3.2 Providing Authorisation Queries
Parts of the program might need to make an authorisation inquiry to determine whether a particular access to a resource should be permitted, but have no intention of making that access. A user may, for example, request that a particular report be generated. That user is entitled to generate the report, and so the system will generate a view of the report tailored to the rights of that user. During that process, a series of ‘authorisa- tion queries’ will need to be made, to determine what protected information should be included within the report. Since such queries are not associated with protected infor- mation being obtained from the SDO, so it could be argued that the auditing of such queries is not required. Consequently, two additional isFieldAccessPermitted methods could be provided by AOs for such purposes. The procedural interface to the AOs is presented in Listing 5.10. The isAllowed methods perform method authorisation and contribute to the audit log, while isMetho- dAccessPermitted, the query version of those methods use data authorisation and are not logged.
5.3.3.2.1 Authorisation Queries - A Potential Security Problem The need for various parts of the program are able to determine whether an access to a protected re- source is allowed, without the query being logged, was discussd. The major reason for providing such functionality is that the program needs to be able to tailor its function- ality to the current user’s role without the generation of large numbers of unnecessary audit records. Without authorisation queries, to determine whether a particular access is permitted, an access attempt must be made and the outcome monitored. That mechanism has problems. Suppose an information record needs to be dis- played to a user. The GUI object must try to fetch each field to determine whether the 5.3. Authentication and Authorisation in the CD Catalog Prototype 153
Listing 5.10 Method Signatures for the class SDOAuthorisation public SDOAuthorisation(String whichObject);
// method authorisation public boolean isAllowed(UserID uid, String theObject, String method, String details); public boolean isMethodAccessPermitted(UserID uid, String method);
// data authorisation public boolean isAllowed(UserID uid, String theObject, String field, String operation, String details); public boolean isFieldAccessPermitted(UserID uid, String field, String operation);
access should be permitted. Consequently, audit records indicating that the user has attempted to access each of the protected data fields are generated, despite the user not attempting the access, the system made the access. The problem for auditors or security administrators to determine is whether on the basis of the audit trail, is an attack being mounted against the program’s protected resources or are the numerous audit records being generated by the normal operation of ‘the system’. However, the provision of such functionality by an SDO potentially has different and possibly more significant security ramifications. Rather than there being too much audit data, there is not enough. The authorisation query mechanism could allow an attacker to probe the system, to determine which SDO resources can be accessed by users acting in different roles, before launching the major attack. Since logging of such events does not occur, such probing can be carried out without leaving a trace. In the prototypes, this functionality has been provided, so that experience could be gained with its provision and use. However, having identified the potential problem with the provision of this functionality, this section will continue by discussing how this functionality could be provided. However, whether such functionality should be provided by a production system, is a major design decision that needs to be resolved on a case by case basis.
5.3.3.3 The CD Catalog Authorisation Class
The implementation of the authorisation class has little bearing on the demonstration of the viability of the SDO concept. The more significant aspect is the definition of the functionality to be provided, i.e. the programmer’s interface that would support 154 Chapter 5. The SDO Concept in Java Non-distributed Applications the provision of both method and data authorisation (that was been provided in the previous section).
Database Table methodAuthorisations object role method CompactDisc user getArtist CompactDisc user getProductCode CompactDisc user getTitle CompactDisc user getYear ...... Table 5.3: Extract from the Method Authorisation Table
Database Table dataAuthorisations object role rights field CompactDisc user read artist CompactDisc user read productCode CompactDisc user read title CompactDisc user read year ...... Table 5.4: Extract from the Data Authorisation Table
Within the prototype, a single authorization class which encapsulates two access control lists was developed. One list contains the method authorisation policy, while the other contains the data authorisation policy. When instantiating its AO, an SDO passes the name of the class to which it belongs as a parameter of the AO’s constructor. Using the SDO’s class name, the AO is able to only load that portion of the security policy that pertains to its associated SDO. In this prototype, the policy information is loaded from a Microsoft Access database. Presented in Tables 5.3 and 5.4 are extracts from the method and data authorisation database tables, show a portion of the security policy relating the SDO class CompactDisc and permissions granted to the role user. As illustrated by the policy information in the two tables, method and data autho- risation constitute alternative mechanisms by which a user’s right to access protected resources can be determined. As described earlier, it is believed that in the majority of cases17, method authorisation is sufficient to meet the authorisation needs of SDOs. In this prototype, method authorisation could have been used exclusively to meet all of the SDO’s access control requirements, however to gain experience in using data authorisation, that mechanism was used to implement authorisation queries that are use by the GUI objects and the update methods of the datastore and datamodel.
17For some applications, the use of an access control list is insufficient to meet the requirements of the security policy. 5.3. Authentication and Authorisation in the CD Catalog Prototype 155
After the authorisation information is loaded into an AO, subsequent authorization decisions are based on that, then static, policy information. Such a naive approach is only applicable to short lived non-distributed applications because any modifications to the security policy will not be reflected in the policy enforced by existing AOs. Another aspect of the provision of access control which was explored in this pro- totype was the consequences of using different SDO-AO models. To enable this re- search, the CompactDisc class, the only SDO class for which there were more than one or few object instantiated, was made configurable, so that two models could be adopted. The two models supported are: a dedicated AO for each SDO, i.e. each CompactDisc object has a dedicated AO, and a dedicated AD for each class, i.e. all CompactDisc objects share the same AO. The consequences of the authorisation model chosen, relate more to the run-time behaviour of the application than any philosophical advantage or any difference in the complexity or amount of coding required. If a single AO is used for all objects of the same SDO class, when the SDO objects are created, only one AO is instantiated, so the instantiation time for the SDOs is reduced. However, whenever an SDO needs to make an authorisation decision, all requests will be send to that one AO object. Consequently, that object will tend to be a bottleneck in multi-threaded programs. In contrast, when each SDO object has a separate AO, both more time and memory will be consumed during the instantiation of an SDO, but the possibility of a bottleneck during authorisation is reduced.
5.3.4 Audit - Logging Authorisation Events
The interaction between an SDO, its associated AO and the audit log was discussed in Section 4.3.2. In summary, AOs can make two kinds of authorisation decisions, those which are intended to be used before a protected resource is accessed (i.e. is this access permitted), and those which are authorisation queries (i.e. would this access be permitted). The only difference between the two kinds of authorisation decision is whether details of the event are sent to the audit log object. The audit policy deter- mines whether the event should be logged. In the prototype, the audit log was implemented by the class SystemLog, and Mi- crosoft Access databases were used for persistent storage of both the audit policy and the audit log itself. The SystemLog class provides services in the form of two static public methods addToLog and closeLog18. The method signatures for these two meth-
18Static methods were used, so that it was not necessary to instantiate an SystemLog object before 156 Chapter 5. The SDO Concept in Java Non-distributed Applications ods are presented in Listing 5.11.
Listing 5.11 Method Signatures for the class SystemLog public static void addToLog(UserID uid, String object, String event, String details, String success); public static void closeLog ( );
Since the provision of full audit facilities was considered to be out of the scope of this research, the functionality provided was minimal. The audit policy consisted of a list of events to be logged. An extract of the loggedEvents table is presented in Table 5.5. The extract specifies that both direct reads and writes to the qoh field of CompactDisc objects, together with invocations of the corresponding accessor and mutator methods, getQOH and setQOH, must be logged. The logging of only suc- cessful or unsuccessful events is not supported.
Database Table loggedEvents logEvent CompactDisc.qoh:write CompactDisc.qoh:read CompactDisc.setQOH CompactDisc.getQOH ... Table 5.5: Extract from the Audit Log Policy Table
An extract from the audit log is presented in Table 5.6. The log corresponds to information for CD #123 being displayed in the Edit Window, the quantity on hand (qoh) being updated by the user, the updated record being written to the data model and data store, and finally the CD list updated. The amount of authorisation being performed within the program is not apparent from the audit log. Recall, only accesses to the qoh data member are being logged. For each occurrence of getQOH that appears in the log, there were the correspond- ing accesses to all the other CompactDisc data members. Additional discussion of the difficulties of using the SDO concept in GUI-based programs is deferred until Section 5.5. In this section, the feasibility of implementing the SDO concept using one au- thorisation mechanism was demonstrated. To show that the successful application of the SDO was not reliant upon on the authorisation mechanism chosen, a version of making addToLog calls. 5.4. JAAS Authorisation and the CD Catalog Prototype 157
Database Table SystemLog thetime role user object operation success details 19/09/2005 5:41:14 PM manager j CatalogModel get true 123 19/09/2005 5:41:14 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j CatalogModel update true 123 19/09/2005 5:41:29 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j DataStoreRDB update true 123 19/09/2005 5:41:29 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j CompactDisc getQOH true 123 19/09/2005 5:41:29 PM manager j CompactDisc qoh:write true 123 ...... Table 5.6: Extract from the Audit Log Table the prototype based on an alternative approach was undertaken. Since Java provides support for developing SAAs within its security framework, that is based on secu- rity managers, access control contexts and JAAS, those mechanisms were extended to meet the authorisation requirements of SDOs. The next section discusses the de- velopment of that version of the CD Catalog prototype which employed JAAS-based authorisation.
5.4 JAAS Authorisation and the CD Catalog Prototype
This section discusses the use of JAAS authorisation, that was introduced in Sec- tion 3.2.6.2, to provide application-level mandatory access control in accordance with the SDO paradigm. The user-developed authorisation mechanism of the initial CD Catalog prototype, was replaced with a JAAS based implementation. No significant changes were made to the remainder of the program. The success of the conversion supports the belief that the SDO concept is sufficiently flexible to allow its widespread use in the development of SAAs. This section finishes by comparing and contrasting those two approaches.
5.4.1 Extending JAAS Authorisation to Non-System Resources
Within a Java program, executing code automatically acquires those permissions that relate to system level resources, that are granted by security policy. To extend JAAS authorisation to enable it to be used to control access to non-system resources (i.e. application specific resources) on the basis of who is requesting that access, two dif- ferent types of changes need to be made to the program code. Firstly the program must comply with JAAS authorisation requirements, and secondly for the Java Secu- 158 Chapter 5. The SDO Concept in Java Non-distributed Applications
rity Framework must be made aware of the application specific resources that require protection. Achieving these separate requirements is discussed next.
5.4.1.1 JAAS Authorisation
For program behaviour to be dependent on who is using it, the relevant thread must be associated with the user. In practice, a Subject object which encapsulates a particular users identities and credentials, needs to be associated with the thread. That association is made by invoking one of the two static methods of the Subject class provided for that purpose, doAs or doAsPrivileged. The method doAs creates a new thread and associates that thread with a combination of the current access control context and the permissions associated with the principals of the specified subject. Gong [91], describes the action of the security manager as: “When a JAAS Security- Manager must make an access control decision, it investigates the stack and retrieves all of the subjects associated with the operations on the stack. It checks and ensures that every subject on the stack is granted the permission.” Essentially this means that an access to the protected resources will only be granted, if all the users associated with methods on the call chain, are all permitted to access that resource. The doAsPrivileged method is used to temporarily raise privileges when trusted code is executing. The behaviour of the doAsPrivileged method is similar to that of the doAs method, except that the AccessControlContext supplied as a parameter to the call, is used to make access decisions, rather than all the subjects associated with operations on the stack. Consequently, the thread is permitted to perform actions that would otherwise be disallowed. This situation is analogous to making an operating system call whereby the thread is granted increased privileges because it is executing the trusted system code. Once the subject-thread association is established, whenever an attempt is made to access a system-level protected resource from within that thread, authorization will be based on the combination of those privileges associated with the process and that user. This change alone is insufficient to support the authorisation requirements of SAAs, as only access to system level resources are being mediated. To enable authorisation on non-system protected resources requires the use of user-defined permissions. 5.4. JAAS Authorisation and the CD Catalog Prototype 159
5.4.1.2 Protecting Non-System Resources
To make the Java Security Framework aware of an application-specific resources, user- defined permission classes need to be created. In the prototype, two user-defined per- missions classes, SDOMethodCallPermission and SDOFieldAccessPermission, were created. Both classes extended the abstract class java.security.Permission. A permis- sion is a “class representing access to a resource” [90] which has a name and often a number of actions associated with it. For example, the SDOMethodCallPermission class has no actions associated with it, while SDOFieldAccessPermission is associated with the actions ‘read’ and ‘write’. The two abstract methods implies and equals must be implemented by the programmer to allow the system to compare permissions. Listing 5.12 presents part of the JAAS security policy for the role user. It shows the granting of both SDO permission types, to that role. Notice that the name of the particular permission being granted follows the permission type, and that the action ‘read’ (but not ‘write’) has been granted to data authorisation related permission.
Listing 5.12 Part of the JAAS Security Policy for role user grant codebase "file:./CDProgram.jar", Principal catalogSDO.security.UserID "user" {
permission catalogSDO.security.SDOMethodCallPermission "catalogSDO.compactdisc.CompactDisc.getProductCode"; permission catalogSDO.security.SDOMethodCallPermission "catalogSDO.compactdisc.CompactDisc.getTitle"; permission catalogSDO.security.SDOMethodCallPermission "catalogSDO.compactdisc.CompactDisc.getArtist";
permission catalogSDO.security.SDOFieldAccessPermission "catalogSDO.compactdisc.CompactDisc.productCode","read"; permission catalogSDO.security.SDOFieldAccessPermission "catalogSDO.compactdisc.CompactDisc.artist", "read"; permission catalogSDO.security.SDOFieldAccessPermission "catalogSDO.compactdisc.CompactDisc.title", "read"; ... };
From a programmer’s perspective, permission checks are automatically called by the relevant methods of the Java API classes. However, internally those methods ex- plicitly initiate the permission check. Similarly, for an SDO to initiate an authorisation check for an application specific resource, it must invoke the checkPermission method of either the security manager or an AccessControlContext object. For both calls, an instantiation of the relevant user-defined permission class must be passed as a param- 160 Chapter 5. The SDO Concept in Java Non-distributed Applications
eter to that call. That object identifies which permission must have been granted for the authorisation to be deemed successful. To make the authorisation decision, check- Permission compares the required permission with those permissions associated with an access control context using the permission’s implies and equals methods. Those two versions of the checkPermission method behave quite differently. The security manager performs the permission check in the current context, i.e. by deter- mining whether the current thread has the permission being checked. In contrast, an AccessControlContext object determines whether the access would be permitted in its context.
5.4.1.2.1 SecurityManager Mediated Access Control In GUI-based SAAs, sig- nificant limitations apply to the use of the security manager mediated access control. In GUI-based programs, the operations requested by the user are carried out by the event handlers associated with the GUI components. Those event handlers run as sep- arate threads, so by default only execute with the privileges of the program, not with the privileges of the current user. Only by specifically creating a new thread which is associated with the user’s Subject object, will the user-specific privileges be acquired. Consequently, every time the system generates a new thread, yet another thread must spawned that is associated with the current user by making a doAsPrivileged call. That second thread then performs the required action in the context of the current user. Con- sequently, when using this access control mechanism, there is a significant increase in code complexity due to the need for thread creation. As importantly, in these GUI-based programs is the performance penalty associ- ated with the need to create the additional thread and the associated instantiation of an AccessControlContext. The performance penalty becomes prohibitive if SDOs are incorporated within the data models of GUI objects. Then the almost continuous re- rendering of GUI objects which occurs when they are moved over one another, causes significant delays. This topic is discussed further in Section 5.5. Consequently within GUI-based SAAs, the use of the security manager mediated access control is considered to be inappropriate.
5.4.1.2.2 AccessControlContext Mediated Access Control An AccessControlCon- text (ACC) object provides an alternative mechanism for performing permission check- ing. Before an access to a protected application-specific resource is to be accessed, an ACC which encapsulates the privileges of the program and the current user, is passed the permission to be checked. Importantly, neither a new thread created nor an ACC 5.4. JAAS Authorisation and the CD Catalog Prototype 161 instantiated each time the system spawns a new thread which accesses a protected resource. The use of ACC based authorisation is illustrated in Listing 5.13, where it is used to implement the doMethodPermissionCheck method in the CatalogModel SDO class. That listing also shows the use of doMethodPermissionCheck by that class’s update method. The example is the same as that presented in Listing 5.4. Notice that doMethodPermissionCheck method semantics have been preserved.
Listing 5.13 Using AccessControlContext-based Authorisation private static void doMethodPermissionCheck(UserID uid, String method, String details) { try { CDProgram.getACC().checkPermission( new SDOMethodCallPermission( "catalogSDO.CatalogModel."+method)); SystemLog.addToLog(uid,"CatalogModel",method,details,"true"); } catch (java.security.AccessControlException e) { SystemLog.addToLog(uid,"CatalogModel",method,details,"false"); throw new SDOSecurityException("Model: " + uid.getRole() + " no " + method); } catch (SecurityException e) { SystemLog.addToLog(uid,"CatalogModel",method,details,"false"); throw new SDOSecurityException("Model: " + uid.getRole() + " no " + method); } } // doMethodPermissionCheck public boolean update(UserID uid, CompactDisc cd) { doMethodPermissionCheck(uid,"update",""+cd.getProductCode(uid)); ... } // update
A convenient way to obtain an ACC object is by creating a thread running with the required privileges and making an AccessController.getContext call. That mechanism was used in the prototype, whenever a new user is authenticated. A code fragment showing that mechanism is presented in Listing 5.14. If the user is successfully authenticated (using JAAS authentication), the UserID object for the user is extracted from the returned Subject object. The doAsPrivileged method of class Subject is invoked to associate a newly created thread, that terminates immediately after a reference to its AccessControlContext object is obtained. Finally, the ACC object that encapsulates the privileges of the new user, is included within the authorisation token. Later, the authorisation token will be passed to SDOs. This mechanism has the advantage over mediating access using the security man- 162 Chapter 5. The SDO Concept in Java Non-distributed Applications
Listing 5.14 Obtaining an AccessControlContext private static AccessControlContext setACContext_acc;
userSubject = authenticator.authenticateUser(clientClassName); if (userSubject==null) { uid=null; } else { uid = authenticator.getUserID(userSubject); Subject.doAsPrivileged(userSubject, new PrivilegedAction() { public Object run() { setACContext_acc = AccessController.getContext(); return null; } // run }, null); uid.setACC(setACContext_acc); }//if
ager in that the expense of associating the thread with the user’s subject is only in- curred when a new user logs in, rather than every time a thread which accesses a protected resource is spawned. A problem associated with the GUI objects and the SDO paradigm, irrespective of how authorisation is performed, is discussed in the next section.
5.5 SDOs and Windowing Environments
Experience gained by developing the GUI-based prototypes identified two sources of potential problems associated with the use of windowing environments: the numerous threads generated within applications to support user interaction with the GUI, and the excessive authorisation that may occur when the SDO concept is employed.
5.5.1 Threads in Windowing Environments
The potential difficulties associated with the numerous threads used by the Java run- time were discussed in Section 5.4.1.2.1. Those difficulties are most pronounced when security manager mediated access control is used. Investigations have determined that programs in which SDOs delegate their access decision making responsibilities to AccessControlContext objects19 or programmer-defined authorisation objects, as af- fected by the problem, but to a much smaller extent. When an AccessControlContext
19The problem is avoided when the technique presented in Section 5.4.1.2.1 is used, but may not be avoided if ACCs are used differently. 5.5. SDOs and Windowing Environments 163 object being used to perform authorisation, irrespective of which thread is running, authorisation will be evaluated in the appropriate security context. In the case of a programmer-defined AO, the mechanism is inherently thread independent.
5.5.2 Excessive Authorisation Checking
An SDO performs an authorisation check before accessing a protected resource, which is precisely the behaviour required of an SAA. However, in GUI environments such behaviour can have some quite undesirable side effects, unless care is taken in the design of the data model of GUI objects.
5.5.2.1 The Source of the Difficulty
In a windowing environment, GUI objects are often re-rendered. Re-rendering occurs most often as the GUI object is being moved. For simple GUI objects, the rendering does not present a problem because the text or graphical data is stored in the GUI’s data model rather than the SDO being stored in the data model. In Java, the so called ‘Swing’ graphical components, are constructed using the Model-View-Controller (MVC) design pattern, which is currently the recommended approach for the design of GUI-driven programs. That design pattern “structures your application effectively because all logic for an application is separated from visible el- ements and the controller controls all interactions between them” [100]. Those Swing objects that are responsible for presenting significant amounts of data to the user, re- quire the programmer to supply a suitable data ‘model’. The Java API provides both default model classes and abstract model classes to help the application programmer provide the required data models. The programmer is only responsible for incorpo- rating the data to be displayed into the model and implementing those methods that allow the ‘view’ to obtain the data elements when they need to be displayed. In the prototype, the ListGUI object which displays the CD listing, is a component of this type. It essentially just encapsulates and supports the operation of a JTable, a Swing component provided by the standard Java API, to support the presentation of tabular data. Figure 5.5 shows the ListGUI/ JTable object which presents the CD collection as seen by a user acting in the role of user. Note that the QOH data is being withheld from a user acting in that role. In the prototype, the model for the JTable was created by extending the Java class javax.swing.table.AbstractTableModel. In relation to this discussion, the most signif- 164 Chapter 5. The SDO Concept in Java Non-distributed Applications
Figure 5.5: The ListGUI Object icant method is getValueAt, which returns the object located at the specified row and column in the table. When a cell within needs to redrawn, the model’s getValueAt is invoked to provide the view with the data to be displayed. Since the ListGUI object displays information about all of the CDs in the store’s collection, the naive approach would involve the model encapsulating a list of Com- pactDisc objects. When using that approach, the CompactDisc objects will ensure that only protected information which that user is permitted to see, will be displayed. Whenever the JTable cell needs to be redrawn, the getValueAt method will invoke the relevant accessor method of the object corresponding to the required row. If protected data is being accessed, the SDO will perform the mandatory authorisation check (that potentially causes that event to be logged), before returning the value to be displayed20. Assume the user decides to move or scroll the table. As the change is occurring, the view is continually re-rendered, to produce the apparent smooth movement of the table contents. Each time the table is re-rendered, each data member in each SDO whose data is visible needs to be accessed again. Each access of a protected data member requires an authorisation check, an audit policy check and potentially the generation and storage of an audit record. From both an efficiency and an audit standpoint, this situation is disastrous. 20In this prototype, the CompactDisc SDO adopts the recommended behaviour of returning a dummy value, rather than the requested information, when authorisation fails in one of its accessor methods. 5.6. Conclusions 165
5.5.2.2 A Potential Solution
A way to avoid efficiency and audit problems just identified, requires that the data being displayed is removed from the SDO collection and stored in a separate data structure that is used as the data model of the GUI object. Data will only need to be obtained from the SDOs when the data in the model requires modification, e.g. when the current user or their role changes. Initially, it might appear that this approach defeats the purpose of using SDOs. The data is now held within an object and access control is no longer being applied to that data. Importantly, the GUI object only contains that information which that user is entitled to see, so access control has been enforced. Also, in terms of entities within the program, the GUI object is ‘the user’, as its sole purpose to display information to the user. This approach was implemented in the CD Catalog prototype. The relevant data was extracted from the SDO collection and stored as a list (actually a java.util.Vector) of String arrays. Now, whenever a cell in the table required rendering, the getValueAt method of the data model returns the array element column from list element at the requested row position. Importantly, no authorisation checks need to be performed as a result of the re-rendering process, the reason for adopting this model.
5.6 Conclusions
The development of the CD Catalog prototypes demonstrated that the SDO paradigm can be used to develop SAAs. The rigor enforced by using the SDO paradigm was found to be sufficiently strong, that it was possible to successfully convert an existing non-SAA to an SAA. The application of SDO concept does not appear to require any language features that are peculiar to the Java language. In the development of the first version of the prototype, particular care was taken to avoid the use of any features that were Java specific. Thus, the successful application of the SDO concept, is believed to be inde- pendent on the Java environment. No object-oriented language features or enhancements are believed to be necessary to support the SDO concept. Two completely different ways of implementing authorisation were discussed in this chapter and implemented within the prototypes. It was established that only minor changes to the program code were required to change from one authorisation mecha- 166 Chapter 5. The SDO Concept in Java Non-distributed Applications nism to an orthogonal mechanism. Thus the independence of the SDO paradigm from the type of authorisation used, was also demonstrated. The development of the prototype highlighted the following aspects of the appli- cation of the SDO concept: • the clear separation of duty between the SDO, its authorisation object and the audit object needs to be maintained. Such separation both simplifies the design of SDO-based programs and also en- ables the reuse of the authorisation and audit classes. The responsibilities of these entities are: an SDO initiates the authorisation process before a protected resource is accessed and then enforces the authorisation decision made on its behalf; the AO is responsible for making the authorisation decision based on the application’s security policy and ensuring that the audit trail is appropri- ately updated; and the audit object is responsible for logging all authorisation decisions stipulated by the application’s audit policy.
• the AO should provide two kinds of authorisation services, authorisation checks and authorisation queries, if the amount of redundant audit information accu- mulated by the application is to be minimised. Authorisation checks are used by SDOs prior to accessing a protected resource, and so must be logged. An authorisation query is used by an SDO or other ob- jects, to determine whether a particular access should be allowed. They are not logged.
• method authorisation appears to be both intuitive to apply and sufficient to meet the authorisation requirements of SAAs. Data authorisation could either be used to supplement method authorisation or to meet the authorisation needs of SDOs. However its use is less intuitive. If data authorisation alone was to be used, it should be renamed to reflect the protection that it provides to protected functionality, i.e. a resource with execute rather than read and write operations associated with it.
• SDOs should not be used within the data models for GUI objects. If SDOs are incorporated within the data models of GUI objects, a large penal- ties can be incurred, in terms of both excessive authorisation and audit records generated, should the GUI object need to be repeatedly re-rendered. In this chapter, the development of the Java prototypes demonstrated that the SDO paradigm could be put into practice. By avoiding Java specific functionality in the 5.6. Conclusions 167 original prototype, the techniques used and the lessons learned should be more widely applicable. Problems that might arise during development were highlighted and sug- gestions solutions were provided. Following the completion of the first stage of the research, several major questions remained to be answered. Can the SDO concept be applied traditional distributed ap- plications? What about the increasingly important Web services environment? Can an SDO inheritance hierarchy be accommodated? The next chapter attempts to answer those questions. There the applicability of the SDO concept to distributed environ- ments is demonstrated, and then the strengths and weaknesses of the SDO concept are further explored. 168 Chapter 5. The SDO Concept in Java Non-distributed Applications Chapter 6
The SDO Concept in Distributed Java Applications
In the previous chapter, the SDO concept was shown to be applicable to the devel- opment of non-distributed security aware applications. This chapter continues that exploration of the SDO paradigm, by considering the applicability of the SDO con- cept to the development of distributed SAAs, the primary aim of the second stage of this research. The main focus of the associated research was devising mechanisms that would permit SDOs to be transmitted between client and server machines. In support of this research, prototypes based on two different distributed programming models were developed, to demonstrate the validity of the research. In the later sections of the chapter, the provision of several desirable features of SAAs are explored, to answer the following questions relating to limitations that the use of the SDO concept might impose on SAA development.
1. What impact does inheritance within SDO classes have on the application of the SDO concept?
2. Can the concept of usage rights (what a user is permitted to do with the in- formation made available to them by an SDO) be accommodated by the SDO paradigm?
3. What role can cryptography play in SDO-based SAAs?
4. What role, do aspect oriented programming languages, such as AspectJ, have in
169 170 Chapter 6. The SDO Concept in Distributed Java Applications
the implementation of the SDO paradigm?
The next chapter considers an orthogonal aspect of the application of the SDO concept, the provision of suitable environments in which SDO based SAAs can be developed and executed.
6.1 The HR System Prototype
An important aspect of the research is determine whether the application of the SDO concept places any limitation on the use of inheritance hierarchies. That aspect of the research could not have been explored using the CD Catalog prototype as it lacked of an SDO inheritance hierarchy. To address that deficiency, the distributed proto- type developed to support the second stage of the research, was based on a different scenario. The human resources scenario, introduced in Section 4.1, formed the basis for a second series of prototypes, the Human Resources Information System (HRIS) prototypes. The knowledge derived from the initial research and the development of the CD Catalog prototype, was harnessed to achieve the major aim of the research, the development of a purpose-build SDO-based distributed SAA. Two versions of the distributed SAA based on that scenario were developed. They only differed in the distributed programming model being used. One version used a traditional, proprietary-based distributed computing model, the Java Remote Method Invocation (RMI) model. That model was chosen to represent the traditional approach, because it is both commonly used for systems development and is fully integrated into the Java API. The other version of the HRIS prototype was based on the Standards- based, Web services model which is rapidly becoming the distributed model of choice. The Web services model was introduced in Section 2.2.
6.1.1 HRIS Overview
The HRIS design is based on the classic client-server model. In this scenario, Hu- man Resources staff normally access the information system on the local area net- work (LAN) using the Java RMI interface, while other system users employ the Web services interface as that interface provides universal access, i.e. users only required Internet access rather than access to the LAN. Figure 6.1 provides an overview of the HRIS. 6.1. The HR System Prototype 171
Non−HR Non−HR User Client User Client
Non−HR Non−HR Non−HR User Client User Client User Client Non−HR User Client
Web Services Interface Server
DataStore Web Services Application Personnel Database DataStore
RMI Interface
HR staff Client HR staff HR staff RMI Application Client HR staff Client Client
Figure 6.1: HRIS Overview
As shown in that figure, a separate version of the application was developed for each programming model, with both versions providing their users with identical func- tionality and user interface1. Each application has a server object that supports the relevant distributed programming model. That server object essentially reflects calls made to it to the DataStore object. As was the case in the CD Catalog, the DataS- tore implements the required call semantics by acting as an interface to the (Microsoft Access) ‘personnel database’. For clarity, the security-related aspects of the prototype have been omitted from the series of figures presented in this chapter. The same security architecture as that used in the CD Catalog prototype (Figure 5.3), is used within the servers and user clients of these applications.
6.1.1.1 SDOs and Authorisation in the HRIS Prototype
The SDOs identified within the information system are:
• the employee objects, classes Employee, Manager and Executive.
• the data store objects, class DataStore.
1In a production system, different user interfaces would be provided to HR staff and HR clients to reflect their different functional requirements. However in this prototype, to save development time, both classes of users were provided with identical user interfaces, with the functionality provided being dependent on the role assumed by the user. 172 Chapter 6. The SDO Concept in Distributed Java Applications
• the RMI server, class EmployeeServerImpl.
• the Web services server, class EmployeeWebServerImpl.
• the class used to convert between the SDOs and their non-SDO equivalents, class SDOClassConverter.
• the employee list object, class StringArrayList.
UserID objects are again used as the authorisation credentials and are logically unaltered. In this prototype however, support for integrity checking was implemented and other changes were required for the Web services version to make it compatible with the Web services model (see Section 6.4.2.2 for details). In this prototype, each SDO has a dedicated authorisation object (AO). That model was chosen purely on the basis that it was believed to be the more difficult to imple- ment2, so any problems that might exist would manifest themselves. The alternative approach would involve some sharing of AO instances, either an AO instance would be shared by all SDOs, or all SDOs belonging to the same inheri- tance hierarchy would share an AO. If either of those models was to be used, only the SDO would need to be transferred between machines. Upon arrival at its destination, the SDO would be associated with the relevant shared AO3 at its destination.
6.1.1.1.1 Authorisation Object Implementation Initially, the authorisation ob- ject implementation of the CD Catalog prototype was reused in this prototype. How- ever, it was soon apparent that the AO implementation was unsuitable. It was far too inefficient in terms of lookup time (during authorisation), memory usage and com- munication bandwidth. Each AO held a copy of that portion of the security policy that related to its SDO. The amount of data became particularly large when inheri- tance hierarchies were involved because the authorisation information relating to all classes in the hierarchy was required. The authorisation information for each permit- ted access consisted of a class-role-method triplet, e.g. <“Executive”, “hrmanager”, “getPerformanceBonus”>. The approach adopted for the HRIS uses a bit/ boolean array (a 64-bit long)to store all the permitted method accesses for a particular class-role combination, e.g.
2This model was believed to be more difficult to implement because whenever an SDO was trans- ferred between the client and server both the SDO and its encapsulated AO would need to be transferred. 3If an appropriate AO did not already exist, an AO would be instantiated to meet the needs of that and other SDOs of that type. 6.1. The HR System Prototype 173
<“Executive”, “hrmanager”, 137438199801>. This triplet replaced numerous triplets having the earlier format. This approach clearly traded readability for efficiency, and necessitated the development of a software tool to translate between the long integer and the permissions it represented. The change4 had minimal impact on the authorisation related code within an SDO (compared to that in the CD Catalog prototype). Listing 6.1 provides an extract from the Executive class showing one of the authorisation constants, the doPermissionCheck method and the code needed to initiate an authorisation check from within the method getSalary. Logically, the code only differs to that presented in Listing 5.13, in that the constant e getSalary, is passed to doMethodPermissionCheck rather than the method name, to act as the basis of the authorisation check.
Listing 6.1 Authorisation in the HRIS public class Executive extends Manager implements Comparable { ... public static final long _e_getSalary = 536870912L; ... private void doMethodPermissionCheck(UserID uid, long method, String details) { if (uid==null) { throw new SecurityException("Exe: nullUser no " + className + "." + method); } if (!authorisor.isAllowed(uid, className, method, details)){ throw new SecurityException("Exe: " + uid.getRole() + " no " + className + "." + method); } } // doMethodPermissionCheck () ...
doMethodPermissionCheck (uid, _e_getSalary,"getSalary");
6.1.1.2 The Development Tools used
The prototype was implemented in the Java programming language using Sun Mi- crosystems’ JavaTM 2 Platform Standard Ed. 5.0, which fully supports the RMI model. In the case of the Web services application, the JavaTM Web Services Developer Pack 1.5 (which includes the Tomcat 5.0 for Java WSDP Container) was used to provide Web services support.
4There was also the introduction of an additional class within the authorisation subsystem which cached the authorisation information read from the authorisation database. Consequently the expense of a database access and the formatting of that data was not incurred each time an AO was instantiated. 174 Chapter 6. The SDO Concept in Distributed Java Applications
Although the prototype was a distributed application, both the prototype develop- ment and experimentation were carried out on a single Pentium based system running Windows XP. It was possible to run the Web services server, the RMI server5 and more than one of each of the user clients on that one machine6. On the majority of occasions, however, only a single server and a matching client would be run7. The development of the HRIS was carried out in five stages: the development of a non-distributed version, its modification to produce the initial RMI-based prototype, the development of the Web services version of the prototype, a revised version of the RMI prototype8, and finally the two distributed prototypes were enhanced to further investigate the implications of adopting of the SDO paradigm. Each of those stages will be separately discussed in the following sections.
6.2 The Non-distributed Prototype
To allow sufficient time to concentrate on research questions, the functionality pro- vided by the prototype was restricted to an absolute minimum required to support the research, namely the addition, deletion and updating of individual personnel records and the provision of a list of all personnel records. As illustrated by the screen capture presented in Figure 6.2, the GUI is essentially the same as that used in the CD Catalog prototype. The main differences between the HRIS and the CD Catalog prototypes are:
1. The HRIS will eventually be distributed, so the datamodel of the CD Catalog prototype was removed and replaced by a class that acts as a front end for the server.
2. changes were made to the implementation of AOs.
3. the organisation’s staff members are classified into a three level hierarchy, em- ployees, managers and executives reflecting the additional benefits made avail- able to personnel at the higher levels. Consequently, the information maintained
5Both servers ran as the host ‘localhost’ (but on different ports), i.e. a host on the local machine. 6Care was taken to avoid simultaneous database accesses as the behaviour of an Access database under such conditions was unknown. 7Research driven enhancements would typically be made to the RMI version of the HRIS and then its compatibility with the other distributed model would be verified. 8The second version of the RMI prototype was developed after the serious security implications of making the SDO classes serializable, was realised. That problem is identified in Section 6.3.3.1. 6.2. The Non-distributed Prototype 175
Figure 6.2: The HR System GUI
for each of these employee categories differs. As much of the personnel infor- mation requires protection, those classes will be SDOs. The employee classes form a simple (linear) SDO inheritance hierarchy.
4. the HRIS can be configured to transfer the employee list as either a collection of individual SDOs or as a (single) list SDO. Being able to support both models enabled investigations into strengths and weaknesses of each approach.
5. cryptography has been used to secure the transmissions between client and server, and to enable integrity checking within the employee and UserID (au- thorisation credential) objects within the client and server processes.
The authentication, authorisation9 and audit subsystems developed for the CD pro- totype were essentially reused within the HRIS prototypes. The development of the non-distributed SDO-based prototype was not significantly more demanding than de- veloping an equivalent, non-security aware application. The benefit of using the SDO paradigm had became apparent. The interaction between the application and the au- thorisation subsystem was restricted to the SDOs, so the enforcement of the applica- tion’s security policy was relatively straight forward. User authentication was handled by a single method call to the authentication subsystem. Naturally, there were also minor increases in code complexity due to the need to manage authorisation tokens and handle security exceptions10. Assuming that the
9The changes that were made to the authorisation subsystem are identified in Section 6.1.1.1.1. 10In many cases, the security exceptions were handled along side, the other exceptions that might 176 Chapter 6. The SDO Concept in Distributed Java Applications
authentication and authorisation functionality is considered to be application infras- tructure rather than part of the SAA, having authorisation handled within the SDOs, meant that the implementation of the remainder of the SAA was not significantly dif- ferent to that of a normal application. The production of the non-distributed HRIS prototype, demonstrated that the SDO concept can be successfully applied to the development of purpose-built SAAs. The belief that the same process can applied to the individual components of a distributed application will be tested by attempting to split this application into client and server components. The main purpose for developing the distributed prototypes was to de- termine whether SDOs could be transferred between the client and server using the two commonly used distributed computing models that had been chosen. The next two sections, Sections 6.3 and 6.4, will be concerned with the mecha- nisms by which objects, and in particular SDOs, are able to be transferred between the client and server using the support provided by the Java RMI and Web services models.
6.3 The Initial RMI Prototype
An overview of the initial version of the RMI-based HRIS prototype is presented in Figure 6.3. That figure also shows the object types that are transmitted between the client and server as either method parameters or as return results. The RMI clients are responsible for providing the GUI (presented in Figure 6.2) that enables the user to interact with the server, i.e. invoke methods provided by the server, a Employ- eeServerImpl object. The server can be configured to transfer the personnel list as either a list (type StringArrayList) or a collection of individual records (types Employee, Manager and Executive). There is also a two way movement of individual personnel records, e.g. get results in the server returning the specified Employee object, while add and update involve the client sending an Employee object to the server. Authorisation credentials, UserID objects, are also transferred to the server. At the end of this section (Section 6.3.3.1), the security implications of using this particular RMI implementation, is identified. The revised RMI implementation, that overcame this deficiency will be discussed in Section 6.5.
arise at the same time for other reasons, e.g. the update of a personnel record might fail due to logical errors (the record does exist), system problems (network delays/ failures), or an authorisation failure. 6.3. The Initial RMI Prototype 177
Client ListGUI
EditGUI
Employee Objects RMIClient
StringArrayList Employee Objects UserID Objects Objects
EmployeeServerImpl Server
UserID StringArrayList Objects Employee Objects Objects
Personnel DataStore Database
Figure 6.3: Overview of the Initial RMI-based HRIS
The discussion of the initial RMI prototype has been included in the thesis, as it provides a simple introduction to the principles that underlay distributed computing models and so simplifies the discussion of the Web services and final RMI prototypes.
6.3.1 The RMI Model
Most proprietary mechanisms, including Java RMI, are restricted in its applicability. Java RMI is a Java specific mechanism, i.e. it only enables an object in one Java pro- gram to invoke a method of another Java object on a remote system. Until recently, Java RMI had been the mechanism of choice to support the distribution of Java appli- cations. Its popularity is now waning as the adoption of the Web services model gains momentum. Wigglesworth [100] describes the simplicity of use of the RMI model as follows: “RMI is a technology that allows programmers to directly call the methods of Java objects that reside on other systems. The fact that you are using remote objects is nearly transparent to you as a programmer”. After a reference to what is apparently a ‘remote’ object is obtained, that reference is used like any other object reference. In reality, that reference is to a ‘stub’ object, a system generated object, which provides the same methods as the remote object. Its role in Java RMI is discussed next. 178 Chapter 6. The SDO Concept in Distributed Java Applications
6.3.1.1 The RMI Mechanism
A remote method is invoked using the same syntax as a local method invocation. As shown in Figure 6.4, the mechanism by which that remote method invocation is achieved, is significantly more complicated. On receiving a message from a client, the stub object, rather than performing the necessary functionality itself, ‘marshals’ the parameters passed to it into a byte stream and transmits that byte stream to the remote system, typically over a TCP/IP socket. The process of converting primitive types and objects to a byte stream is referred to as ‘serialization’. For an object to be serialized, it must implement the marker interface11 Serializable.
message containing marshalling parameters as a unmarshalling message containing method parameters serialised byte stream method parameters Client Stub Skeleton Remote Object Object Object Object return result return result as a return result serialised byte stream Client Machine Remote Machine
Figure 6.4: The RMI Mechanism
At the remote machine, the byte stream is received by another system generated object, referred to as a ‘skeleton’ object. That object ‘unmarshals’ (deserializes) the byte stream to reconstruct the parameters which are then passed to the relevant remote object as a normal method invocation. The remote object performs the required oper- ation, and if required, a return value or exception is returned to the client object, by what is effectively, the reverse process. The byte stream only contains the data that is encapsulated within the objects being serialised, together with sufficient ‘mark up’ information to allow the objects to be re- instantiated at the destination. Importantly, bytecode is not transferred within the byte stream. Thus, objects are able to be transferred between the client and server. Having seen how objects, including SDOs, can be passed between the client and server, one aspect remains unresolved. How does the client obtain a reference to the stub object? Answering that question will be deferred until Section 6.3.2.5. There it will be answered in the context of its implementation in the RMI version of the HRIS prototype.
11“Marker interfaces have no methods. . . . The sole purpose of a marker interface is to attach a piece of type information to the class.” [100], i.e. the implementing class does not need to provide any specified functionality in order to implement the interface. In most cases, all that is required is that the class declare that it implements the Serializable interface. 6.3. The Initial RMI Prototype 179
6.3.2 Using RMI to Create the SDO-based HRIS
The conversion of a non-distributed SDO-based SAA to an distributed SAA is no dif- ferent to the conversion of a non SAA to its distributed equivalent. The RMI model is only concerned with supporting the distribution of applications, and so is not af- fected by the nature of the application being distributed. The underlying mechanism is sufficiently powerful, that SDOs as well as other objects and primitive types can be transmitted between the clients and server. The steps involved in performing that conversion which resulting in the creation of the initial RMI implementation will now be individually discussed.
6.3.2.1 Define the Server Interface
Listing 6.2 provides an extract of the Java interface, EmployeeServer, which is im- plemented by the server. Being the interface for an RMI server, the interface must extend the interface java.rmi.Remote. This requirement ensures that the server class will implement the required functionality needed to support the RMI mechanism. Additionally, each of the (remotely invoked) methods must declare that it throws java.rmi.RemoteException. This exception is used to convey communications or server problems to the client. The presence of the additional dummy parameter for the sec- ond load method results from a Java syntax restriction12.
Listing 6.2 Extract from Interface EmployeeServer public interface EmployeeServer extends java.rmi.Remote { public Collection load (UserID uid) throws DataStoreException, java.rmi.RemoteException; public StringArrayList load (UserID uid, boolean dummyParam) throws DataStoreException, java.rmi.RemoteException; public Employee get (UserID uid, String empNo ) throws DataStoreException, java.rmi.RemoteException; ... } // interface EmployeeServer
From a programmer’s perspective, an important aspect of this interface is that remote method invocations appear almost identical to their local counterparts. This includes support for the passing of objects, of arbitrary complexity, as parameters and
12In Java, it is not possible for overloaded methods to have the same parameter list, but different return types. Hence the additional parameter dummyParam, was added to make the method signatures of the two load methods, different. 180 Chapter 6. The SDO Concept in Distributed Java Applications their return as the result of method invocations. In the next section, the mechanism by which this is made possible will be briefly discussed.
6.3.2.2 Create a Server Class
The server class which implements the EmployeeServer interface presented in List- ing 6.2, is the EmployeeServerImpl class. Like many RMI server implementations, EmployeeServerImpl extends the Java API class java.rmi.server.UnicastRemoteObject, consequently it inherits the functionality required of a RMI RemoteObject, i.e. it “sup- ports point-to-point active object references using TCP streams” [100]. The imple- mentation of the services provided by the EmployeeServerImpl class are trivial. Each method uses the UserID authorisation credential passed as a parameter, to initiate an authorisation check (as discussed in the previous chapters) and if successful the rele- vant DataStore13 method is invoked and any result returned.
6.3.2.3 Generation of the Stub and Skeleton Class Files
The rmic software tool is provided as part of the Java Development Kit (JDKTM5.0) to generate the required stub and skeleton classes14 from compiled Java class files. The stub and skeleton class files generated from EmployeeServerImpl.class have the names EmployeeServerImpl Stub.class and EmployeeServerImpl Skel.class respectively.
6.3.2.4 Instantiate and Register the Server Object
At runtime, the EmployeeServerImpl program, like any other RMI server program, in- stantiates one or more server objects, and then registers them with a naming service. In this prototype, only a single RMI server is instantiated, and the Secure Sockets Layer protocol (SSL) is used to secure the byte streams being transmitted. The relevant code fragments from EmployeeServerImpl that perform these functions are presented in Listing 6.315.
13The DataStore implementation is a slightly modified version of its CD Catalog counterpart which supports the different SDO data types and an additional load method. 14As discussed in Section 6.3.1.1, the stub and skeleton classes are system generated classes which are responsible for the marshaling and un-marshaling of the parameters of the remote call. 15The RMISSLClientSocketFactory and RMISSLServerSocketFactory classes are not included within the standard Java distribution. They can be separately downloaded from Sun Microsystems’ web site [101]. 6.3. The Initial RMI Prototype 181
Listing 6.3 Instantiating the EmployeeServerImpl Server Object private static final int PORT = 2019;
// from main() Registry registry = LocateRegistry.createRegistry(PORT, new RMISSLClientSocketFactory(), new RMISSLServerSocketFactory()); registry.bind("EmployeeServer", new EmployeeServerImpl());
// from constructor super(PORT, new RMISSLClientSocketFactory(), new RMISSLServerSocketFactory());
6.3.2.5 Obtain a Remote Object Reference
To obtaining a reference to the remote object is straight forward. As shown in List- ing 6.4, it is essentially a two stage process; (1) the registry object for the particular server is located, and (2) the server reference is obtained from that registry. Two points should be noted regarding the process, firstly the lookup is performed using an alias (rather than the name of the class or something similar). In this prototype, the alias used is ‘EmployeeServer’. That alias is associated with the server object when it is is added to the registry and is quoted when clients attempt to find the server. The second point to note is that the object returned by the registry has the interface type, not the type of the object returned, i.e. its type is EmployeeServer not EmployeeServerImpl.
Listing 6.4 Obtaining a Server Object Reference String objectName = "EmployeeServer";
Registry registry = LocateRegistry.getRegistry( InetAddress.getLocalHost().getHostName(), PORT, new RMISSLClientSocketFactory()); empServer = (EmployeeServer) registry.lookup(objectName);
6.3.3 SDOs in a RMI Environment
The Java language provides all of the support required to enable the development of non-distributed SAAs, based on the use of the SDO concept. Similarly, with the support provided for the Java RMI model, the application of the SDO concept to the development of distributed SAAs is not restricted in any way. 182 Chapter 6. The SDO Concept in Distributed Java Applications
The only problem that was experienced when attempting to apply the SDO concept related to the transmission of AOs between the client and server. In the prototype, the memory requirements and hence the bandwidth required to transmit AOs were significantly larger than that required for the SDOs themselves. These problems were a direct result of the authorisation model used within the application. It is not necessarily a deficiency on the SDO approach itself. By shar- ing the authorisation object, which incidentally is the method normally used within current SAAs16, both the transmission and memory usage problems, disappear. In a different context where the information content of the SDOs exceeds the size of the authorisation data, this problem would not exist.
6.3.3.1 Serialization and SDOs - Potential Security Problem
Java’s support for serialisation on which the RMI mechanism is based, poses a security problem when applied to SDOs. To enable serialisation the class must declare that it implements the marker interface Serializable. Making such a declaration effectively grants the system permission to serialise objects of that class, when requested to do so. Should an SDO be declared as being Serializable, rogue code that has a reference to the SDO can by-pass its authorisation mechanisms, and gain access to its protected data. For example, the SDO could be passed to the writeObject method of the class ObjectOutputStream that will write a copy of the content of that SDO to the specified file. A mechanism for overcoming this problem involves the provision of a middleware layer that converts the SDO to a ‘normal’ object that contains the same information. That object can be safely serialised and consequently transferred using the RMI mech- anism. At the destination, the reverse process is performed. Although apparently sim- ilar, this situation is fundamentally different to its predecessor. Since the SDO is not serializable, it cannot be attacked as previously described. The normal object that is formed for it (and encapsulates the same data), only exists momentarily within the middleware layer on both the client and server side. Hence the possibility that it could be attacked by that mechanism is minimal, as the attacker will not be able to obtain a reference to it. An important consequence of this approach is that the middleware software will require sufficient privileges to enable it to access (read and update) all protected data
16Since SAAs do not currently employ the SDO concept, authorisation will typically be performed by a centralised object. Only when the SDO concept is applied, does a framework for having numerous AOs exist. 6.4. The Web Services Prototype 183 members within the relevant SDOs. In the next section, the applicability of the SDO concept in Web services environ- ment will be discussed. Under that distributed computing model, there is no ‘system support’, akin to serialisation, that can be utilised to extract the data from an SDO. Thus, the transmission of an SDO, is significantly more difficult and relies on an ar- chitecture similar to that just suggested.
6.4 The Web Services Prototype
The Web services model is becoming the distributed computing model of choice. Its popularity is well deserved as it is a Standards based model and employs XML- based messaging, which gives Web services the potential to integrate information sys- tems written in different programming languages and running on different platforms17. However, there is a significant trade off of both program complexity and message size to achieve this system independence. More detailed information about Web services was provided in Section 2.2 (and references [3, 17, 21–23, 102–108]). This section however, is not concerned with virtues or otherwise, of the Web ser- vices model, but instead to demonstrate the compatibility of the SDO concept and that currently popular Web services distributed computing model. As the compatibility of the SDO concept with the Java RMI model has been demonstrated, it concentrates on the transmission of SDOs between the client and server in Web services based applications. The tools of the Java Web Services Developer Pack (JWDP) were created to ad- dress the need to easily integrate a Web service into a distributed application. Avail- able software tools generate all the classes needed to support the communications between the client and server from the WSDL description of the service (see Section 2.2.2). Because of the complexity of WSDL descriptions, in the prototype, the WSDL description for the server was generated from the Java interface EmployeeServer us- ing the JWSDP tool wscompile and the configuration file xml gen config.xml. The command used to run wscompile, its configuration file, the original EmployeeServer interface and the WSDL file generated, are all presented in Appendix A.
17This contrasts with the Java RMI model that only supports message passing between Java objects. 184 Chapter 6. The SDO Concept in Distributed Java Applications
6.4.1 A Web Services - SDO Mismatch
When using RMI, the translation of an object to the byte stream is achieved using serialisation. Serialisation is built into the Java runtime environment, so the data en- capsulated in an object can be extracted by directly from the runtime data structures. There is no need to use the object’s accessor and mutator methods, so an SDO can be serialised18 as easily as any other object. The situation when using the Web services tools is completely different. For an object to be transferred, the data stored must be ‘read’ using the object’s accessor methods, in order for that data to be included within a SOAP message. At its des- tination, a new object is instantiated using the object’s default constructor and then each of the mutator methods are invoked to initialise the object’s data members. Con- sequently, the class of any object which is to be transferred must have the following properties:
1. the class must provide an accessor and mutator for every data member,
2. the class must provide a default (i.e. zero parameter) constructor, and
3. the class must provide a constructor which takes all of the data members as parameters.
To assist the application builder, development tools of the JWSDP, automatically generate the source code for all classes identified within the WSDL description of the Web service as being parameters or return values. As the classes are system generated, they cannot be modified. The design of SDO classes is orthogonal to such requirements. The defining char- acteristic of an SDO is that it performs access control on its resources, so the presence of an accessor and a mutator method for each data member, which do not perform authorisation, cannot be tolerated.
6.4.1.1 The Client Solution
Objects in a distributed application are not in reality, transferred between systems; they only ‘appear’ to be transferred. Instead the data that they encapsulate is transferred and a new object is instantiated at the destination using the transferred data. In different distributed models, that data is transferred using different mechanisms. In the Java
18The security concerns regarding SDOs and serialisation was raised in Section 6.3.3.1 and a possible solution suggested. 6.4. The Web Services Prototype 185
RMI model, that data is transferred as a byte stream, while the Web services model transfers that data as text within a SOAP message (see Appendix B for a sample SOAP message). The provided tools supporting the Web services model cannot be used to transfer SDOs as outlined above (Section 6.4.1). A typical solution to such a problem would be to allow the Web services infrastructure, to transfer a ‘normal’ object. The SDO class would be a subclass of the transferred type, and the problem is solved. That approach is used to handle the transfer of UserID objects. Unfortunately, the approach will not work for SDOs. The SDO class would inherit the accessor and mutator methods which do not perform authorisation. Its protected data members can be accessed via those methods, which do not perform authorisation. It would not be an SDO! Like many problems in Computing Science, this problem can be solved through the provision of a higher level of abstraction. By incorporating a middleware/ software layer that sits above the Web services infrastructure, a higher level of abstraction than that provided by the Web services model is created, that supports the transfer of SDOs. Figure 6.5 presents the architecture used in the Web services version of the HRIS.
WebClient
UserID Employee StringArrayList Objects Objects Objects
HRWebServicesConnection SDOClassConverter
NonSDOStringArrayList Client Objects NonSDOEmployee Objects SOAPUserIDsuperClass messages Objects Server
EmployeeWebServerImpl
StringArrayList Employee Objects UserID Objects Objects SDOClassConverter Personnel DataStore Database
Figure 6.5: Transferring SDOs in a Web Services Environment
On the client side, that middleware is implemented as the HRWebServicesCon- nection class. To access a remote service, the client application invokes HRWebSer- vicesConnection methods, rather than those of the ‘real’ server. As this is a local class, the (client) application developers are able to pass SDOs as parameters and/or receive 186 Chapter 6. The SDO Concept in Distributed Java Applications
SDOs as return values. Listings 6.5 and 6.6 provide corresponding extracts from the public interface of the HRWebServicesConnection class and the Web services server respectively.
Listing 6.5 Extract from Class HRWebServicesConnection public class HRWebServicesConnection { public HRWebServicesConnection(); public StringArrayList load(UserID uid, boolean dummy) throws DataStoreException ; public Collection load(UserID uid) throws DataStoreException ; public Employee get(UserID uid, String empNo ) throws DataStoreException ; ... } // class HRWebServicesConnection
A comparison of those listings shows that the HRWebServicesConnection services mirror those provided by the server. The methods of the HRWebServicesConnection class provide common behaviour that can be summarised as follows: for each SDO passed as a parameter, instantiate its non-SDO equivalent19 using the information con- tent of the SDO, and when finished invoke the corresponding method of the server. Non-SDO parameters are forwarded unchanged. Return values are handled by effec- tively reversing the process. In the prototype, a separate SDOClassConverter object is used to perform the relevant conversions between SDOs and non-SDOs.
Listing 6.6 Extract from Interface EmployeeServer public interface EmployeeServer extends java.rmi.Remote { public NonSDOStringArrayList load (UserIDsuperClass uid, boolean dummyParam) throws DataStoreException, java.rmi.RemoteException; public NonSDOEmployee[] load2 (UserIDsuperClass uid) throws DataStoreException, java.rmi.RemoteException; public NonSDOEmployee get(UserIDsuperClass uid, String empNo) throws DataStoreException, java.rmi.RemoteException; ... } // interface EmployeeServer
The source code of the get method, which is presented in Listing 6.7, illustrates this behaviour that results the return of an Employee SDO, as the method return value. Depending on the implementation details, the methods of the SDOClassConverter class may need to invoke the constructors, together with all accessor and mutator
19The term ‘non-SDO equivalent’ is used to denote a class that encapsulates data members having the same names and types as the specified SDO. 6.4. The Web Services Prototype 187
Listing 6.7 The Method HRWebServicesConnection.get public Employee get(UserID uid, String empNo ) throws DataStoreException { try { NonSDOEmployee nonSDOEmp = webServer.get(uid, empNo); return SDOClassConverter.convertToSDOEmployee(suid,nonSDOEmp); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); } // catch }//get
methods of all of SDOs that is responsible for converting. Consequently, that object will require the privileges needed to invoke all of those SDO methods. In the proto- type, those privileges are associated with the role SU. In the prototype, the approach taken was to require the administrator who executes the client program (and elsewhere the server program) to authenticate into that role and the authorisation token generated would be used by the middleware software20. Consequently, to successfully execute the client program of the Web services prototype, the administrator must: (1) authen- ticate into the role creator, to access the privileges required to instantiate the objects that allow the client side application to run, and (2) authenticate into the role SU21.If that administrator also wishes to use the application, she must then authenticate into the required user role. In the prototype, both the HRWebServicesConnection and the SDOClassConverter classes were ‘hand coded’ specifically for this application. The complete source code for the classes HRWebServicesConnection and SDOClassConverter are provided in Appendices C and D respectively. In an SDO production environment, the SDO Support Environment would be expected to provide a software tool to generate these classes (and their server-side equivalents), just as the numerous classes needed to sup- port the Web services model are generated by the Java WSDP tools.
6.4.1.2 The Server Solution
On the server side, a similar approach is employed to that on the client side. In this prototype, the class EmployeeWebServerImpl provides both an implementation of the server interface and is also responsible for interfacing the non-SDO aware Web ser-
20The alternative approach would be to have the system generate the required authorisation credential using a mechanism that bypasses the authentication subsystem. 21The UserID object instantiated is immediately passed to and thereafter used by the class converter. 188 Chapter 6. The SDO Concept in Distributed Java Applications
vices infrastructure with the SDO aware server application. Since this class provides protected functionality, it is an SDO. By performing an authorisation check in each of its methods, this SDO protects the server, from the potential load caused by having to partially process unauthorised requests. Once the required parameter translations are performed, the appropriate DataStoreImpl method is invoked to perform the requested operation. As shown in Figure 6.5, the parameter conversion at the server is delegated to an instance of the same SDOClassConverter class as that used on the client side.
6.4.2 Special Classes for the Web Services Prototype
Application code running on both the client and server machines, apply the SDO paradigm, i.e. know about and use SDO objects of types Employee and StringAr- rayList, and UserID objects. Since the Web services infrastructure is unable to handle SDOs, those classes manipulate the corresponding WSDP compliant classes; NonS- DOEmployee, NonSDOArrayList and UserIDsuperClass22. The middleware layer is responsible for providing the interconnection of these otherwise incompatible appli- cation subsystems. The next subsection will discuss the role of the SDO and non-SDO classes in enabling the transfer of SDOs within SOAP messages and authorisation credential conversion and the associated integrity checking.
6.4.2.1 SDO and ‘NonSDO’ Classes
Even though they are both effectively holders for information, an SDO such as a Man- ager object is fundamentally different to its non-SDO equivalent, a NonSDOEmployee object. A Manager SDO performs access control on its encapsulated protected con- tent by restricting access to selected methods, it is a member of a class hierarchy and it attempts to monitor the integrity of its protected content. In contrast, a NonSDOEm- ployee object only provides constructors and a pair of accessor and mutator methods for each data member. In this section, only the conversion of a class to its counter- part, will be considered. The separate issue of using cryptography to provide integrity guarantees is discussed in Section 6.7.1.3. A NonSDOEmployee object encapsulates a set of data members that correspond to the union of all data members declared in all of the Employee classes. Consequently,
22Those WSDP compliant classes are automatically generated from the WSDL description of the Web service which includes a description of those classes. Their class descriptions begin about 40 lines into the WSDL EmployeeServer description that is presented in Appendix A.4. 6.4. The Web Services Prototype 189 that one class acts as the non-SDO equivalent for the entire Employee class hierar- chy. It also has an additional data member, which stores the type of the Employee object that it represents. Listing 6.8 presents the code for the static method SDO- ClassConverter.convertToSDOEmployee which converts a NonSDOEmployee object to the appropriate type of Employee object. As shown that process involves obtaining the value of each data member from the non-SDO object and then using those values to instantiate the Employee object.
Listing 6.8 The Method SDOClassConverter.convertToSDOEmployee public static Employee convertToSDOEmployee(UserID uid, NonSDOEmployee employee) { Employee emp; doMethodPermissionCheck(uid,"SDOClassConverter", "convertToEmployee");
// set the common fields String empType = employee.getEmpType(); Vector methodAuths = employee.getMethodAuthorisations(); long SDOPermissions = employee.getSDOPermissions( ); String empNo = employee.getEmpNo( ); String name = employee.getName( ); String phone = employee.getPhone( ); String position = employee.getPosition( ); long salary = employee.getSalary( ); String homePhone = employee.getHomePhone( ); Vector signature = employee.getSignature( );
// instantiate the Employee object and set type specific fields if (empType.equals("Executive")) { emp = new Executive(uid, empNo, name, phone, position, salary, homePhone, employee.getCarDetails(), employee.getPerformanceBonus(), methodAuths, signature,SDOPermissions); } else if (empType.equals("Manager")) { emp = new Manager(uid, empNo, name, phone, position, salary, homePhone, employee.getCarDetails(), methodAuths, signature, SDOPermissions); } else if (empType.equals("Employee")) { emp = new Employee(uid, empNo, name, phone, position, salary, homePhone, methodAuths, signature, SDOPermissions); } else { // unknown type throw new RuntimeException("SDOClassConverter" + ".convertToSDOEmployee-unknown NonSDOEmployee type"); } return emp; } // convertToSDOEmployee 190 Chapter 6. The SDO Concept in Distributed Java Applications
The other class conversions are performed in a similar manner. The systematic nature of the code, supports the previously expressed view that a software tool could be developed to generate the class or set of classes, needed to perform the type con- versions required to support the operation of a particular server. By introducing a level of abstraction above that provided by the standard Web ser- vices infrastructure, the middleware software facilitates the transfer of SDOs between the individual systems on which a distributed SDO-based SAA resides.
6.4.2.2 Authorisation Credentials
In the Web services prototype, the authorisation credentials, UserID objects, also have a Web services compliant counterpart namely UserIDsuperClass objects. Both classes contain identical information namely: the role of the user; the userName of the user, the unique system wide identifier for a user; the expiryDate of the token; and the signa- ture generated by the authentication service to certify the authenticity of the previous fields. With this pair of classes, the problem is not that the UserID methods perform authorisation, but rather that they must provide additional functionality. Since no data protection is required, the UserID class is able to extend the UserIDsuperClass class, adding integrity checking functionality and an additional signatureValid field (to enable the more efficient handling integrity checking). The UserID objects in both the RMI and Web services applications are ‘logically’ equivalent. However the RMI version of the class does not extend another class23 and does not include the set of mutator methods that are needed by WSDP tools. The algorithm used for integrity checking is that proposed in Section 5.3.2.1. In- tegrity checking is carried out as a multi-step process, with each step being more computationally expensive than its predecessor. Firstly, the setting of the internal va- lidity flag signatureValid is used to determine whether on the basis of previous checks, the credential is believed to be valid. If the flag indicates that the data is valid, the ex- piry date is checked; and finally if the credential is still current, the digital signature is checked to verify the current validity of the credential’s content24. By recomputing the digital signature and comparing it to the stored signature, any modifications to the cre- dential by an attacker are detectable. Should any of these tests fail, the signatureValid flag is cleared and for extra security, the role field is changed to a message (“Invalid
23Other than Object, which all objects must extend. 24Signature checking is discussed in Section 7.3.4 6.4. The Web Services Prototype 191
UserID signature for ” + userName). Signature checking is a computationally expensive operation, so for efficiency, it is only performed in the getRole and getName methods which return the role of the user, i.e. when the credential is being used for authorisation. UserID objects also provide information needed for the creation of an audit record. Such accesses typically occur in rapid succession immediately after the role information has been accessed, so performing a signature check for all accesses was considered to be unnecessary. Integrity checks are not performed when the UserID’s mutator methods are in- voked. The mutator methods should only by used by the WSDP tools, when the data members including the signature, are initialised one at a time after the instantiation of the UserID at its destination. When the methods are used in this manner, an integrity check (if performed) would fail on most occasions as only some of the data members would have been initialised at that time. Signature generation is never performed, as the signature is generated by the authentication authority, not the UserID object.
6.4.3 Observations Regarding the Web Services Prototype
The development of the Web services version of the HRIS prototype, demonstrated that the SDO concept can be used in conjunction with the Web services model. Like all Web services applications, there is a significant trade off of both program com- plexity and message size in order to achieve system independence. For example when invoking a server method, a large message is needed to describe, in XML, the details of the method being invoked including the types of its parameters and their values in a system independent manner. Such a message, the message sent to invoke the get method which takes a UserIDsuperClass object as a parameter, is presented in Appendix B.1. The response message, shown in Appendix B.2, is even larger as the information content of the returned NonSDOEmployee object, which includes autho- risation data, must be encoded. The remote method invocation requirements of non-SDO based applications are fully supported by the available toolkits. However, those toolkits cannot be used to transfer SDOs. The tools use accessor and mutator calls, to disassemble and later reassemble any object being transferred. By performing authorisation and having an additional parameter, accessor and mutator methods of SDO are incompatible with these tools. However, as described in this section, the introduction of a higher level of abstraction, and the provision of the relevant middlware software layer that interfaces the SDO-based application to the Web services infrastructure, successfully overcomes 192 Chapter 6. The SDO Concept in Distributed Java Applications
the apparent incompatibility. The next section, will discuss the reuse of this middleware architecture, in the implementation of a more secure RMI prototype.
6.5 The RMI Prototype
The initial RMI prototype suffered from the security flaw that was identified in Sec- tion 6.3.3.1. That flaw arose as a direct result of declaring SDOs as being Serializable, to make them compatible with the RMI distributed computing model. It should be noted that making a class as being Serializable, is not normally con- sidered to be a security flaw. Classes typically provide a set of public accessor and mutator methods that provide access their information content, so there is no inher- ent breach of security by making them Serializable. The security problem is pecu- liar to SDOs. They do not provide ‘normal’ access to their protected data. Instead, their methods perform authorisation before providing access to protected information. Since SDOs do not provide unrestricted access to their data, declaring them as being Serializable constitutes a security flaw (i.e. it provides a mechanism for bypassing the object’s authorisation mechanisms), which does not apply to other objects.
6.5.1 Implementing the RMI Prototype
The revised RMI prototype design is based on the communications architecture that was developed to support the implementation of the Web services prototype. By com- paring Figures 6.5 and 6.6, it is apparent that the only difference between the two architectures, is the mechanism used to transfer the SDO’s information content. In the Web services prototype, the information is transferred in SOAP messages, while the RMI prototype transfers that data as a serialized byte stream. The changes required to incorporate the new communications architecture into the initial RMI prototype, were not significant. The RMI server implemented the Employ- eeServer interface, that was used in the Web services prototype (see Listing 6.6), so much of the ‘middleware code’ developed for that prototype was able to be reused. The middleware classes were either imported (unchanged) into the RMI prototype, or merged with the RMI code from the initial RMI prototype, to create the programming model specific classes. The remainder of the prototype’s implementation remained unchanged. 6.6. Securing Network Communications 193
RMIClient
UserID Employee StringArrayList Objects Objects Objects
HRRMIConnection SDOClassConverter
NonSDOStringArrayList Client Objects NonSDOEmployee Objects SerializedUserIDsuperClass Data Objects Server
EmployeeServerImpl
StringArrayList Employee Objects UserID Objects Objects SDOClassConverter Personnel DataStore Database
Figure 6.6: Overview of the RMI-based HRIS
The main difference between this prototype and its (RMI-based) predecessor, is that neither the Employee classes, nor StringArrayList class, are declared as being Serializable. Their non-SDO equivalents are serializable so they can be transferred between the client and server using the RMI distributed programming model infras- tructure. Being Serializable is not considered to be a problem for these classes. Their objects are instantiated, immediately passed to the server stub that serializes them, and thereafter they become unreachable. At no stage does a reference to these objects pass outside the trusted code of the Java API or the middleware layer. The use of the middleware layer, once again has allowed SDOs to be transferred between the client and server without having to make the SDOs Serializable. The next section, will discuss the securing of the network communications. This is the last of the sections of this chapter which specifically deal with distributed appli- cations. The remainder of the chapter investigates what consequences the use of the SDO paradigm has on the implementation of inheritance hierarchies, usage rights and object lifetimes. A final section discusses the possible usefulness of an aspect oriented language, such as AspectJ, to the implementation of the SDO concept.
6.6 Securing Network Communications
Security mechanisms supported by the Java environment have been used in this proto- type to secure network traffic. Both of HRIS prototypes use the Secure Sockets Layer 194 Chapter 6. The SDO Concept in Distributed Java Applications
(SSL) to provide session level protection, while the Web services prototype can also be configured to use encryption and/or signing of SOAP messages at the application level. To provide the level of abstraction needed to deal with the complexity of network communications, data communication is viewed as a multi-layered process. Each layer is responsible for providing a different level of abstraction to the communication process. By building on the services provided by the underlaying layer, each layer is able to provide services at a higher level of abstraction to the layer above. The OSI Reference Model (Network Stack) provides a framework based on specification seven of distinct layers, the services to be provided by each layer, and the required inter-layer interfaces. The construction of communications hardware and software in accordance with this reference model, enables products developed by one vendor inter-operate with products from other vendors. In relation to the provision of secure communications within the prototypes, two important layers are the ‘session’ and ‘application’ layers. At the session layer, layer 5, reliable secured communications between two directly linked communications devices can be established. The SSL protocol is used in both versions of the HRIS prototype, to secure the exchange of messages associated with remote method invocation. It is the most commonly used security related protocol and provides ‘point to point’ confidentiality and integrity guarantees. The application layer (layer 7) which is at the top of the network stack, deals with provision of a reliable communication channel between individual applications run- ning on different computers connected by a network of arbitrary complexity. Security incorporated at this layer provides ‘end to end’ security guarantees. At this level, that the Web services tools provide additional security guarantees through the encryption and/or signing of SOAP messages.
6.6.1 Securing Communications in the RMI Prototype
Only SSL was used in the Java RMI prototype, since RMI is a low-level point to point mechanism for providing remote procedure call semantics. Section 6.3.2.4 outlined the mechanism by which SSL secured communications were established between the client and server. If desired, cryptography could also be applied at the application layer, using one of the following mechanisms:
• changing the server interface, so that Java SignedObjects and/or SealedObjects, 6.6. Securing Network Communications 195
rather than ‘normal’ objects, are used as parameters and return values25.
• customising the serialisation process. By providing a pair of matching readOb- ject and writeObject methods for those classes that have objects being transmit- ted, the desired cryptographic techniques can be applied during the generation and interpretation of the transmitted byte stream. (The RMI process and serial- isation were discussed in Section 6.3.1.1.)
Thus if desired, cryptographic techniques can be applied at the application, as well as the session layer, to secure the network communications of the RMI prototype.
6.6.2 Securing Communications in the Web Services Prototype
The adoption of the Web services model was initially hampered by the lack of security, so considerable work was invested in the establishment of security standards for the securing of Web services communications. The subsequent development of software tools which conform to these standards, has meant the securing of SOAP messages, at both the application and session layers, has become mainly a declarative rather than a programming task. The Java Web Services Developer Pack 1.5, which was used to develop the Web Services version of the HRIS prototype, is an example of such a Web services toolkit. When using that toolbox, encryption of SOAP messages by the server is enabled, by passing the security configuration file “encrypt-server.xml” (Appendix E.1) to the software tool wscompile as the security argument. That tool then generates the server side classes needed to support the exchange of encrypted SOAP messages. Similarly, the configuration file “encrypt-client.xml” (Appendix E.2) is used when generating the client side classes. Appendix E shows the effect of enabling application level encryption on the SOAP messages sent to request a record ‘delete’. The first SOAP message, presented in Appendix E.3, is an unencrypted ‘delete request’ message, while the second message, Appendix E.4, is the encrypted version of the same “delete request” message. Note the inclusion of a specification of the type of encryption and key used, are included within the message in plain text so that the message can be decrypted. Both SOAP messages were captured at the server.
25A SignedObject encapsulates another object and a digital signature, and so provides integrity guar- antees on the object. A SealedObject encapsulates an encrypted object, so provides confidentiality guarantees. These objects were discussed in some detail in Section 3.2.7. 196 Chapter 6. The SDO Concept in Distributed Java Applications
6.7 SDOs and Inheritance Hierarchies
The need to make all data members in an SDO private was identified in Section 4.4.1. In this section, the implications of that approach to the construction of SDOs, will be discussed. With data members declared as private26, a subclass (and all other classes in the same package) no longer has special rights which allow them to directly access data members of their superclasses. They too, must use the accessor and mutator methods of its superclass if they need to access their private data members. However, being a subclass still has some advantages. They still inherit the methods of their superclass. Consequently, in the case of accessor methods, (unless those methods have been overridden to perform extra functionality prior to the access) the inherited method is automatically invoked. What are implications of these observations for SDOs?
6.7.1 Authorisation and SDO Inheritance Hierarchies
Consider the class hierarchy of the HRIS prototype, involving Employee, Manager and Executive classes that form a simple inheritance chain. The data member, salary is declared within the class Employee, along with the accessor and mutator methods, getSalary and setSalary respectively. Both the Manager and Executive classes, inherit those methods. In the HRIS prototype, an inherited method was only overridden if additional ac- cess restrictions applied for that type of employee. As shown in Table 6.1, different access privileges are required to access the salaries of each of the employee types. Consequently, the salary accessor and mutator methods in the Manager and Executive subclasses, are overridden to enforce these additional access restrictions.
Employee type User role creator hruser hradmin hrmanager Employee r r rw rw Manager r rw rw Executive r r rw Access rights: r - read, w - write Table 6.1: Security policy extract for the data member Salary
26In Java, the access specifies available are private, package, protected and public. If data members are not declared as being private, the next most restrictive specifier is package which provides access to all classes within the same package, which is clearly not sufficiently restrictive for protected data. The specifier protected is less restrictive, also allowing subclasses from any package to access the data members. 6.7. SDOs and Inheritance Hierarchies 197
As shown in Listing 6.9, the overloaded method is trivial to code. It performs the appropriate authorisation check and then invokes the corresponding superclass method.
Listing 6.9 setSalary methods from the Employee and Executive Classes // From the Employee class public static final long _setSalary = 4096L; public void setSalary(UserID uid, long salary ) { doMethodPermissionCheck (uid, _setSalary, "setSalary"); this.salary = salary; updateSignature(); } // setSalary
// From the Executive class public static final long _e_setSalary = 1073741824L; public void setSalary(UserID uid, long salary ) { doMethodPermissionCheck (uid, _e_setSalary,"setPosition"); super.setSalary(uid, salary); } // setSalary
6.7.1.1 Significant Penalties are incurred
Since the application’s security policy is likely to dramatically change during the life of the system, protected resources to which all legitimate users originally had the same access, might later be deemed to have different access right requirements. Con- sequently, it might be considered prudent to override all of the accessor and mutator methods in each subclass to enable this possibility. That simple code within the Executive.setSalary class is associated with some po- tentially quite high penalties. That super call propagates from the calling class, back through the class hierarchy to the class in which the data member is defined. In each class where the method was overridden, an additional authorisation check is performed to determine whether the salary information can be accessed by the user for that par- ticular type of employee, and the potentially an audit record is generated. Thus, the consequences of making the data members private within SDOs, is not restricted to making additional super calls, but will include the making of unnecessary authori- sation checks and potentially the generation of multiple audit records for the single access to a data member. The problem is compounded, by the number of SDO meth- ods for which this could occur. 198 Chapter 6. The SDO Concept in Distributed Java Applications
Another consequence is that if a user is granted permission needed to access a particular method, say to invoke Executive.setSalary, they must also be granted per- missions access to the corresponding method in each of the superclasses27, i.e. they must be granted the permissions for Manager.setSalary and Employee.setSalary.If the permission was not granted, the authorisation check in the Executive class would succeed but would fail in the Manager class, so the update could not be performed. Assuming that protected data members are declared as being private, there is one situation which cannot be handled in the suggested manner. That situation arises when the security policy stipulates that a particular data member may be accessed in a sub- class, but can not be accessed in one of its superclasses. In terms of the salary example, this would correspond to an executive’s salary being updateable, but an employee’s salary is not. When an attempt is made to update an executive’s salary the authori- sation check in the Executive class would succeed, but it would fail in the Employee class. Thus, a legal operation would be refused! Whether this is a real problem is unknown. A practical example which falls into this category has not been identified, but it may well be quite common in a particular application domains.
6.7.1.2 Providing Authorisation Queries
Providing the application with the ability to determine whether a particular authorisa- tion check will succeed, is a way of reducing the number of unnecessary audit records generated by the application28. The implementation of authorisation queries within SDO inheritance hierarchy is more involved than providing a single method. Like the determination of an authorisation check, the determination of whether an access should be permitted may need to propagate up the inheritance chain. As observed in the previous subsection, authorisation within the HRIS, displays the property that ‘if authorisation performed within a method succeed, the authorisa- tion in the inherited superclass method will also succeed’. This property, in association with the observation that the method invocation need not propagate as far as the data members defining class, simplifies the implementation of authorisation queries. The matter is decided by the first authorisation check. The canSetSalary method presented
27This requirement is based on the assumption that an authorisation check will be performed in each setSalary method as the method invocation progresses up the inheritance chain to the class where the access finally occurs. The assumption is true for the HRIS. 28As discussed in Section 5.3.3.2.1, whether or not authorisation queries should be provided is a design decision. 6.7. SDOs and Inheritance Hierarchies 199 in Figure 6.10 shows the implementation of this approach.
Listing 6.10 canSetSalary method from the Executive Class public boolean canSetSalary(UserID uid ) { return isAccessPermitted(uid, _e_setSalary); } // canSetSalary
Since the security policy stipulates that obtaining a executive’s salary details is more restricted than those of a manager, an Executive specific authorisation check must be performed before an executive’s salary details can be returned. Consequently, the canSetSalary, is overridden in the Executive class. That authorisation check de- termines the result of the authorisation query. Had no Executive specific check been required, the method would not be overridden, so the inherited method will make the decision29. Thus, within SDO inheritance hierarchies, the implementation of authorisation queries is quite efficient. However, the relevant authorisation query method still needs to be overridden in each class in which there is a change in the access requirements of a protected resource.
6.7.1.3 Providing Integrity Checking within SDOs
Section 4.7.2.3.1 discussed the provision of integrity guarantees, using cryptographic MACs. In the prototype, time constraints prevented the implementation of crypto- graphic MACs, so digital signatures were used in their place as the relevant primitives had already been developed. Since non-repudiation was not required, the SDO is only checking the integrity of its encapsulated data (which it had signed), the added expense incurred in computing digital signatures (compared to MACs) would not otherwise be justified. In the prototype, the only SDOs that performed integrity validation were the Em- ployee classes and the StringArrayList class. The other SDOs did not encapsulate protected data, so integrity was not performed. In this section, the implementation of integrity checking within the Employee classes will be briefly discussed as the topic has already been discussed in detail in Section 4.7.2.3.1. This section merely demon- strates that the mechanism previously described, could be successfully implemented.
29The existence of an inherited method is guaranteed, otherwise a compilation error would have occurred. 200 Chapter 6. The SDO Concept in Distributed Java Applications
The only accessor method in which integrity is checked is the getEmpNo method. In the prototype, this method is invoked, whenever an SDO’s encapsulated personnel record is read, integrity checking in the single accessor method was considered to be sufficient. Naturally, an integrity check is performed before any update is made, and a replacement signature generated. Listing 6.11 shows the code that updates the signature in the method Executive.set- PerformanceBonus. The algorithm used when updating performanceBonus is: per- form an authorisation check, perform an integrity check, if its integrity is in tact, update the data member and generate a signature for the new content. If the current signature is invalid, its protected content destroyed. Slight variations on this algorithm is used in all the SDO classes.
Listing 6.11 Signature Updating in the Executive Class public void setPerformanceBonus(UserID uid,String performanceBonus){ doMethodPermissionCheck (uid, _e_setPerformanceBonus, "setPerformanceBonus"); if (checkSignature()) { this.performanceBonus = new String(performanceBonus); updateSignature(); } else { throw new SecurityException("Exec.sPB: invalid Signature"); }//if } // setPerformanceBonus
In the prototype, the SDO’s content is destroyed using the clear method, which sets all protected data members to an appropriate constant clearedString30. The implementation of the methods checkSignature and updateSignature that are invoked by setPerformanceBonus, are presented in Listing 6.12. The implementation of those methods vary slightly between SDO classes. The method getProtectedData is use to ensure that the data members accumulated for the signature generation and signature checking, operate on identical data31. The implementation of integrity checking within the HRIS prototype demonstrated that the use of digital signatures (or better still, cryptographic MACs) can be used within SDOs to provide integrity guarantees. Whether integrity checking within SDOs is required while they remain within a single virtual machine, is an SAA design deci-
30A non-null string was used to avoid raising future exceptions, and the ‘clearly visible’ string (rather than “”) was used so that it was obvious during debugging, that the data had been cleared. 31As protected data members are always declared as being private, only the data members that are declared in that class (for the class Executive, performanceBonus) are accumulated to form the data to be signed. In most SDO classes, the multiple data members are appended to form that data. 6.8. Usage Rights and SDO Lifetimes 201
Listing 6.12 Cryptographic Functionality in the Executive Class private byte[] getProtectedData() { StringBuffer sb = new StringBuffer(performanceBonus); return CryptoFunctionality.stringBuffer2bytes(sb); } // getProtectedData() public boolean checkSignature() { CryptoFunctionality crypto=CryptoFunctionality.getInstance(); if ((signature == null) || (! super.checkSignature()) || (! crypto.isValidSignature(getProtectedData(), signature, "sign"))) { clear(); // the SDO data return false; } else { return true; }//if } // checkSignature private void updateSignature() { CryptoFunctionality crypto=CryptoFunctionality.getInstance(); signature = crypto.sign(getProtectedData(), "sign"); } // updateSignature
sion. The purpose of this research was to verify that such mechanisms could be used if desired. While SDOs are in transit, integrity guarantees can be obtained using other mechanisms (see Section 6.6).
6.8 Usage Rights and SDO Lifetimes
The HR System prototype, like the CD Catalog prototype, provides the user with the ability to request a list of records. Logically there are two approaches to the returning of such information, either as a single list object or a collection of records. This prototype can be configured to return the list of employee records as either a collection of Employee SDOs or a single StringArrayList SDO. The first approach views the personnel records list as a collection of individual records, so models them in that fashion, as a collection of individual records. Each record is encapsulated within a separate Employee SDO. Access control is provided at the level of individual records, and also, because the data has not been converted to its textual representation, this approach is particularly useful if any computation needs to be performed on the protected content, e.g. the collection of statistics. 202 Chapter 6. The SDO Concept in Distributed Java Applications
Alternatively the personnel records can be viewed as being a list and modeled in that fashion. A single table SDO, a StringArrayList object32, is returned. This approach is particularly effective when the information is destined for display. The protected data is only to be read from the individual Employee objects once (at the information server), using the rights of the user making the request, and converted to its textual representation. Thus, only protected information for which the user has no read access, is included, so the list reflects that user’s permitted view of the data. The SDO applies access control at the list level, and in the case of the prototype, access is further constrained is that the data can only be read once. The list that is extracted from the SDO is suitable for inclusion within the data model of a table GUI object such as a JTable. The next two sections, consider the implementation of the related issues of usage rights and SDO lifetimes.
6.8.1 Usage Rights
Many GUI objects, do more than allow a user to view or update the information which they display. Operations such as ‘print’ and ’save copy’ may be supported, which create permanent ‘personal copies’ of displayed information on either paper or on the local file system. In the CD Catalog and HRIS prototypes, only the ‘Print’ operation is supported (see Figure 4.2 or 6.7). A major issue was overlooked when developing the CD Catalog prototype. The SDO paradigm was only used to control read and write access to the data while in the SDOs. There was an inherent assumption that a user who has read access to particular information (possibly with some of the more security sensitive parts hidden), are also entitled to make permanent copies of that information. In general, this assumption is invalid. The security policy might only allow some users to make copies of a particular data set, or alternatively, users might only be permitted to make copies of a subset of the displayed data. The second stage of the research, included an investigation into how such requirements might be supported within SDO-based SAAs. Four different usage rights were identified within the security/ database related literature: analysis33, display, print and save (a copy). Any information having none
32As the class name suggests, the data is a list of string arrays, which is effectively a table (or 2- dimensional array) of textual data. 33The ability to gain statistical information from sensitive information, without divulging that sen- sitive information is usually associated with database security. Pfleeger [37] describes the so called 6.8. Usage Rights and SDO Lifetimes 203 of these usage rights associated with it, cannot be accessed using the system. Us- age rights are orthogonal to the ability to manipulate the information within ‘the database’, i.e. update, save and remove data, which are separately handled by au- thorisation within SDOs. There are two inherent problems with attempting to use SDOs to enforce usage rights:
1. an SDO cannot determine what use will be made of protected data, prior to releasing a copy of that data. Even if the intended use of the data had to be specified when requesting access to the data, there is no guarantee that the spec- ified use will be adhered to.
2. when an SDO releases a copy of protected data, it has relinquished all control that it previously had over that copy of the data.
These restrictions make it impossible for SDOs to enforce usage rights. However, just because SDOs cannot enforce usage rights, does not necessarily mean that us- age rights cannot be enforced using a companion approach that utilises GUI objects. It would be expected that protected information will remain encapsulated (and pro- tected) within its SDO, until it is ‘released’ to the user. In reality, an SDO typically cannot directly ‘release information to a user’, instead the information is passed to a GUI object, which in turn, presents that information to the user. Within an SDO-based SAA, the semantics of the release of information to the GUI object, could include the transfer of responsibility for enforcing usage rights on that information. The GUI object controls how the user can use that information34. There is an assumption that computer systems on which SAAs reside, have con- figured to ensure that the enforcement of usage rights by the SAA cannot be bypassed. For example, on a Microsoft Windows machine, the ability to take screen captures by pressing the < PtrScr > key, would be disabled.
‘inference problem’ as “a way to infer or derive sensitive data from nonsensitive data. The inference problem is a subtle vulnerability in database security”. However an SAA may also be required to provide statistical information relating to its sensitive data, so the ability to mark information as ‘not available for direct access’, could be beneficial. The inference problem less of a problem within an application, as little flexibility is provided to the user when requesting statistical information (in com- parison to a database). 34It is recognised that a GUI object cannot prevent the user breaching the security policy by means external to the application, e.g. a GUI object cannot prevent a user from using a pen to transcribe the information displayed on the screen. It can however, prevent the user breaching the usage rights using the facilities of the SAA, e.g. by enabling the printing that information. 204 Chapter 6. The SDO Concept in Distributed Java Applications
6.8.1.1 The Implementation of Usage Rights
This section outlines the elements of a ‘Usage Rights Design Pattern’ and its appli- cation to the HRIS prototype. SDOs play no part in the enforcement of usage rights, other than the conveying of usage rights relating to its protected content, to the rel- evant GUI objects. The GUI objects are responsible for obtaining the usage rights from the SDO, and then the enforcement those usage rights. To ensure consistency, SDOs which support usage rights implement the interface UsageRights. As shown in Listing 6.13, that will ensure that the method getSDOPermissions is implemented.
Listing 6.13 The interface UsageRights package common; public interface UsageRights {
/** returns a value of type long, that acts as a bit vector * specifying which of the usage rights (STAT_MASK, * VIEW_MASK, PRINT_MASK} and \emph{SAVE_MASK}) * are associated with the encapsulated data. * @returns the usage rights associated with the SDOs content */ public long getSDOPermissions( );
} // UsageRights
In the prototype, experimentation was conducted which involved the use of only two of the four usage rights identified, the right to view and to print35. Both of the GUI objects which display personnel information, the ListGUI and EditGUI objects, enforce usage rights. Of the SDO classes, usage rights are only relevant to the list class, StringArrayList and the employee classes, Employee, Manager and Executive36, so support for usage rights was only implemented in those classes. Supporting usage rights in the SDO classes is trivial. The SDO class declares that it implements the interface UsageRights, and provides the required method getS- DOPermissions. That method returns the value stored in an additional data member, sdoPermissions, which holds the usage rights. That value of type long acts as a bit vec- tor specifying which of the usage rights STAT MASK, VIEW MASK, PRINT MASK and SAVE MASK, are associated with the data encapsulated within that SDO.
35All four usage rights were supported within the prototype, however the prototype did not provide ‘save to file’, nor did it perform any statistical computations, so those usage rights was never enforced. There was however, a single personnel record that only had statistical usage. Consequently, that record was omitted from the employee listings and is not to be displayed by the EditGUI object. 36Only these SDOs encapsulated protected data. The remaining SDOs, such as the DataStoreImpl, only provide protected functionality. 6.8. Usage Rights and SDO Lifetimes 205
When the SDO is instantiated, its usage rights are set to the following system defaults:
• Executive - statistical use, view
• Manager - statistical use, view, print
• Employee - statistical use, view, print, save
• StringArrayList - statistical use, view
Users are not provided with the ability to set or change the assigned usage rights37. Any GUI object, which displays information obtained from an SDO to the user, is responsible for enforcing usage rights on that information. Thus, when the required information is extracted from the SDO, the GUI object is also required to obtain the associated usage rights. The usage rights obtained are stored and permanently asso- ciated within the data model of the GUI to allow mediation of the users access to the information. The SDO does not take an active part in enforcing usage rights. The usage rights are set when the SDO is instantiated, and are accessed by GUI objects.
6.8.1.1.1 EditGUI and Usage Rights The EditGUI object supports the viewing and updating of individual personnel records. The incorporation of support of usage rights into the class is straight forward. When a personnel record is displayed as part of the ‘find’ operation, whether the record38 or an error message is displayed, is de- termined by the usage rights for that personnel record. Similarly, the usage rights determine whether the ‘Print’ button is enabled. An illustration of the EditGUI’s en- forcement of usage rights was presented in Figure 4.2. Since an executive’s personnel record is displayed, (only selected fields of) the record is displayed and the ‘Print’ button disabled.
6.8.1.1.2 ListGUI and Usage Rights The ListGUI object is responsible for pre- senting a list of personnel records to the user. As previously indicated, the prototype can be configured to either use a StringArrayList or a collection of Employee objects, to hold the personnel list. The incorporation of usage rights into the two implementa- tions of the ListGUI, will be separately discussed in the next two subsections.
37For research purposes, usage rights are arbitrarily changed from the system defaults by modifying the relevant database entries. 38Whether a record should be displayed is calculated by determining the setting of the relevant bit in sdoPermissions bit vector, i.e. by evaluating sdoPermissions&VIEW MASK!=0. 206 Chapter 6. The SDO Concept in Distributed Java Applications
StringArrayList Version of the Prototype In Section 6.8, the advantages of us- ing a StringArrayList to return a list of information for display, were discussed. Hav- ing a single list simplifies the management of the usage rights because the rights are associated with the list as a whole, rather than individual records. When a StringAr- rayList object is instantiated, the usage rights for the list are set to the minimum rights possessed by any personnel record in the list39. However, to ensure that the returned list can be displayed, only viewable personnel records are included in the list. The ListGUI object treats the list in a similar manner to that used by the EditGUI object, since it is only displaying an individual record. Although this mechanism makes the handling of the personnel list quite simple, the ability of a user to either print or save data is curtailed, e.g. the list can only be printed if every item that has been included in the list was able to be printed.
Collection of Employee Objects Version of the Prototype When a collection of Employee objects is included in the list, all personnel records are returned irrespective of their usage rights. This approach overcomes the shortcoming of the list method that was just identified, as each record is associated with its usage rights, rather than those of the list. The security policy requirement, that the list can only be printed if every item in the list can be printed, can be met by removing from the list of those records which cannot be printed. The ListGUI implementation that handles a collection of Employee objects is simi- lar to that used in the CD Catalog prototype. Its data model contains a list of Employee objects, each of which encapsulates usage rights40. However, this data model imple- mentation suffers from the severe problem of having to perform numerous SDO data accesses (and authorisation checks) to repopulate the table whenever the GUI requires refreshing (see Section 5.5). The effectiveness of this implementation in handling usage rights is demonstrated by comparing Figures 6.7 and 6.8. Figure 6.7 shows the personnel list. It displays only those personnel records for which display is permitted. Since this is the view for a user acting in the role hruser, the true values of those fields of the personnel record
39More correctly, a particular usage right is included in the list’s rights set, only if that right is associated with all personnel records included in the list. 40It also includes a two-dimensional boolean array, canViewField. The array, which is initialised along with the contents of the employee list whenever the role of user using that HRIS client changes, acts as an allowed access cache, storing for each type of employee object, whether each of the data members can be displayed. The array is used to determine which fields of a personnel record should be displayed within the JTable, without having to make unnecessary authorisation requests. 6.8. Usage Rights and SDO Lifetimes 207 which a hruser is not permitted to view, are withheld due to the authorisation query/ checks performed by the Employee objects.
Figure 6.7: A Listing of All Personnel Records
Figure 6.8: A Printable Listing of All Personnel Records
Figure 6.8 shows the personnel list after the user has requested that the list be printed by clicking the ‘Print’ button. Note that those employee records which are not permitted to be printed have been removed from the list. The user is given the option of printing the permitted list or cancelling the request. This approach has the advantage of allowing the user to print all of the records that are permitted by the security policy. An optimal data model for the JTable, is one in which the data is removed from the Employee object collection and stored in either a two-dimensional array of strings or a list of string arrays, and a separate parallel array/ list of usage rights is created to holds the usage rights for each data row of the table. Such an implementation would support fine grained usage rights, while at the same time avoiding excessive authorisation checks. The same data model implementation could be supported if the 208 Chapter 6. The SDO Concept in Distributed Java Applications
StringArrayList implementation was modified to include the usage rights for each row of the table rather than a single usage right for the list. Neither of these approaches was implemented in the prototype, due to the lack of time.
6.8.1.2 Appropriateness of Usage Rights
Experimentation using the HRIS demonstrated that the concept of usage rights can be supported within SDO-based SAAs. Providing support for usage rights within an SAA requires those objects that obtain protected data for SDOs, to enforce the usage rights associated with that data. The role of SDOs is to encapsulate the usage rights associated with their protected content. The users of that information that are responsible for obtaining those rights from the SDO and then enforcing them.
6.8.2 Implementing SDO Lifetimes
In Section 4.4.2, support for limited lifetimes for SDOs and user credentials was dis- cussed in depth, and potential implementations proposed. This section will develop that topic by discussing the implementation of lifetimes within the HRIS prototype. Support for object lifetimes was only implemented in the UserID (authorisation credential) class, the StringArrayList class and the Employee class hierarchy. To allow investigations into both models, the lifetime of UserID and Employee classes were time based41, while the lifetime of StringArrayList objects was measured in terms of how many times their protected content could be read. Objects of all these classes destroy their protected content once their lifetime has expired.
6.8.2.1 Lifetime Specified by Expiry Date
In the UserID class, the lifetime is specified by specifying an expiry time and the currency of the credential is checked in the checkSignature method. For simplicity, the expiryDate is stored as a long integer, which represents the millisecond count since the Epoch, January 1, 1970 00:00:00.000 GMT (Gregorian) [90]. The use of this time representation simplifies time comparisons. The relevant implementation is presented in Listing 6.14.
41The use of time based lifetimes, requires clocks which are synchronised to the extent that any discrepancies between clocks is small compared compared to the time periods that they are being used 6.8. Usage Rights and SDO Lifetimes 209
Listing 6.14 Lifetime checking in UserID.checkSignature() // has UserID has expired? if (Calendar.getInstance().getTimeInMillis() > expiryDate) { SystemLog.addToLog(this,"UserID","checkSignature", "EXPIRED", "false"); role = "
Since both the expiry date and digital signature are checked, any modifications to the expiry date aimed at extending the lifetime of an expired credential, will be detected. As illustrated in the code fragment, after logging the event, the credential is destroyed by changing the user’s role value. Since the user’s role is included within the SAA’s error messages, the need to re-authenticate is made known to the user. When using time based lifetimes, care must be taken to ensure that any UserIDs used by the application’s ‘system processes’, do not expire.
6.8.2.1.1 Implementation of Employee Lifetimes Lifetimes were implemented in the Employee class hierarchy in a similar manner, to the UserID class. To simplify the implementation of Employee lifetimes, the expiry date was not considered to be a protected data member. It is declared as being ‘protected’ (so that the expiryDate de- clared in the Employee class is visible in all subclasses) and no authorisation checks performed in its accessor and mutator methods42. However, since expiryDate is in- cluded in the signed data of the Employee class, any changes made to the expiry date would be detected and the object cleared. The effect of SDO lifetimes is most evident in the ListGUI object. In the prototype version that uses a collection of Employee objects to model the employee list, the Employee objects within the data model will timeout simultaneously. When the GUI object is next refreshed, the content of the table, is suddenly overwritten. Refer to Figure 6.9, for an example of the ‘cleared’ data table. to measure. 42These methods were required for the Web services prototype to allow the disassembly and re- assembly of Employee objects. 210 Chapter 6. The SDO Concept in Distributed Java Applications
Figure 6.9: The ListGUI after Employee lifetimes have expired
6.8.2.2 Lifetime Specified Access Count
The StringArrayList class is an example of where it is reasonable to specify its lifetime in terms of the number of accesses which may be performed. It contains only a single piece of protected content a copy of which is released as single operation, i.e. the get method returns the ‘table of information’, so it is feasible to talk about a number of accesses. The possibility of only releasing part of the information cannot occur. The release of only part of the information which makes the counting of accesses difficult, can occur if (1) multiple protected resources can be separately accessed, e.g. an Employee object, or (2) part of a single protected resource can be released, e.g. the playing of part of a movie. However in this case those possibilities cannot occur so the implementation of SDO lifetime is also quite simple. An access counter, numReadsPerformed, and the number of invocations of get that are permitted, numReadsPermitted, were used to determine when the lifetime of a StringArrayList has expired. The implementation of get method which is provided in Listing 6.15 shows that as well as implementing lifetimes, this SDO class also implements integrity checking. The method is implemented as one would expect, except for one peculiarity, the determination of whether the requester’s role is “SU”. That role is used by the Web ser- vices middleware layer, which converts the StringArrayList to an NonSDOStringAr- rayList and vice versa (see Section 6.4.1). Since such accesses should not affect the object’s lifetime, those accesses do not cause the numReadsPerformed value to be in- cremented. In the prototype, this behaviour is especially important, as only one access is permitted, sufficient to allow the information table to be transferred to the appropri- ate GUI object. Further, the authorisation performed within the get method ensures that access is only permitted by the user who requested the information43.
43More correctly, since authorisation is based on the RBAC model, any user acting in the same role 6.9. Usefulness of AspectJ 211
Listing 6.15 Lifetime checking in StringArrayList.get public Collection get(UserID uid) { doMethodPermissionCheck (uid, "StringArrayList"); checkSignature();
if (uid.getRole().equals("SU")) { return copyStrList(strList); } else if (numReadsPerformed < numReadsPermitted) { numReadsPerformed++; return copyStrList(strList); } else { if (sdoDataDestroyed==0) { clear(); }//if return new Vector(); } }//get
6.8.2.3 Comments on SDO Lifetimes
The implementation of lifetimes for SDO objects within the HRIS prototype and the simplicity of that implementation, demonstrated that the adoption of the SDO concept, in no way hinders the implementation of object lifetimes within SAAs. There is a problem associated with provision of SDO lifetimes based on time. The SDO must be executing for detection of an expired lifetime to occur. Thus, a dormant SDO may exist with its protected data intact, well beyond its specified lifetime. The data will however, be destroyed as soon as one of its instrumented methods is invoked. Thus, the problem is not significant. Considering the increased protection afforded by supporting defined lifetimes for SDOs, specifying lifetimes for many of an SAA’s SDOs should be seriously consid- ered.
6.9 Usefulness of AspectJ
In Section 5.2.1.3, the changes that needed to be made to a class to convert it to an SDO class, were identified. Essentially, major changes were: (1) the addition of an extra parameter, an authorisation token, to each method which accesses a protected resource; (2) the addition of a small amount of code to each of those methods, to initiate an authorisation check (using a local method) and then enforce the authori- may read that information. 212 Chapter 6. The SDO Concept in Distributed Java Applications
sation decision; and (3) the addition of that local method to the class that calls upon the SDO’s AO to perform an authorisation check, and to throw an exception if the authorisation fails. The latter two changes are logically one, but were separated to reduce the amount of duplicated code. Although these changes are straight forward, the need to be make very similar updates to quite a large number of methods, raises the possibility of introducing subtle errors. AspectJ is an aspect oriented programming extension to the Java programming language. A quite extensive introduction to the language was provided in Section 2.9. AspectJ appears to have the potential to assist with quite mundane and potentially error prone task of performing the initial introduction of similar code to numerous methods, and also to enhance the manageability of that ‘almost replicated’ code when changes are required.
6.9.1 The Investigation Performed
A preliminary investigation into the potential of using AspectJ to the support the im- plementation of the SDO concept was made. It involved using AspectJ to make the required updates a very cut down version of the HRIS. The candidate system was cre- ated by making the following two major changes to a previous version of the HRIS: (1) the application was made non-distributed, and (2) support for displaying the list of personnel records was removed. What remained was a minimal system, but suffi- cient to test whether the use of AspectJ would prove beneficial. The authentication- authorisation subsystems, Employee SDO hierarchy and the DataStoreImpl SDO still remained, together with the EditGUI which would enable the testing of the authorisa- tion introduced by AspectJ.
6.9.1.1 Requirements
The purpose of the investigation was to determine to what extent AspectJ can be used to transform a non-SDO class into an SDO class, and assist in the maintenance of that SDO. A major problem is that the methods of the SAA that perform authorisation do so on the basis of an authorisation token which is passed as an additional parameter. It is believed that AspectJ is unable to add that parameter, so the developer will need to perform that task. Similarly, the required authorisation query methods canGet?? and canSet??, need to be added to the classes being converted. These methods do not need to perform the authorisation query, AspectJ will be used to add the required code, but 6.9. Usefulness of AspectJ 213 they need to be declared. Listing 6.16 provides an extract from the Executive class which shows the typical implementation of an accessor, a mutator and an authorisation query method. As shown in that listing, this version of prototype supports the following features: (1) when authorisation fails in an accessor method, a dummy value is returned to the caller (rather than raising an exception), and (2) the class supports integrity checking (in the form of signature checking), as illustrated by the implementation of the mutator method setPerformanceBonus.
Listing 6.16 Extract from the Executive class public boolean canGetPerformanceBonus(UserID uid) { return false; } // canGetPerformanceBonus public String getPerformanceBonus(UserID uid) { return new String(performanceBonus); } // getPerformanceBonus public void setPerformanceBonus(UserID uid,String performanceBonus){ if (checkSignature()) { this.performanceBonus = new String(performanceBonus); updateSignature(); } else { throw new SecurityException("Exec.sPB: invalid Signature"); }//if } // setPerformanceBonus
After the conversion is completed, those SDO methods should behave as though the code of the methods had been transformed into the methods presented in List- ing 6.17. Notice that this implementation differs from the code used in the other prototypes in that the call to the authorisation object is performed within the methods themselves, rather than using a shared method. This approach was taken because the duplicated code was being added by AspectJ (each time the system was recompiled), so there would not be a maintenance problem.
6.9.1.2 The Implementation
Two aspects were developed to achieve the required conversion of the (modified) non- SAA to an SDO-based SAA. That portion of one of the aspects which modifies all of the Executive class’s mutator methods will be very briefly discussed to show how 214 Chapter 6. The SDO Concept in Distributed Java Applications
Listing 6.17 Proposed replacement methods for the Executive SDO class public boolean canGetPerformanceBonus(UserID uid) { if (staticAuthorisor==null) staticAuthorisor= new SDOAuthorisor ("Employee"); return staticAuthorisor.isMethodAccessPermitted(uid, className, "getPerformanceBonus"); } // canGetPerformanceBonus public String getPerformanceBonus(UserID uid) { if (!emp.authorisor.isAllowed(uid,className, "getPerformanceBonus")){ if (methodName.equals("getSalary") || methodName.equals("getSDOPermissions") ) { return new Long(Employee.internalInvalidLong); }else{ return Employee.internalInvalidString; }//if } else { return performanceBonus; } } // getPerformanceBonus public void setPerformanceBonus(UserID uid,String performanceBonus){ if (! emp.authorisor.isAllowed(uid,className, "setPerformanceBonus")){ throw new SecurityException(uid.getRole() + " no " + "setPerformanceBonus" + "." + methodName);
if (checkSignature()) { this.performanceBonus = new String(performanceBonus); updateSignature(); } else { throw new SecurityException("Exec.sPB: invalid Signature"); }//if } // setPerformanceBonus 6.9. Usefulness of AspectJ 215 this conversion was achieved44. A relevant extract of the aspect is provided in List- ing 6.18, with the full listing of that aspect, EmployeeSDOAspect, being presented in Appendix F.
Listing 6.18 Extract from the EmployeeSDOAspect aspect pointcut executiveSet(Executive emp, UserID uid) : target(emp) && args(uid,..) && (execution(public * common.Executive.set*(..)) && within(Executive) ); before(Executive emp, UserID uid) : executiveSet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); setCode(emp, uid, sig); } // advice private void setCode(Employee emp, UserID uid, Signature sig) { String methodName = sig.getName(); String className = emp.getClass().getSimpleName(); if (! emp.authorisor.isAllowed(uid,className,methodName) ) { throw new SecurityException(uid.getRole() + " no " + className + "." + methodName); } } // setCode
pointcut executiveSet selects all executions of a mutator method45 from the Exec- utive class. The selection has been restricted to non-inherited methods. The pointcut has captured both the target of the invocation, i.e. the Executive object, and the UserID object being passed as the first parameter to the method. That information is passed to the advice as parameters. That advice use the associated thisJoinPoint object to determine the name of the method being invoked and name of the class to which it belongs (i.e. “Executive”). The advice then invokes the isAllowed method of the AO associated with this Executive object. The separate method setCode is used to perform this functionality as the code is reused by the advices for other joinpoints.
44The candidate is inexperienced in the use of AspectJ, so it is quite possible that a less than optimal aspect was developed. However, the conclusions relating to the usefulness of AspectJ are believed to be valid. 45By convention, mutator methods are named ‘setDataMember’, while accessor methods are named ‘getDataMember’. 216 Chapter 6. The SDO Concept in Distributed Java Applications
6.9.1.3 The Ineffectiveness of AspectJ
Using the approach discussed above, AspectJ was used to construct the SDO based prototype. Certainly, once it had been developed, it was easier to make any changes to the authorisation code as changes only needed to be made once within the code of the aspect. Potentially within a large application, the ease of maintenance may warrant the use of AspectJ (or other aspect oriented programming language). However, the usefulness of AspectJ (and possibly other aspect oriented program- ming languages) appears to be somewhat limited. The deficiencies appear to be:
• reviewing the effectiveness of the authorisation being provided is much simpler when the ‘hand written’ authorisation code is used rather than the more obscure AspectJ code.
• developers need to be skilled in the use of both the aspect oriented language and the development language.
• non-text based authorisation schemes, such as that used within the HRIS dis- tributed prototype, is not believed to be implementable in AspectJ as the relevant constant, whether declared within the aspect or in the class, cannot be accessed.
• each method in which authorisation is performed, required the authorisation token to be passed to it. While adding the parameter, or developing the method for the first time, it is a simple (though repetitive and potentially error prone when numerous updates need to be made) matter to add the relevant authorisation code ‘by hand’.
• the authorisation query methods need to be added to the class ‘by hand’. The addition of the required query call could also be performed at that time.
• although it is possible to add code before, after or around joinpoints (such as method invocations and data accesses), the insertion of the authorisation check at an arbitrary point in the method is not possible. For example, it might be desirable to collect context information before making the authorisation call.
• far more time was spent developing the aspect and ensuring that it worked cor- rectly, than would have been required to make the changes by hand. Also, de- bugging was more difficult without being able to see exactly what the code was. Potentially, these problems may not have been so significant, if the candidate had more experience with AspectJ and its associated browser. 6.10. Closing Comments 217
In summary, although the idea of using AspectJ to support the implementation of the SDO concept appeared to be promising, the experience gained in attempting to use language to perform this simple non-SDO to SDO conversion, indicates that its usefulness is very limited. However as stated earlier, once the aspect had been developed and tested, mainte- nance of that part of the application was significantly easier. For a large application, and in a development environment in which AspectJ expertise was available, the ease of maintenance might warrant the use AspectJ or other aspect oriented language.
6.10 Closing Comments
In this chapter, the ability to apply the SDO concept to the development of purpose built distributed SAAs was demonstrated. Since its applicability was demonstrated when using two orthogonal distributed computing models, its applicability to a wide range of distributed models is likely. The research demonstrated that the use of the SDO concept does not interfere with the use of inheritance hierarchies or the provi- sion of desirable application features such as the implementation of object lifetimes, integrity checking and usage rights. Additionally, the ineffectiveness of aspect oriented languages, in particular As- pectJ, in supporting the implementation of the SDO concept was identified. The next chapter will continue to explore the practical application of the SDO concept to the development of SAAs by discussing the provision of a suitable SDO support environment. 218 Chapter 6. The SDO Concept in Distributed Java Applications Chapter 7
The SDO Support Environment
This chapter continues the discussion of the previous two chapters which dealt with the application of the SDO to the development of SAAs in non-distributed and distributed environments respectively. The major thrust of those chapters was to demonstrate that the SDO concept can be applied to SAA development. This chapter considers an orthogonal aspect of the SDO concept. Rather than dealing with whether or not the SDO concept is compatible with and improves current SAA development best practice, this chapter deals with the provision of support for both the development process and the execution of the SAAs developed using that process. Such a support environment will be referred to as the ‘SDO Support Environment’ (SDOSE). The next chapter will provide an evaluation of the SDO concept as a guiding phi- losophy for SAA development, and identify research that needs to be completed if the full potential of the SDO concept is to be realised. Support for the application of the SDO paradigm is required in three areas, the provision of: (1) documentation detailing the philosophy behind the SDO concept and guidelines showing how that philosophy can be put into practice, (2) documented pro- cedures and processes, and any SDO specific tools needed to support those processes, and (3) an Application Programmers Interface (API) which extends the language API to provide classes specifically designed to support the requirements of SDO-based SAA development. The first aspect of that support is provided by earlier chapters of this thesis. Chap- ter 4, and to a lesser extent Chapter 1, introduced the SDO philosophy and then dis- cussed how it might be put in practice through a (language independent) discussion
219 220 Chapter 7. The SDO Support Environment of the issues involved and how they might be resolved. Chapters 5 and 6 expanded that discussion by providing concrete examples of how the SDO philosophy can be put into practice in the Java programming language. The second aspect, the provision of procedures and processes which guide SDO- based SAA development is more an organisational rather than research matter. How- ever, an indication of the expected minimal effects that the introduction of the SDO concept will have on existing processes, is provided in the next section, Section 7.1. The identification of tools specifically designed to support the SDO concept are dis- cussed in the context of the environment in which they will be deployed, in Sec- tions 7.1 and 7.2. The third aspect, the provision of an SDO/ SAA specific API, has only been briefly investigated. The functionality of the API is derived from the services that were devel- oped to support the discussed prototypes, so have been introduced in Chapters 5 and 6. The API, and related discussion, are provided in Section 7.3. Gaining familiarity with the API is likely to be the most significant component of the training requirements for existing programmers who would use the SDO concept in SAA development.
7.1 SAA Life Cycle and the SDO Concept
As illustrated in Figure 7.1, each release of an SAA is expected to make an orderly progression through four environments during its lifetime. Those environments are:
• the Development Environment The processes and tools associated with this environment support the design and implementation of SAAs,
• the Commit Environment In this environment, the security characteristics of the individual classes which comprise the SAA are established,
• the Deployment Environment The components of the SAA are assembled, configured and packaged ready for deployment within this environment,
• the Execution Environment This environment supports the secure execution of SAAs. 7.1. SAA Life Cycle and the SDO Concept 221
Development Commit Deployment Execution Environment Environment Environment Environment
Figure 7.1: SAA Life Cycle
The development, deployment and execution environments are found in the stan- dard Software Engineering production model for any software product that is de- veloped. The other environment, the Commit Environment, proposed by Mohay et al. [109], is peculiar to SAAs. Its purpose is to ensure that all of the classes of the SAA conform to the organisation’s standards for SAA development. As identified in that paper, this environment provides “a verification mechanism which carries out static checking of software (e.g., authenticity checks, covert channel analysis, Trojan horse/virus checking etc.) and verifies that the software to be distributed meets the security policy imposed by management”. Their proposal included the requirement for software tools within each environment, that would use cryptographic techniques to enforce the controlled progression of software from one environment to the next. In the following subsections, any impacts that the adoption of the SDO paradigm are likely to have on each of these environments will be identified, together with any additional support which needs to be provided.
7.1.1 Development Environment
The application of the SDO concept does not impact on the process of SAA develop- ment, as its adoption only changes the positioning of authorisation checks within the SAA. Rather than authorisation checking being performed at their current locations in the SAA code, that same checking is moved to those objects which encapsulate protected resources, i.e. those objects will be converted to SDOs. Consequently, the development processes and procedures currently in place, will not require modifica- tion. However, as identified in the introduction to this chapter, some training of current developers will be required to make them familiar with the SDO philosophy and the API provided1 to support that philosophy. The largest impact that adoption of the SDO concept will have on the development
1Like their current API, one would hope, the SDO specific extension, would be composed of a standard component provided by their current SAA development environment vendor, supplemented by an in-house component that meets their particular development requirements. 222 Chapter 7. The SDO Support Environment of SAAs is the form that the software enforcible security policy will take. Rather than translating the ‘logical’ security policy into an authorisation system specific set of rules based on data access, a set of rules based on method authorisation will be required to support the SDO paradigm. It is believed that changes to the authorisation infrastructure would not be required, only changes to the semantic basis of the rule set. As identified previously, the other difference is to SAA design, in that the location of authorisation checks within the SAA, will change. Determining the location of au- thorisation checks, will now consist of identifying which methods in the classes which manage protected resources, provide access to those resources. Since the changes to the design and implementation of SAAs are relatively minor changes, only a minor commitment to developer training is required to support adoption of the SDO con- cept. The development environment is a high trust environment, in that the final quality of the software is dependent upon the developers acting both professionally and hon- estly. In particular, it is believed that they will not intentionally introduce flaws in the software product, which they or others will be able to exploit at some future time. In this environment, maintaining high productivity is likely be considered to be more important than providing a very high level of system security. Here, an appro- priately configured commercial operating system for which a wide range of software development tools are available, would be favoured over a secure operating system, for which only rudimentary development tools were available. The only additional support required in the development environment to support the implementation of the SDO concept, is the provision of a dedicated API and tool set that directly supports the SDO concept.
7.1.2 Commit Environment
The Commit Environment as previously mentioned is responsible for evaluating the quality of the software that has been developed, in particular its security properties, rather than validating its functionality2. A combination of analysis performed by soft- ware tools and evaluations of source code quality through code inspections, is likely to be used to ensure that the software component complies with organisational quality
2The development environment is primarily responsible for ensuring that the functional require- ments are met. Only after the required functional standards have been achieved, will the software be permitted to progress to the commit environment. 7.1. SAA Life Cycle and the SDO Concept 223 standards. In this environment, a trusted, specialised compiler which does not support lan- guage features and parts of the API that are deemed as being insecure, is likely to play a major part in ensuring that the executable code generated is a true reflection of both the source code and organisational security policy requirements. The implementation of the authorisation mechanism with SDOs will be a major focus. After all, the effectiveness of the SAA in restriction access to the application’s resources, is reliant upon them. As part of the SDOSE, it would be expected that tools would be available to assist with the mapping of the security policy to the initiation of authorisation checks within SDOs. Otherwise, no other specialised SDO-related support tools would be required. Despite the checking which occurs within this environment, the trust placed in the developers is not significantly reduced. Given sufficient time and resources, code inspections performed by experienced programmers should detect accidental security flaws. However practical resource constraints, are likely to translate into an inability to discover a carefully hidden flaw introduced by a (skilled) malicious developer. Here also, a great deal of trust is placed in personnel. The operating environ- ment itself will be primarily determined by the needs of the specialised tools being employed. Despite these constraints, securing the commit environment is a major concern.
7.1.3 Deployment Environment
Generally, the Commit and Deployment environments may be combined. However for discussion proposes, it is considered appropriate to segregate the two environments. The deployment environment is concerned with the configuration and packaging of the SAA, i.e. preparing it for distribution, so it is unlikely that there will be any additional requirements peculiar to the application of the SDO concept. The effectiveness of this environment, and the security of the deployed SAA, is highly reliant upon the skill and trustworthiness of the personnel involved.
7.1.4 Execution Environment
The execution environment is significantly different to the previous environments, in several significant ways. Firstly, the number of users of a product is several orders of magnitude larger than the number of people involved in its development. Placing 224 Chapter 7. The SDO Support Environment a high level of trust in the large number of SAA users is far less feasible. Secondly, the SAAs are likely to be deployed at numerous sites, not all of which will be ade- quately secured, so the possibility of an outsider attack is high. Thirdly, the numerous execution environments are unlikely to be isolated from the remainder of the world. Consequently, they may be susceptible to attack by viruses and associated malware. Finally and possibly most importantly, only the deployed SAA provides access to the protected resources that an attacker, whether internal or external, will want to access. Consequently, the users of the SAA and the computer on which it resides, are necessarily considered to be untrustworthy. The execution environment, comprising the operating system, the SDO support environment and the authorisation subsystem of the SAA, together act to defend the protected resources from unauthorised access. The role of the authorisation subsystem of the SAA has been the topic of much of this thesis, so will not be considered again. The following section will discuss the requirements for an operating system and the role of the SDOSE in protecting SDOs within the execution environment.
7.2 Protecting the Execution Environment
The proposed ‘SDO Support Environment’ (SDOSE) is, from a systems viewpoint, a collection of application level programs and class libraries which support the secure execution of SDO-based SAAs. The SDOSE on a computer system is likely to be implemented as two components. The first is an executing server-like process which provides services to both remote SDOSEs and all of the SDOs running on that com- puter (in their separate virtual machines). The other component is an SDO specific API. Due to time constraints, a determination of what parts of the SDOSE should be included in the server partition and how it will interact with the remainder of the SDOSE, has not been undertaken. The purpose of this section is to identify the services that the SDOSE should pro- vide to help to protect SDOs and their protected resources, in what must be assumed to be an untrusted environment.
7.2.1 Trust Establishment
Trust establishment related to how the SDOSE might be used to establish a high level of trust between the distributed components of an SAA. In this context, trust is de- rived from the belief that the computers across which the SAA are distributed, are 7.2. Protecting the Execution Environment 225 adequately secure and that the SAA components have not been compromised. It be- gins by considering what constitutes an adequately secure system, and then discusses how it might be achieved.
7.2.1.1 Secure Operating System
For application level protection measures to be successful, they must be supported by and supplemented by the services provided by the operating system and other system software. An SAA can only control access to resources which take place through the SAA. The operating system is responsible for preventing the unauthorised access to those protected resources by all other means, e.g. by directly accessing or copying files. To prevent unauthorised access, the operating system must: (1) implement manda- tory access control to prevent unauthorised access to system resources, which include persistent forms of that information managed by SAAs, together with the configura- tion and access control information on which the SAA relies; and (2) provide com- plete process separation, that includes the prevention of access to uncleared memory by a different process, i.e. access to transient manifestations of that information which might exist on disk blocks and memory blocks. The other related functionality re- quired is the provision of a complete and protected audit trail. The latter service supports the detection of inappropriate activities carried out on the computer system. Trustworthy implementations of such operating systems services are only achiev- able using appropriately configured, trusted operating systems. Only in such an envi- ronment, can an SAA provide true application level access control.
7.2.1.2 Adequate Security
SAAs, however, will very often operate in far less trusted environments. For ex- ample, the imposition of legislative requirements, such as HIPAA in the US health sector (Section 2.4), mandates the attainment of designated security standards. But, unlike military systems which require very high levels of security and have the per- sonnel and budgets capable of supporting such security standards, the security targets for other government and commercial organisations are framed in terms of providing reasonable security. In the following subsections, the need to establish trust in distributed SDO-based SAAs will be explored. 226 Chapter 7. The SDO Support Environment
7.2.1.2.1 Securing Commercial Operating Systems By far the majority of SAAs operate in environments supported by commercially available operating systems. As identified in Section 1.2.1, such protection is, at best, adequate. In such environments, the ability of SAAs to enforce mandatory access control is significantly diminished. For example, should an attacker be able to manipulate the SAAs authentication or authorisation data (through the exploitation of an operating system flaw), illegitimate users can masquerade as legitimate users to access the resources protected by SAA. (That same flaw might also provide an attacker with direct access to the information stored in files or databases, so they would bypass the SAA altogether.) Computer systems using commercial ‘off-the-shelf’ operating systems however, can be made as secure as possible, by (1) ensuring that security patches for the oper- ating system and other system tools are routinely applied, and (2) that anti-virus and other protection software, is kept up to date. Operational requirements, in particular, only allowing approved software to be loaded onto the system, further reduces the likelihood of introducing either flawed software or software contaminated by viruses or other related malware, into the system. Since the protection afforded by SAAs, including those based on the SDO concept, can be circumvented when such precau- tions are not taken, such policies should be mandatory on all systems on which SAAs reside. For a distributed SAA, those conditions apply to all client machines, including home machines (if the organisational security policy permits such connections). An alternative approach that can significantly enhance the security provided by Linux based systems, is the installation of an operating system patch that incorporates mandatory role based access control (RBAC) into the Linux operating system. The patch is available from the (US) National Security Agency (NSA). Support for RBAC will significantly increase the security provided by the system, however the ability to take this option is reliant upon the provision of an appropriate budget and availability of highly skilled personnel, to support the design the role hierarchy, appropriately configure the operating system and continued maintenance of a secure configuration despite changing organisational requirements.
7.2.1.2.2 Security and SDOs Mobile code, in the form of Java applets, have been considered to pose a major threat to computer systems. The inclusion of many of the security features of the Java language and its Java Virtual Machine (JVM), that were discussed in detail in Chapter 3, were a direct result of the need to maintain secu- rity while still providing support for applets. Both objects and SDOs in a distributed 7.2. Protecting the Execution Environment 227 application, are also mobile code, so potentially pose a threat to application hosts. Conversely, hostile hosts pose a threat to SDOs, and the security-sensitive re- sources which they encapsulate. These views are supported by research into mobile agents which established that it is not possible to protect a mobile agent from a con- certed attack mounted on a hostile platform, and similarly hostile mobile agents can, to a lesser extent pose a threat to mobile agent platforms3. Section 2.8 provided an extensive discussion of security in mobile agent systems.
7.2.1.3 A Means of Establishing Trust
One service that the SDO Support Environment (SDOSE) should provide is the ability to determine whether a remote system to which an SDO is to be sent is suitable4. The establishment of mutual trust is expected to be based on a two way exchange of credentials between the communicating systems. Two methods by which trust establishment could be achieved are: there is a two way exchange of credentials between instances of the SDOSE, or each SDOSE sepa- rately evaluates the suitability of the other system through some form of remote attes- tation not involving the SDOSE at the other site. What ever mechanism is employed, the evaluation will include an estimation of the current security state of each computer system, in particular the integrity of the SDOSE at each site. As discussed in the literature review, Section 2.7.2.2, how remote attestation can be achieved in practice, is being actively researched by IBM. One proposed mecha- nism relies on the analysis of measures (cryptographic checksums) made by a tamper- resistant hardware device, a TPM, of all software loaded on that system. Such an approach is impractical in general, due to the huge variation in hardware and soft- ware, including device drivers, that may be present on a system. However, systems on which SAAs are reside, are not typical systems. Firstly, there will often be a restric- tion in hardware used to ‘approved’ systems, hence a significant containment in the number of device drivers used. Secondly, there should be limited system and appli- cation software loaded onto the system, all operating system security patches should have been installed and the virus software up to date. In such a system, the use of the proposed IBM technique, that includes all software loaded onto the system in the
3The threat posed to mobile agent platforms has been limited by the introduction of similar protec- tion mechanisms to those used to defend against applets. 4This research is confined to a consideration of the application of the SDO concept to the develop- ment and support of SAAs. Consequently, an SDO will only be sent to a computer on which part of that SAA resides, so the presence of an instance of the SDOSE at that site can be assumed. 228 Chapter 7. The SDO Support Environment evaluation of the trustworthiness of the system, might be feasible. No attempt has been made by the candidate to further investigate the feasibility of this approach, nor how it might be implemented.
7.2.2 Security Policy Distribution
In Section 4.2.2, the problem of policy distribution was discussed and a three-tier architecture proposed. There would be one or more policy servers which provide policy services to the individual policy objects located on each computer onto which the SAA is distributed. Those policy objects in turn, provide policy information to the authorisation objects within their virtual machine. A possible mechanism for distributing policy updates to long-lived SDOs within a virtual machine was suggested in that section. As no support for policy distribution was provided within the prototypes, the practicality of the proposed approach has not been demonstrated. In the proposed three-tier architecture, responsibility for policy propagation to the policy objects within each virtual machine, lies with the SDOSE. The SDOSE will provide a policy server for that purpose. A server architecture is required, as com- munications with objects outside a virtual machine, are remote accesses, irrespective of the computer on which the reside. Policy objects within the individual virtual ma- chines, will poll that server checking for updates. The distribution of policy updates is reliant upon the provision of mirrored policy files or databases on the machines on which the SAA resides, and as such is not im- pacted upon by the adoption of SDO concept. Consequently, that functionality will continue to be achieved by what ever mechanisms are currently in use.
7.2.3 Web Services Support
The Web services model does not directly support the SDO concept. However, as described in Section 6.4, support tools are currently available to generate the class files for all objects passed as parameters and the numerous classes needed to support remote procedure call (RPC) semantics. Typically those tools use the WSDL specification of the services being provided by the Web services server, as the basis for that code generation. To achieve RPC semantics, both object and primitive type parameters must be transferred from the client to server and any return result (or raised exception) re- 7.3. The SDO Support Environment API 229 turned. For example, to make the remote procedure call, the method being invoked along with its object and primitive type parameters must be converted to a SOAP message, that SOAP message transmitted to the server, the parameters reconstructed, finally the appropriate method at the server is invoked with those transmitted parame- ters. To support this mechanism, the class files for the types passed between the client and server (that are generated by these tools) contain the required constructors and ‘appropriately named’ accessor and mutator methods for each data member. SDOs cannot be passed by such a mechanism. They must, by definition, per- form authorisation before performing any operation which accesses protected data. Hence, they are completely incompatible with that mechanism. As shown in Fig- ure 6.5, that incompatibility was overcome by providing middleware software on both the client and server, that interfaces the SDO-based programs executing on both client and server, with the Web services RPC infrastructure. On the client side, that middle- ware is responsible for taking the SDO arguments to RPC, converting them to their non-SDO equivalent5 and then reflecting the call to the corresponding server service (that expects those non-SDO parameters). The conversion between SDOs and their non-SDO equivalents is a high privilege operation. It must possess sufficient privi- leges to enable all data members of all of the SDOs that are being transferred between the client and server, to read and updated. In the prototype, the classes forming that middleware layer, were hand-crafted. However, by requiring SDOs to provide a set of similarly named accessor, mutator and constructor interface to that required by Web services tools, that middleware software should be able to be automatically generated. The SDOSE is expected to provide such a tool. Then the classes needed to support the transmission of SDOs will be generated at effectively the same time as the Web services toolkit generates the classes needed to support Web services based RPC, i.e. there will be no overhead for the SAA developer.
7.3 The SDO Support Environment API
The proposed preliminary SDOSE API is presented and discussed in this section. Since the use of the SDO concept does not change the functionality provided by SAAs, it only affects the manner in which authorisation is performed, much of the API is
5The term “non-SDO equivalent”, refers to the class that was generated by the Web services toolkit and contains the same data members as the SDO. 230 Chapter 7. The SDO Support Environment
unlikely to already be present within the libraries of secure SAA developers. Some functionality however is specific to the SDO-based SAAs. The API is based on experience gained though developing the prototypes used to support this initial research into the SDO concept, so some important functionality may have been overlooked. Despite its short-comings, the API will provide guidance in the development of suitable API for organisations that intend to apply the SDO concept to their SAA development.
7.3.1 Authentication Services
To utilise the authentication services provided by the SDOSE, an SAA must obtain a reference to an object which implements the SDOAuthenticator interface, either through direct instantiation or by using a factory class. Listing 7.1 presents that inter- face.
Listing 7.1 The authenticator interface SDOAuthenticator package sdose.security; import javax.security.auth.Subject;
public interface SDOAuthenticator {
/** login the user * @param numAttempts the number authentication attempts permitted * (must be greater than 0 otherwise 3 assumed) * @return null and the user was not authenticated * OR returns a new Subject object for the authenticated user */ public Subject authenticateUser(int numAttempts);
/** login the user */ public void logoutUser(Subject subject);
/** return the specified authorisation credential * @param subject the credentials of an authenticated user * @param type the string representation of the type of the * required credential * @return an object of the specified type from the subject, * or null if no such object is exists */ public Object getAuthorisationCredential(Subject subject, String type);
} // SDOAuthenticator 7.3. The SDO Support Environment API 231
Three methods are specified:
• authenticateUser which authenticates a user and returns a Subject object (which contains all of the identities and credentials that derived from the authentication process),
• getAuthorisationCredential which extracts an application-specific authorisation credential, from the collection of credentials in the user’s Subject object, and
• logoutUser, which destroys all temporarily stored information within the au- thentication sub-system that relates to that user.
As discussed in Section 5.3.1, since JAAS authentication is being used, a JAAS configuration file must be created which specifies the authentication mechanisms to be used, and the relevant LoginModule to support each of the specified authentication mechanisms. These are configuration changes, are made external to the code of the SAA.
7.3.2 Authorisation Services
An SDO delegates responsibility for performing access control to its associated autho- risation object. Authorisation objects implement the SDOAuthorisor interface which is presented in Listing 7.1. The authorisation services that they provide are best im- plemented by restricting access the methods of SDOs that access protected data and functionality (see Sections 4.2 and 5.3.3). The authorisation services defined are:
• isAllowed which performs a authorisation check and logs the event, and
• isMethodAccessPermitted which performs a authorisation check without log- ging the event.
Although the RBAC model for implementing mandatory access control is expected to be used, the authorisation services defined by the SDOAuthorisor interface, place no such restriction on the authorisation process. There is also no restriction on the type of object used as the authorisation credential as those methods accepts a parameter of type Object. Implementations of the interface must however be paired with the appropriate authentication counterpart, to ensure that the credentials generated as a result of authentication match those used for authorisation. 232 Chapter 7. The SDO Support Environment
Listing 7.2 The authorisor interface SDOAuthorisor package sdose.security;
public interface SDOAuthorisor {
public static final long STAT_MASK = 1L; public static final long VIEW_MASK = 2L; public static final long PRINT_MASK = 4L; public static final long SAVE_MASK = 8L;
/** a authorisation query which determines whether the user is * permitted to invoke the specified method from the specified class * This call IS NOT logged * @param uid the authorisation credential for the user * @param theObject the name of the class to which the method belongs * @param methodID the ID for the method that the user has attempted * to invoke * @return whether the user is permitted to invoke the specified * method */ public boolean isMethodAccessPermitted(Object uid, String theObject, long methodID);
/** a authorisation check to be used by SDOs to determine whether * the user is permitted to invoke the specified method from the * specified class * This call IS logged * @param uid the authorisation credential for the user * @param theObject the name of the class to which the method belongs * @param methodID the ID for the method that the user has attempted * to invoke * @param details additional information to be included within log * @return whether the user is permitted to invoke the specified * method */ public boolean isAllowed(Object uid, String theObject, long methodID, String details);
} // SDOAuthorisor 7.3. The SDO Support Environment API 233
The parameters of the authorisation methods, reflect the assumption that method authorisation is being used. The methodID parameter restricts the authorisation mech- anisms that can be employed, because methods are identified by number rather than name. Thus the specification as defined, tends to favour the bit-map representation of privileges associated with a role. An alternative (or a replacement) interface should be developed if the specified interface is incompatible with existing authorisation infras- tructure. The constants associated with the provision of usage rights (Section 6.8.1) have also been included within this interface6.
7.3.3 Audit Services
The audit services are essentially provided for use by SDOAuthorisation object to log authorisation events, however they are also available to the remainder of the SAA. The interface ApplicationLog, Listing 7.3, specifies the services available. Before an audit record can be written, the application log must have been opened by invoking the method openLog. Multiple openLog invocations must be allowed, especially if there are multiple instances of the application running on that machine. The log must be closed prior to application termination to allow the release of any application re- sources. Only the one method, addToLog, is provided to append an audit record to the application log. The extremely large number of audit records that can result from the adoption of the SDO paradigm, may restrict the potential implementations of this interface. It is likely that implementations will support the provision of a separate audit policy which specifies which authorisation requests must be audited. Rather than providing an interface, which specifies what functionality must be provided by implementations of that interface, an alternative approach would be to provide a single class which contains addToLog and closeLog as static methods. This approach has the advantage or not requiring an ApplicationLog object to be instanti- ated before making addToLog calls. That method can instantiate an ApplicationLog object, if necessary, before appending the audit record. This more convenient mecha- nism was used in the prototypes.
6Although not directly involved in the authorisation process, usage rights determine how the pro- tected data can be used, once released by an SDO. Since they are very closely related to authorisation, they have been included within this interface. 234 Chapter 7. The SDO Support Environment
Listing 7.3 The application log interface ApplicationLog package sdose.security; import javax.security.auth.Subject;
public interface ApplicationLog {
/** open the systemLog writing any error information to stdError */ public void openLog ( );
/** close the systemLog writing any error information to stdError */ public void closeLog ( );
/** append the details of an method authorisation check to the * already open application log * The appending of the audit record may or may not attempted, * depending upon the requirements of the application’s audit policy * @param uid the user’s authorisation credential * @param object the name of the object whose method was invoked * @param method the name of the method invoked * @param details additional information related to the invocation * @param success whether the authorisation check succeeded * @throws LogAppendException - if append fails. */ public void addToLog(Subject uid, String object, String method, String details, String success) throws sdose.security.LogAppendException;
} // ApplicationLog 7.4. Summary 235
7.3.4 Cryptographic Services
The interface CryptoFunctionality is based on the class of the same name, which is used in the HRIS prototype. The required cryptographic functionality is implemented entirely in software, using classes of the Java API and the Bouncy Castle implemen- tation of the Java Cryptography Extension (JCE) and cryptographic keys are stored in aJavakeyStore7. In a production system, that cryptographic functionality and key storage should be performed by trusted hardware. Hardware which conforms to the Trusted Computing Group’s Trusted Platform Module Specification (see Section 2.7) is a low cost source of that hardware support. To obtain a key from a Java keystore, its alias must be specified (together with the keystore password). Reflecting that implementation, all the cryptographic methods defined in the interface take a string parameter named keyAlias. The services fall into three categories8: encryption to provide confidentiality guarantees, message authenti- cation codes (or cryptographic checksums) to provide integrity guarantees and digital signatures to provide both integrity guarantees and non-repudiation. The interface currently reflects too closely the environment in which it originated. As noted earlier, keys are identified by names and the method isValidUserIDSignature that validates the signature in UserID objects, is a prototype specific service. This method, although apparently identical to its isValidSignature counterpart, it behaves differently. To prevent the production of fraudulent credentials using the signing ser- vice, the authentication subsystem and the CryptoFunctionality class share a secret that is combined with the UserIDs information, before a signature is computed.
7.4 Summary
This chapter has provided an overview of the services that will assist with the adoption of the SDO paradigm. The major observation that becomes apparent from the SDOSE described in this chapter is that using the SDO paradigm does not cause significant changes to the development process, nor to the environment in which SAAs execute. The majority of the comments made in the chapter relate to an attempt to provide a secure execution environment. The chapter has attempted to highlight the minimum
7A keyStore is described in the Java API documentation as being “a storage facility for crypto- graphic keys and certificates” [90]. 8The only category of services used in the prototype and hence actually put into practice were the signing services. 236 Chapter 7. The SDO Support Environment
Listing 7.4 The cryptographic functionality interface CryptoFunctionality package sdose.security;
public interface CryptoFunctionality {
/** encrypt plainText using the private key with alias keyAlias */ public byte[] encrypt(byte[] plainText, String keyAlias);
/** decrypt cipher Text using the public key with alias keyAlias */ public byte[] decrypt(byte[] cipherText, String keyAlias);
//*****************************************************
/** sign the message using the private key with alias keyAlias */ public byte[] sign(String msg, String keyAlias); public byte[] sign(byte[] msg, String keyAlias);
/** determine whether the signature is the valid signature for msg * using the key with alias keyAlias */ public boolean isValidSignature(String msg, byte[] signature, String keyAlias); public boolean isValidSignature(byte[] msg, byte[] signature, String keyAlias); public boolean isValidUserIDSignature(byte[] msg, byte[] signature, String keyAlias);
//*****************************************************
/** generate a MAC for the msg using the key with alias keyAlias */ public byte[] genMAC(String msg, String keyAlias); public byte[] genMAC(byte[] msg, String keyAlias);
/** is mac is the valid MAC for msg using key with alias keyAlias*/ public boolean isValidMAC(String msg, byte[] mac, String keyAlias); public boolean isValidMAC(byte[] msg, byte[] mac, String keyAlias);
//*****************************************************
/** convert the array of bytes to their String representation */ public String bytesToString(byte[] data);
} // CryptoFunctionality 7.4. Summary 237 services that should be provided for an SAA, including one based on the SDO concept, to perform its function. 238 Chapter 7. The SDO Support Environment Chapter 8
Conclusions and Future Work
8.1 Conclusions
The SDO concept is an extension to the current notion of the object-oriented program- ming paradigm. Using this extension, those objects which encapsulate the protected resources of a security aware application, are made aware of, and become responsible for controlling access to those resources. Thus, is concerned with the provision of mandatory access control to protect the resources of an object. The application of the SDO concept does not imply the need to replace the au- thorisation mechanisms currently being used within SAAs. Instead the SDO concept relates to where in the application, authorisation checks should be initiated. The purpose of this research was to investigate the viability of using the SDO con- cept as the basis for SAA development. Prior to this research, there was no published research into the use of any SDO-like approaches for the enforcement of access con- trol within SAAs. The major focus of this research has therefore been, to demonstrate that the approach has merit and to determine its strengths and weaknesses.
8.1.1 The Research Outcomes
An orthogonal view of the SDO concept is that it targets the provision of the funda- mental characteristics of SAAs, that they (1) mediate all accesses to their protected resources, (2) that those access control mechanisms cannot be bypassed (using the
239 240 Chapter 8. Conclusions and Future Work services provided by the SAA1), and (3) all such authorisation events are logged in accordance with the application’s audit policy.
8.1.1.1 Viability of the SDO Concept
Due to the absence of prior research in this area, the initial task was to devise a mech- anism by which SDOs would be able to control access to both kinds of protected resources that they might manage, data and functionality. The research conducted has indicated that the most suitable mechanism is to control access to those SDO methods through which protected resources are accessed. After all, those methods provide the only way that the SDO’s data and functionality can be accessed from within the SAA. The placing of authorisation checks in a method preamble has been demonstrated to be both an effective and convenient mechanism for restricting access SAA protected resources. That mechanism has been successfully used in both the CD Catalog and HRIS prototypes, previously discussed in this Thesis. After initially establishing that the SDO concept could be applied to the devel- opment of non-distributed SAAs, its applicability to the development of distributed SAAs was demonstrated. The generality of the SDO approach was demonstrated by developing a second version of the distributed HRIS prototype that used an orthogo- nal distributed computing model. Having shown that the SDO concept was compati- ble with both a traditional (proprietary) distributed computing model, namely the Java RMI model, and the currently popular Web services model, it is believed that the SDO concept has wide application.
8.1.1.2 SDO Concept Does Not Hamper SAA Development
Having demonstrated the feasibility of using the SDO concept as the basis for applying mandatory access control within SAAs, research focused on determining what restric- tions its use placed on the development process. Following experimentation using the HRIS prototype as a test bed, it was demonstrated that (1) the adoption of the SDO did not restrict the use of inheritance hierarchies, (2) restricted lifetimes for SDOs2 can be supported, (3) usage rights3 enforcement can be exerted even after protected content
1An SAA cannot control access to those resources that occur though any other means, such as the copying of file. Such protection is the responsibility of the operating system. 2This functionality is similar to that provided by digital rights management systems whereby a protected resource (e.g. a movie or soundtrack) is only made available for a specified period of time or number of uses. 3Usage rights restrict what a user is permitted to do with information (using the resources of the SAA), once it has left the SDOs, e.g. whether the information can be displayed or printed. 8.1. Conclusions 241 leaves their SDO, and (4) the use of cryptographic techniques to provide additional security guarantees was not restricted. Thus the use of the SDO concept is neither restrictive nor detrimental to the development process.
8.1.1.3 Ineffectivness of AspectJ
Another significant finding was that the use of aspect oriented programming language, AspectJ, did not provide the level of support for the implementation of the SDO con- cept that might be expected (see Section 6.9). The SDO concept is believed to be a valuable extension to the object-oriented pro- gramming paradigm. In the following subsections, its major strengths and weaknesses will be identified, and ways of avoiding some of its weaknesses suggested.
8.1.2 The Strengths
The main strength of the SDO concept is the intuitive manner in which access control is applied within an SAA. Access control is localised within objects, extending the trend of the last two decades in which access to data within programs has become increasingly localised, culminating in the object-oriented paradigm. When the SDO concept is applied, those methods that provide access to protected resources, are also responsible for enforcing mandatory access control on those resources. Such an ap- proach necessarily ensures that the access control measures cannot be circumvented because the only place the resource can be accessed, is where authorisation is per- formed. The majority of the responsibility for authorisation within an SAA is localised within the SDOs, so the remainder of the SAA is almost unaware of the need to pro- vide authorisation. From a design viewpoint, SDOs are the logical place for locating responsibility for authorisation. The SDO and its methods are concerned with the maintenance of the integrity of the information resources for which they are respon- sible. In an SAA, preserving integrity includes the provision of controlled access to those resources. By employing the services of a separate authorisation object, which makes authorisation decisions on its behalf, the implementation of SDOs is essen- tially unchanged from that of a normal object. The additional requirement is that each SDO method that accesses a protected resource, should initiate an authorisation check and enforce the decision made. These functions can typically implemented as a small method preamble. 242 Chapter 8. Conclusions and Future Work
Two properties of this approach to authorisation make it particularly amenable to code reviews, which provide a crucial mechanism for the identification of errors, both during development and final conformance testing. Firstly, locating the authorisation code within the preamble of the method makes it ideally situated for code inspections. Its presence, or absence is easily determined. Secondly as the authorisation decision is based on an authorisation credential and an identifier associated with the method, (typically either its name or similarly named constant), ensuring that the appropriate authorisation check is being performed is greatly simplified. Another strength of the SDO paradigm is that both the financial cost associated with its adoption, and the disruption to current practices, should be minimal. The intuitive nature of the SDO concept and the fact that the development process does not need to be modified as a result of its adoption, means that there is no requirement to undertake major staff retraining to facilitate its adoption. Further as the SDO con- cept does not involve a radical change in the development, currently available object- oriented programming languages and development environments provide the basic facilities required to support the SDO concept, i.e. there is no need to replace the cur- rent development tools. There will be some costs incurred in either developing (or purchasing, if they become available) a suitable SDOSE.
8.1.3 The Weaknesses
8.1.3.1 Excessive Authorisation Checking
The major weakness of the SDO approach relate to efficiency, in particular the number of authorisation checks that are performed, and the related number of audit records generated. The cornerstone of the SDO concept is that whenever a protected resource is accessed, that method performing that access will initiate an authorisation check. This mechanism ensures that authorisation cannot be bypassed. However under certain circumstances, unnecessary authorisation will be performed. Those situations, include when:
• data is copied from one SDO to another. Since the information is not being released, but instead being copied from one secure encapsulation4 to another, authorisation checks are logically unneces- sary. For example, in the ‘Web services prototype’, numerous ‘unnecessary’
4The term ‘secure encapsulation’ in this context means, that the encapsulated data can only be accessed after an authorisation check is performed. It does not imply that the SDO will provide any absolute security guarantees. 8.1. Conclusions 243
authorisation checks are incurred as the middleware software reads and updates protected data members (using their accessor and mutator methods), as the con- versions between SDO and their non-SDO equivalents are carried out. This deficiency cannot be overcome. When an SDO method accesses a pro- tected resource it must, ‘by definition’, perform authorisation. If the SDO con- cept is not being used, this situation does not arise. Authorisation only occurs once when the information server creates the software object containing the requested protected information. The SDO philosophy, in contrast, provides multi-level protection. Access control continues to be enforced, even after the protected information is released by the server (SDO), as it is still encapsulated within an SDO. The basis of the SDO philosophy is that only authorised users can gain access to protected information. As in any secure system, efficiency is subordinate to security. In situations in which the SDO is being copied to another SDO of the same type5, the provision of a ‘copy’ method, which potentially might not be pro- tected, is a way to avoid unnecessary authorisation checks.
• a protected method invocation propagates up the inheritance hierarchy. This is not a result of the application of the SDO paradigm alone. The problem only arises when different access control rules apply to a data member depend- ing on the type of the object. Each time there is a different rule, the relevant SDO method needs to be overridden in order to apply the relevant authorisa- tion check. At runtime, not only must that authorisation check be performed, but authorisation checks will be performed in each superclass that defined its own ‘specialised’ authorisation check. This problem was discussed in detail in Section 6.7.1.1. This problem cannot be overcome. It arises from the combination of several factors: (1) SDOs are responsible for performing application level access con- trol; (2) direct access to data members is confined to the methods of the defining class, i.e. data members are declared as being private; (3) the security policy dictates that for some object types in the class hierarchy, a specific authorisation check must be performed; and (4) if a mechanism was provided that would al- low the authorisation check performed in a superclass to be avoided, then that
5For example, an SDO would need to be copied if an ‘information server’ encapsulates a collection of records, one or more of which need to be returned to fulfill a client request. 244 Chapter 8. Conclusions and Future Work
mechanism could be used by other code. Thus, if the SDO concept is used, there is no solution to this problem.
• the data model for a GUI object contains SDOs. This is not a deficiency of the SDO concept as this situation can easily be avoided by not including SDOs within the data model of GUI objects. This topic was discussed in depth in Section 5.5. Since GUI objects act as a proxy for the user within a program, the required SDO semantics are being adhered to when the relevant information from the SDO (or SDOs) and stored in the GUI object’s data model. The user will still only gain access to that information to which they are entitled as the SDO ap- plies the appropriate access control rules as the data is copied to the GUI object.
The common factor in each of the above cases, is that the SDO can not know the context of the access, and hence whether authorisation should be performed. It must perform the specified authorisation check. If the SDOs are not being used, the context of the information access should be known, so the developer can determine whether authorisation should, or should not be applied in that particular situation. Making an incorrect determination of whether authorisation should be performed, is potentially a source of flaws in the current implementation of ‘discretionary’ mandatory access control. In contrast, the application of the SDO philosophy may result in the excessive enforcement of mandatory access control. Keeping things in perspective, security not efficiency, should be the primary concern of an SAA.
8.1.3.2 Audit Problems
Associated with the large number of authorisation checks, is a correspondingly large number of audit records. Since the details of all authorisation checks are sent to the audit/ log object, all authorisation checks could potentially be logged. As discussed in Section 4.3.2, one way to both tailor the audit process to the requirements of legit- imate users of the application’s audit record, and potentially to reduce the number of authorisations logged, is to enforce an audit policy that specifies those authorisation events which should be logged. The number of audit records generated can also be reduced by having SDOs pro- vide authorisation ‘queries’. Authorisation queries allow parts of the application, e.g. 8.1. Conclusions 245
GUI objects to determine the result of an authorisation check without that authori- sation event being logged (see Section 5.3.3.2.1 for an discussion of authorisation queries and whether they should be provided). If that application’s security policy does not forbid their use, authorisation queries provide a mechanism to reduce the number of (possibly) irrelevant audit records generated. SDOs never use such ‘queries’ before accessing a protected resource, as the security policy not the application developer, decides whether or not an authorisation decision should be logged.
8.1.3.3 Choice of Authorisation Model
Care needs to be taken when choosing how authorisation should be implemented within SDOs, as the decision made can have significant memory or network band- width implications. In the prototypes, authorisation decisions were made by an autho- risation object that was encapsulated within the SDO, i.e. each SDO had a dedicated AO. Those AOs, in turn, encapsulated that authorisation information which related to that particular SDO. What soon became apparent when using this model, was the volume of that authorisation information being held with the SDOs. The problem was compounded when inheritance hierarchies were involved. The adoption of this particular model can have dire consequences in terms of excessive memory usage and network bandwidth consumed6. The bandwidth consequences were more significant when the bandwidth hungry Web services (distributed com- puting) model was used. In some applications, these problems can be reduced by (1) choosing a model (and authorisation implementation) that increases the amount of authorisation object sharing (reducing memory usage), and (2) avoiding the transmission of authorisation information when SDOs are passed between machines (reducing network bandwidth). For other applications, where the amount of authorisation information relating to an SDO is small compared to its information content, having a dedicated SDO might be considered beneficial.
8.1.3.4 Are the Weaknesses Significant?
The weaknesses of the SDO paradigm are not believed to constitute a major imped- iment to the adoption of that paradigm. While working on this project, the three weaknesses that were most apparent were:
6In the prototypes, the authorisation information was orders of magnitude larger than the data being protected, making this approach highly inefficient (in that situation). 246 Chapter 8. Conclusions and Future Work
1. the excessive authorisation associated with SDOs in GUI data models As identified, this problem can be avoided by copying the data from the SDOs into the data model. The unnecessary authorisation checks that occur elsewhere are less likely to be significant in practice than they were in the prototypes. In the prototype, every data member was protected, and the access rules were deliberately changed in each subclass to allow experimentation, so the number of ‘extraneous’ authorisation checks being performed were larger than would be expected in practice.
2. the resource usage associated with allocating a dedicated AO for each SDO The memory problem can be avoided through the sharing of AOs between SDOs. For many applications, the sharing of AOs between all the objects of a class may prove to be an acceptable compromise between the competing re- quirements of minimising resource usage and providing flexibility. The band- width problem can also be avoided by not sending the AO, when an SDOs is being sent between machines. Instead, the relevant AO is obtained at the desti- nation. In this thesis, it is assumed that a high level of trust exists between the parts of the (single) SAA that are distributed across multiple machines and that the integrity of the system is maintained i.e. the SAA at a particular site will not substitute an inappropriate security policy in the form of an inappropriate AO. Even if these assumptions are completely wrong, and the AO supplied allows all accesses, all is not lost. That scenario is current execution environment without SDOs.
3. the excessive number of audit records generated This problem remains unresolved and requires further research. Potentially in- cluding a consideration of the source of the authorisation event as well as its type, in deciding whether an authorisation event should logged, might prove useful.
It is believed that the strengths of the SDO paradigm, are much more significant than its weaknesses, so extension of this research is warranted. 8.2. Future Work and the Potential for SDO Concept 247
8.2 Future Work and the Potential for SDO Concept
8.2.1 Scalability
This research demonstrated that the SDO concept is both feasible and worthwhile. However, the prototypes developed to support this research, were necessarily sim- ple small-scale SAAs. The most pressing need is to determine whether practical SAAs can be developed using the SDO concept, i.e. the scalability of the SDO concept re- mains unexplored.
8.2.2 Application to Non GUI Application Domains
The research conducted to date has dealt with GUI-based SAAs which required only limited interaction between the objects that comprise the application. The applicability of the SDO concept to SAAs, or communicating SAAs, that incorporate complex interactions between numerous objects requires investigation.
8.2.3 Application to e-Health
Should the SDO concept prove to be scalable, the contribution made by this research will be significant. Increased security within distributed information systems is in- creasingly being demanded by both users and legislation. An example of an appli- cation domain in which the SDO concept could be invaluable, is e-Health. Current legislative requirements in the United States (HIPAA), and elsewhere, demand that personal health information be kept secure. Still, health information and the access control constraints that relate to its use, remain separate. SDOs provide an intrinsic and permanent coupling of protected data and the access control restrictions relating to that data. When combined with encryption, SDOs will provide a reliable mechanism for ensuring that personal health information is only made available to its intended recipient. Research into this, and similar applications of the SDO concept warrant investigation.
8.2.4 SDOs Adapt to their Environment
The increasing globalisation of information systems results in difficulties with the dis- tribution of data. The information needs of users must be met in such a way that they meet local requirements, i.e. information must be provided that is: (1) tailored 248 Chapter 8. Conclusions and Future Work to meet the requirements of the nation/ state in which the information is being ac- cessed, e.g. the appropriate language used and the information provided reflects local legal requirements; and (2) compatible with the security status of the destination, e.g. different information subsets are made available to different departments within the organisation, different partner organisations etc. Currently such restrictions are applied at the information source, with the ‘infor- mation server’ only providing the minimal subset of information that that is required to meet the needs of its recipient. However,the SDO paradigm offers an alternative approach, that warrants investigation. With the advent of very high speed commu- nications links, it has become plausible to dispatch SDOs that encapsulate all of the available information (rather than just its recipient’s subset). Such enhanced SDOs would not only perform authorisation (as discussed in this thesis), but would also tai- lor their respond to service requests to match their current environment. Should the SDO be accessed by a different user in potentially a different environment, it could continue behave appropriately. For static information, that SDO/ information might be further migrated. As it con- tains all the relevant information, the appropriate information can now be provided in its new environment. Current objects can not behave in this manner. This approach is effectively the information system equivalent of the common digital rights man- agement practice of freely distributing the copyright material, but only making that material available after the user purchases some subset of the available usage rights.
8.2.5 Audit
A major problem experienced while working with SDOs, was the inability to produce an audit trail which did not contain large numbers of unnecessary audit records. The current practice of specifying a separate audit policy to address the different, though related, issues of authorisation and the generation of the audit trail, only partially addresses the problem. Research into the generation of a complete, yet concise, audit trail in SDO-based SAAs (and object-oriented applications in general) is desperately needed.
8.2.6 Critical Infrastructure
The role that the SDO concept might play in the protection of national infrastructure, in particular those based on the Supervisory Control and Data Acquisitions (SCADA) 8.2. Future Work and the Potential for SDO Concept 249 architecture, was explored in the APIEMS’05 Conference paper that has been repro- duced in Appendix G. The proposed architecture, that is based on a marrying of con- text aware computing and the SDO concept, apparently would have produced a real improvement in the security of that hypothetical system. With the potential benefits offered by the SDO concept, and the identified need to secure national infrastructure, attempts to control access to hardware devices using SDOs should be explored further.
8.2.7 Pervasive Computing
Another major area of potential future research relates to the role of SDOs in a per- vasive computing environment. In the next twenty years, we are likely to see a dis- tributed computing environment in which (1) much of the insecurity of the Web due to the non-trustworthiness of computing devices will have been resolved, (2) the majority of computing power will reside in dedicated devices [110], and (3) the object oriented paradigm will dominate [111]. In such a futuristic scenario, the idea of using SDOs as the normal vehicle for transferring data is credible. Such objects would be able to migrate throughout the ‘trusted Internet’ and no matter where they are located, the SDOs will ensure that the appropriate access control measures are enforced. Making this possibility a reality, forms a long term research goal. 250 Chapter 8. Conclusions and Future Work Appendix A
WSDL Description of the EmployeeServer
A.1 Command to generate WDSL Description wscompile -define -verbose -cp . etc\xml_gen_config.xml
A.2 Configuration File: “xml gen config.xml”
A.3 The EmployeeServer Interface
// File: HrSystem\etc\EmployeeServer.java /** * @author John Holford
251 252 Appendix A. WSDL Description of the EmployeeServer
* Created on 28/06/2004 */ package common; import common.UserIDsuperClass; import java.util.Collection;
public interface EmployeeServer extends java.rmi.Remote {
/** return the all the records in the EmployeeServer * @param uid the user for whom the SDOReadOnlyList is being created * @param dummyParam a dummy parameter to distinguish between the two load calls * @return a StringArrayList containing all the data from the datastore * @throws DataStoreException if database operation fails */ public NonSDOStringArrayList load (UserIDsuperClass uid, boolean dummyParam) throws DataStoreException, java.rmi.RemoteException;
/** return the all the records in the EmployeeServer * @return an Array of NonSDOEmployee objects containing all the * data from the datastore * @throws DataStoreException if database operation fails */ public NonSDOEmployee[] load2 (UserIDsuperClass uid) throws DataStoreException, java.rmi.RemoteException;
/** gets an existing record from the EmployeeServer * @param empNo the employee number for the desired record * @return the record having the specified employee number * OR null and no maching record exists * @throws common.security.DataStoreException if database operation fails */ public NonSDOEmployee get ( UserIDsuperClass uid, String empNo ) throws DataStoreException, java.rmi.RemoteException;
/** removes a record from the EmployeeServer * @param empNo the employee number for the desired record * @return true and the record corresponding to key was removed * OR false and no corresponding record existed * @throws common.security.DataStoreException if database operation fails */ public boolean remove (UserIDsuperClass uid, String empNo ) throws DataStoreException, java.rmi.RemoteException;
/** adds a record to the EmployeeServer * @param employee the non-existing employee record to be added * @return true and element was added * OR false and an element already existed * @throws common.security.DataStoreException if database operation fails */ A.3. The EmployeeServer Interface 253
public boolean add (UserIDsuperClass uid, NonSDOEmployee employee ) throws DataStoreException, java.rmi.RemoteException;
/** update the information stored in the EmployeeServer about * an employee from its current state to "replElement" * @param replElement the new information which is to be stored in * the EmployeeServer for an existing element (the only * data used to identify the existing element is the empNo) * @throws DataStoreException if datastore operation fails */ public boolean update ( UserIDsuperClass uid, NonSDOEmployee replElement) throws DataStoreException, java.rmi.RemoteException;
/** gets the name of an employee from the EmployeeServer * @param empNo the employee number of the relevant employee * whose name is requested * @return the name of the employee having the specified employee number * @throws DataStoreException if database operation fails */ public String getName ( UserIDsuperClass uid, String empNo ) throws DataStoreException, java.rmi.RemoteException ;
/** gets the position of an employee from the EmployeeServer * @param empNo the employee number of the relevant employee * whose name is requested * @return the position of the employee having the specified employee number * @throws DataStoreException if database operation fails */ public String getPosition( UserIDsuperClass uid, String empNo) throws DataStoreException, java.rmi.RemoteException;
/** determines whether a record associated with the specified employee number * is present in the EmployeeServer * @param empNo the employee number for the desired record * @return whether a record associated with the specified * employee number is present in the EmployeeServer * @throws DataStoreException if database operation fails */ public boolean isPresent ( UserIDsuperClass uid, String empNo ) throws DataStoreException, java.rmi.RemoteException;
/** return the number of records in the EmployeeServer * @return the number of records in the EmployeeServer * @throws DataStoreException if database operation fails */ public int getNumRecords ( UserIDsuperClass uid ) throws DataStoreException, java.rmi.RemoteException;
} // interface EmployeeServer 254 Appendix A. WSDL Description of the EmployeeServer
A.4 WSDL Description of the EmployeeServer
SOAP Messages captured at Server
B.1 get Request Message
4/10/2005 18:39:56 com.sun.xml.wss.filter.DumpFilter process INFO: ==== Received Message Start ====
261 262 Appendix B. SOAP Messages captured at Server
B.2 get Response Message
4/10/2005 18:39:56 com.sun.xml.wss.filter.ExtendedProcessSecurityHeaderFilter getSecurityHeader WARNING: WSS0202: No wsse:Security element in the message 4/10/2005 18:39:56 com.sun.xml.wss.filter.DumpFilter process INFO: ==== Sending Message Start ====
The HRWebServicesConnection Class
// file: HRSystem\webServer\webclient\common\HRWebServicesConnection.java
/** * @author John Holford * Created on 20/09/2004 * */ package common;
//imports import java.rmi.RemoteException; import java.rmi.Remote; import javax.security.auth.Subject; import javax.xml.rpc.*;
//import common.security.SDOAuthenticator; import common.security.SDOAuthorisor; import common.security.AuthorisationCache; import common.UserID; import common.security.SDOClassConverter; import common.security.HRUserIDCreator; import java.util.Collection; import java.util.Iterator; import java.util.Vector;
/** This class provides client classes with access to the EmployeeServer Web Services Server. It is an "SDO environment system" class. The client exchanges Employee SDO objects with this class, while it interacts
265 266 Appendix C. The HRWebServicesConnection Class
with the web services server with the required NonSDOEmployee objects. */ public class HRWebServicesConnection {
private boolean debug = false;
private SDOAuthorisor authorisor; private UserID suid;
private EmployeeServer webServer;
public HRWebServicesConnection(){ AuthorisationCache.openAuthorisationCache( );
// suid = new HRUserIDCreator().generateUserID("su", "SU", "su"); suid = getSuperUserID("Client: Superuser Login"); if (suid==null) throw new RuntimeException( "HRWebServicesConnection: unable to create su UserID");
// use static stubs to override endpoint property of WSDL String serviceHost = System.getProperty("endpoint.host"); String servicePort = System.getProperty("endpoint.port"); String serviceURLFragment = System.getProperty("service.url"); String serviceProtocol = System.getProperty("endpoint.protocol"); String serviceURL = serviceProtocol + "://" + serviceHost + ":" + servicePort + serviceURLFragment;
System.out.println("Service URL=" + serviceURL);
try { HRWebService webService = new HRWebService_Impl(); EmployeeServer_Stub stub = (EmployeeServer_Stub) webService.getEmployeeServerPort(); webServer = (EmployeeServer)stub; stub._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, serviceURL); } catch (Throwable t) { System.out.println("CLASS: " + t.getClass().getName() + "\n\n"); System.out.println(t.getMessage()); t.printStackTrace(System.out); System.out.println(); System.out.println(); } // try catch
} // HRWebServicesConnection
/** gets all the Employee records from the EmployeeServer * @param uid the user credential used for authorisation of this 267
* method call * @return all the employee records in a StringArrayList object * @throws common.security.DataStoreException if database * operation fails * @throws SecurityException if the user is not authorised to make * this method call */ public StringArrayList load ( UserID uid, boolean dummy ) throws DataStoreException { try { NonSDOStringArrayList nssal = webServer.load(uid, dummy); if (!(nssal instanceof NonSDOStringArrayList)) throw new DataStoreException( "HRWebServicesConnection.load:Unsupported NonSDOReadOnlyList"); if ( debug ) System.out.println("HRWebServicesConnection.load: \n\t" + nssal.toString()); return SDOClassConverter.convertToStringArrayList(suid, nssal); } catch (RemoteException re) { if ( debug ) System.out.println("HRWebServicesConnection.load :" + re.getMessage()); throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch }//load
/** gets all the Employee records from the EmployeeServer * @param uid the user credential used for authorisation of this * method call * @return all the employee records as a collection of Employee * objects * @throws common.security.DataStoreException if database * operation fails * @throws SecurityException if the user is not authorised to make * this method call */ public Collection load ( UserID uid) throws DataStoreException { try { NonSDOEmployee[] data = webServer.load2 (uid); Collection result = new Vector(); for (int i=0; i if(debug){ System.out.println("\n\nHRWebServicesConnection.load:"); Iterator iter = result.iterator(); while (iter.hasNext()) { System.out.println("\t" + iter.next().toString()); }//while System.out.println("\n\n"); }//ifdebug return result; } catch (RemoteException re) { if(debug) System.out.println("HRWebServicesConnection.load: " + re.getMessage()); throw new DataStoreException("RemoteException: " + re.getMessage()); } // catch }//load /** gets an existing record from the EmployeeServer * @param uid the user credential used for authorisation of this * method call * @param empNo the employee number for the desired record * @return the record having the specified employee number * OR null and no maching record exists * @throws common.security.DataStoreException if database * operation fails * @throws SecurityException if the user is not authorised to make * this method call */ public Employee get(UserID uid, String empNo) throws DataStoreException { try { NonSDOEmployee nonSDOEmp = webServer.get(uid, empNo); if(debug) System.out.println("HRWebServicesConnection.get: \n\t" + nonSDOEmp.toString()); return SDOClassConverter.convertToSDOEmployee( suid, nonSDOEmp); } catch (RemoteException re) { if(debug) System.out.println("HRWebServicesConnection.get: " + re.getMessage()); throw new DataStoreException("RemoteException: " + re.getMessage()); } // catch }//get 269 /** adds a record to the EmployeeServer * @param employee the non-existing employee record to be added * @return true and element was added * OR false and an element already existed * @throws SecurityException if the user is not authorised to make * this method call * @throws common.security.DataStoreException if database * operation fails */ public boolean add (UserID uid, Employee employee ) throws DataStoreException { try { NonSDOEmployee emp = SDOClassConverter.convertToNonSDOEmployee(suid,employee); if ( debug ) System.out.println("HRWebServicesConnection.add: \n\t" + emp.toString()); return webServer.add(uid, emp); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch }//add /** update the information stored in the EmployeeServer about * an employee * from its current state to "replElement" * @param replElement the new information which is to be stored in * the EmployeeServer for an existing element (the only * data used to identify the existing element is the empNo) * @throws SecurityException if the user is not authorised to make * this method call * @throws DataStoreException if datastore operation fails */ public boolean update ( UserID uid, Employee replElement) throws DataStoreException, java.rmi.RemoteException { try { NonSDOEmployee replEmp = SDOClassConverter.convertToNonSDOEmployee( suid, replElement); if ( debug ) System.out.println("HRWebServicesConnection.update:\n\t" + replEmp.toString()); return webServer.update(uid, replEmp); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch } // update 270 Appendix C. The HRWebServicesConnection Class /** removes a record from the EmployeeServer * @param empNo the employee number for the desired record * @return true and the record corresponding to key was removed * OR false and no corresponding record existed * @throws SecurityException if the user is not authorised to make * this method call * @throws common.security.DataStoreException if database * operation fails */ public boolean remove (UserID uid, String empNo ) throws DataStoreException { try { return webServer.remove(uid, empNo); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); } // catch } // remove /** gets the name of an employee from the EmployeeServer * @param uid the user credential used for authorisation of this * method call * @param empNo the employee number of the relevant employee * whose name is requested * @return the name of the employee having the specified * employee number * @throws SecurityException if the user is not authorised to * make this method call * @throws DataStoreException if database operation fails */ public String getName (UserID uid, String empNo ) throws DataStoreException { try { return webServer.getName(uid, empNo); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); } // catch } // getName /** gets the position of an employee from the EmployeeServer * @param uid the user credential used for authorisation of this * method call * @param empNo the employee number of the relevant employee * whose name is requested * @return the position of the employee having the specified * employee number * @throws SecurityException if the user is not authorised to * make this method call 271 * @throws DataStoreException if database operation fails */ public String getPosition(UserID uid, String empNo) throws DataStoreException { try { return webServer.getPosition(uid, empNo); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch } // getPosition /** determines whether a record associated with the specified * employee number is present in the EmployeeServer * @param uid the user credential used for authorisation of * this method call * @param empNo the employee number for the desired record * @return whether a record associated with the specified employee * number is present in the EmployeeServer * @throws SecurityException if the user is not authorised to make * this method call * @throws DataStoreException if database operation fails */ public boolean isPresent (UserID uid, String empNo ) throws DataStoreException { try { return webServer.isPresent(uid, empNo); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch } // isPresent /** return the number of records in the EmployeeServer * @param uid the user credential used for authorisation of * this method call * @return the number of records in the EmployeeServer * @throws SecurityException if the user is not authorised * to make this method call * @throws DataStoreException if database operation fails */ public int getNumRecords ( UserID uid ) throws DataStoreException { try { return webServer.getNumRecords(uid); } catch (RemoteException re) { throw new DataStoreException("RemoteException: " + re.getMessage()); }//catch } // getNumRecords 272 Appendix C. The HRWebServicesConnection Class } // class HRWebServicesConnection Appendix D Class SDOClassConverter // file: HRSystem\common\security\ClassConverter.java package common.security; import common.*; import java.util.Vector; import java.util.Enumeration; public class SDOClassConverter { private static final boolean signEmployeeObjects = common.HRConfigurationConstants.signEmployeeObjects; private static boolean debug = false; private static final int numRecElements = 3; private static final int role = 0; private static final int object = 1; private static final int method = 2; private SDOClassConverter( ) { } // SDOClassConverter // ********************************************************************* // ************************** doMethodPermissionCheck // ********************************************************************* 273 274 Appendix D. Class SDOClassConverter /** a convenience method this method is called at the start of each * protected method of this SDO to determine whether the specified * method may be envoked on behalf of the entity specified by uid * @param uid the id and role of the entity on whose * behalf the method is being invoked * @param method the identifier used to specify the method being * invoked in the security policy and will also appear in the * string associated with the exception should one be raised */ private static void doMethodPermissionCheck(UserID uid, String className, String method) { if (!(uid.getRole().equals("SU") ) ) { throw new SecurityException(uid.getRole() + " cannot call " + className + "." + method); } } // doMethodPermissionCheck () // ****************************************************************** // ************************** Type Conversion Methods // ****************************************************************** // ****************************************************************** // *************************** StringArrayList conversions // ****************************************************************** public static NonSDOStringArrayList convertToNonSDOStringArrayList( UserID uid, StringArrayList orig) { NonSDOStringArrayList result; doMethodPermissionCheck (uid, "SDOClassConverter", "convertToNonSDOStringArrayList"); if (debug) { System.out.println( "SDOClassConverter.convertToNonSDOStringArrayList: \n\t" + orig.toString()); CryptoFunctionality crypto = CryptoFunctionality.getInstance(); crypto.displayBytes(orig.getSignature()); } result = new NonSDOStringArrayList( ); String[] userMethodAuths = orig.getUserMethodAuthorisations(uid); if (debug) System.out.println("userMethodAuths size=" + userMethodAuths.length); result.setUserMethodAuthorisations(userMethodAuths); 275 Vector methodAuths = orig.getMethodAuthorisations(uid); if (debug) System.out.println("methodAuths size=" + methodAuths.size()); result.setMethodAuthorisations(methodAuths); result.setStrBufferList(orig.getStrBufferList(uid)); result.setNumReadsPermitted(orig.getNumReadsPermitted(uid)); result.setNumReadsPerformed(orig.getNumReadsPerformed(uid)); result.setSdoDataDestroyed(orig.getSdoDataDestroyed(uid)); result.setSDOPermissions(orig.getSDOPermissions()); result.setSignature(orig.getSignature()); if (debug) { System.out.println( "SDOClassConverter.convertToNonSDOStringArrayList:" + " signature after conversion \n" ); CryptoFunctionality crypto = CryptoFunctionality.getInstance(); crypto.displayBytes(result.getSignature()); } orig.clear(); if (debug) { System.out.println( "SDOClassConverter.convertToNonSDOStringArrayList:" + " NonSDOStringArrayList object created"); System.out.println( result.toString() ); }//ifdebug return result; } // convertToNonSDOStringArrayList public static StringArrayList convertToStringArrayList(UserID uid, NonSDOStringArrayList orig) { StringArrayList result; doMethodPermissionCheck (uid, "SDOClassConverter", "convertToStringArrayList"); if (debug) { System.out.println( "SDOClassConverter.convertToStringArrayList: \n\t" + orig.toString()); CryptoFunctionality crypto = CryptoFunctionality.getInstance(); crypto.displayBytes(orig.getSignature()); } String[] userMethodAuths = orig.getUserMethodAuthorisations(); Vector methodAuths = orig.getMethodAuthorisations(); 276 Appendix D. Class SDOClassConverter result = new StringArrayList(methodAuths, userMethodAuths, orig.getStrBufferList(), orig.getNumReadsPerformed(), orig.getNumReadsPermitted(), orig.getSdoDataDestroyed(), orig.getSDOPermissions(), orig.getSignature( )); if (debug) { System.out.println("SDOClassConverter.convertToStringArrayList:" + " signature after conversion \n" ); CryptoFunctionality crypto = CryptoFunctionality.getInstance(); crypto.displayBytes(result.getSignature()); } orig.clear(); if (debug) { System.out.println( "SDOClassConverter.convertToStringArrayList:" + " StringArrayList object created"); System.out.println( result.toString() ); } return result; } // convertToNonSDOStringArrayList // ************************************************************************* // ******************************************** Employee conversions // ************************************************************************* public static NonSDOEmployee convertToNonSDOEmployee(UserID uid, Employee employee) { NonSDOEmployee emp; doMethodPermissionCheck (uid, "SDOClassConverter", "convertToNonSDOEmployee"); Vector methodAuths = employee.getMethodAuthorisations(uid); if (debug) { System.out.println("SDOClassConverter.convertToNonSDOEmployee: \n\t" + employee.toString()); System.out.println("methodAuths size=" + methodAuths.size()); } emp = new NonSDOEmployee( ); emp.setMethodAuthorisations(methodAuths); if (debug) { Vector temp= emp.getMethodAuthorisations(); System.out.println("emp.getMethodAuthorisations() size=" + temp.size()); } 277 if (employee instanceof Executive) { if (debug) System.out.println("SDOClassConverter. convertToNonSDOEmployee:" + " converting an Executive object"); emp.setEmpType("Executive"); emp.setPerformanceBonus(((Executive)employee) .getPerformanceBonus(uid)); emp.setCarDetails(((Executive)employee).getCarDetails(uid)); } else if (employee instanceof Manager) { if (debug) System.out.println("SDOClassConverter.convertToNonSDOEmployee:" + " converting an Manager object"); emp.setEmpType("Manager"); emp.setCarDetails(((Manager)employee).getCarDetails(uid)); emp.setPerformanceBonus(""); }else{ if (debug) System.out.println("SDOClassConverter.convertToNonSDOEmployee:" + " converting an Employee object"); emp.setEmpType("Employee"); emp.setCarDetails(""); emp.setPerformanceBonus(""); } emp.setSDOPermissions(employee.getSDOPermissions()); emp.setEmpNo(employee.getEmpNo(uid)); emp.setName(employee.getName(uid)); emp.setPhone(employee.getPhone(uid)); emp.setPosition(employee.getPosition(uid)); emp.setSalary(employee.getSalary(uid)); emp.setHomePhone(employee.getHomePhone(uid)); if (signEmployeeObjects) emp.setSignature(employee.getSignature( )); else emp.setSignature(null); employee.clear(); if (debug) { System.out.println("SDOClassConverter.convertToNonSDOEmployee" + " after clear(): \n\t" + employee.toString()); System.out.println("SDOClassConverter.convertToNonSDOEmployee:" + " NonSDOEmployee object created"); showNonSDOEmployeeDetails( emp ); } return emp; } // convertToNonSDOEmployee // *********************************************************************** 278 Appendix D. Class SDOClassConverter public static Employee convertToSDOEmployee(UserID uid, NonSDOEmployee employee) { Employee emp; doMethodPermissionCheck (uid, "SDOClassConverter", "convertToEmployee"); if (debug) System.out.println("SDOClassConverter.convertToSDOEmployee: \n\t" + employee.getName( ) + " " + employee.toString()); String empType = employee.getEmpType(); Vector methodAuths = employee.getMethodAuthorisations(); if (debug) System.out.println("methodAuths size=" + methodAuths.size()); if (empType.equals("Executive")) { if (debug) System.out.println("SDOClassConverter.convertToSDOEmployee:" + " creating an Executive object"); emp = new Executive(methodAuths); ((Executive)emp).setPerformanceBonus(uid, employee.getPerformanceBonus()); ((Executive)emp).setCarDetails(uid, employee.getCarDetails()); } else if (empType.equals("Manager")) { if (debug) System.out.println("SDOClassConverter.convertToSDOEmployee:" + " creating an Manager object"); emp = new Manager(methodAuths); ((Manager)emp).setCarDetails(uid, employee.getCarDetails()); } else if (empType.equals("Employee")) { if (debug) System.out.println("SDOClassConverter.convertToSDOEmployee:" + " creating an Employee object"); emp = new Employee(methodAuths); }else{ throw new RuntimeException("SDOClassConverter.convertToSDOEmployee" + " - unknown NonSDOEmployee type"); } if (debug) { Vector temp = emp.getMethodAuthorisations(uid); System.out.println("temp size=" + temp.size()); } emp.setSDOPermissions(uid, employee.getSDOPermissions( )); emp.setEmpNo(uid, employee.getEmpNo( )); emp.setName(uid, employee.getName( )); emp.setPhone(uid, employee.getPhone( )); emp.setPosition(uid, employee.getPosition( )); emp.setSalary(uid, employee.getSalary( )); emp.setHomePhone(uid, employee.getHomePhone( )); if (signEmployeeObjects) emp.setSignature(employee.getSignature( )); else emp.setSignature(null); 279 // employee.clear(); emp.checkSignature(); if (debug) { System.out.println("SDOClassConverter.convertToSDOEmployee" + " after clear(): \n\t" + employee.toString()); System.out.println("SDOClassConverter.convertToSDOEmployee:" + " SDOEmployee object created"); System.out.println(emp.toString()); } return emp; } // convertToSDOEmployee /* *********************************************************** */ /* *********************************************************** */ /* ****************** Debugging routines follow ************** */ /* *********************************************************** */ /* *********************************************************** */ /** display the first count method authorisations */ private static void displayMethodAuthorisations(Vector methodAuths, int count) { int numEntries = methodAuths.size(); System.out.println("Method authorisations - " + numEntries + " entries present"); // at most display the specified number of entries if (count < numEntries) numEntries = count; System.out.println("First " + numEntries + " entries:"); for(inti=0;i System.out.println("\n\n"); } // displayMethodAuthorisations private static void showNonSDOEmployeeDetails(NonSDOEmployee e){ System.out.println("\n\nSDOClassConverter:\nNonSDO Employee Details:"); 280 Appendix D. Class SDOClassConverter System.out.println("EmpNo:\t\t" + e.getEmpNo( )); System.out.println("Permissions:\t\t" + e.getSDOPermissions( )); String empType = e.getEmpType( ); System.out.println("EmpType:\t" + empType); System.out.println("Name:\t\t" + e.getName( )); System.out.println("Phone:\t\t" + e.getPhone( )); System.out.println("Position:\t" + e.getPosition( )); System.out.println("Salary:\t\t" + e.getSalary( )); System.out.println("HomePhone:\t" + e.getHomePhone( )); if (empType.equals("Executive")) { System.out.println("carDetails:\t" + e.getCarDetails( )); System.out.println("pBonus:\t" + e.getPerformanceBonus( )); } else if (empType.equals("Manager")) { System.out.println("carDetails:\t" + e.getCarDetails( )); } Vector methAuths = e.getMethodAuthorisations(); if (methAuths == null) System.out.println("MethodAuthorisations is null"); else displayMethodAuthorisations(methAuths, 3); System.out.println(); } // showNonSDOEmployeeDetails private static void showSDOEmployeeDetails(UserID uid, Employee e){ System.out.println("\n\nSDOClassConverter:\nSDO Employee Details:"); System.out.println("EmpNo:\t\t" + e.getEmpNo( uid )); System.out.println("Permissions:\t\t" + e.getSDOPermissions( )); System.out.print("EmpType:\t"); if (e instanceof Executive) { System.out.println("Executive"); } else if (e instanceof Manager) { System.out.println("Manager"); }else{ System.out.println("Employee"); } System.out.println("Name:\t\t" + e.getName( uid )); System.out.println("Phone:\t\t" + e.getPhone( uid )); System.out.println("Position:\t" + e.getPosition( uid )); System.out.println("Salary:\t\t" + e.getSalary( uid )); System.out.println("HomePhone:\t" + e.getHomePhone( uid )); if (e instanceof Executive) { System.out.println("carDetails:\t" + 281 ((Executive)e).getCarDetails(uid)); System.out.println("pBonus:\t" + ((Executive)e).getPerformanceBonus(uid)); } else if (e instanceof Manager) { System.out.println("carDetails:\t" + ((Manager)e).getCarDetails(uid)); } Vector methAuths = e.getMethodAuthorisations(uid); if (methAuths == null) System.out.println("MethodAuthorisations is null"); else displayMethodAuthorisations(methAuths, 3); System.out.println(); } // showSDOEmployeeDetails } // SDOClassConverter 282 Appendix D. Class SDOClassConverter Appendix E Enabling Application and Link level Protection E.1 Security Configuration File: “encrypt-server.xml” 283 284 Appendix E. Enabling Application and Link level Protection E.2 Security Configuration File: “encrypt-client.xml” E.3 An Non Encrypted delete Request Message Note: Some lines of the captured message were too long to fit on the page and so have be split. All indented lines are a continuation of the preceding line. 8/10/2005 14:47:45 com.sun.xml.wss.filter.DumpFilter process INFO: ==== Received Message Start ==== E.4 An Encrypted delete Response Message Note: Some lines of the captured message were too long to fit on the page and so have be split. All indented lines are a continuation of the preceding line. 8/10/2005 14:34:50 com.sun.xml.wss.filter.DumpFilter process INFO: ==== Sending Message Start ==== The aspect EmployeeSDOAspect package aspectj; import org.aspectj.lang.*; import common.UserID; import common.Employee; import common.Manager; import common.Executive; import common.security.SDOAuthorisor; aspect EmployeeSDOAspect { private boolean eDebug = false; // ************************ Get Methods **************************** pointcut executiveGet(Executive emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Executive.get*(..) ) && within(Executive) ); pointcut managerGet(Manager emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Manager.get*(..) ) && within(Manager) ); pointcut employeeGet(Employee emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Employee.get*(..) ) 287 288 Appendix F. The aspect EmployeeSDOAspect && within(Employee) ); // ------ Object around(Executive emp, UserID uid) : executiveGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String className = sig.getDeclaringType().getSimpleName(); String methodName = sig.getName(); if (! emp.authorisor.isAllowed(uid,className,methodName) ) { if (eDebug) System.out.println(uid.getRole() + " no " + className + "." + methodName); if (methodName.equals("getSalary") || methodName.equals("getSDOPermissions") ) { return new Long(Employee.internalInvalidLong); } else { return Employee.internalInvalidString; }//if }else{ if (eDebug) System.out.println(uid.getRole() + " can call " + className + "." + methodName); return proceed(emp, uid); } }//advice Object around(Manager emp, UserID uid) : managerGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String className = sig.getDeclaringType().getSimpleName(); String methodName = sig.getName(); if (! emp.authorisor.isAllowed(uid,className,methodName) ) { if (eDebug) System.out.println(uid.getRole() + " no " + className + "." + methodName); if (methodName.equals("getSalary") || methodName.equals("getSDOPermissions") ) { return new Long(Employee.internalInvalidLong); } else { return Employee.internalInvalidString; }//if }else{ if (eDebug) System.out.println(uid.getRole() + " can call " + className + "." + methodName); return proceed(emp, uid); } }//advice Object around(Employee emp, UserID uid) : employeeGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String className = sig.getDeclaringType().getSimpleName(); 289 String methodName = sig.getName(); if (! emp.authorisor.isAllowed(uid,className,methodName) ) { if (eDebug) System.out.println(uid.getRole() + " no " + className + "." + methodName); if (methodName.equals("getSalary") || methodName.equals("getSDOPermissions") ) { return new Long(Employee.internalInvalidLong); } else { return Employee.internalInvalidString; }//if }else{ if (eDebug) System.out.println(uid.getRole() + " can call " + className + "." + methodName); return proceed(emp, uid); } }//advice // ************************ Set Methods **************************** pointcut executiveSet(Executive emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Executive.set*(..) ) && within(Executive) ); pointcut managerSet(Manager emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Manager.set*(..) ) && within(Manager) ); pointcut employeeSet(Employee emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Employee.set*(..) ) && within(Employee) ); // ------ before(Executive emp, UserID uid) : executiveSet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); setCode(emp, uid, sig); }//advice 290 Appendix F. The aspect EmployeeSDOAspect before(Manager emp, UserID uid) : managerSet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); setCode(emp, uid, sig); } // advice before(Employee emp, UserID uid) : employeeSet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); setCode(emp, uid, sig); } // advice private void setCode(Employee emp, UserID uid, Signature sig) { String methodName = sig.getName(); String className = emp.getClass().getSimpleName(); if (eDebug) System.out.println("Role="+ uid.getRole() + " className=" + className + " methodName=" + methodName); if (! emp.authorisor.isAllowed(uid,className,methodName) ) { if (eDebug) System.out.println(uid.getRole() + " no"+className + "." + methodName); throw new SecurityException(uid.getRole() + " no " + className + "." + methodName); } if (eDebug) System.out.println(uid.getRole() + " can call " + className + "." + methodName); }//setCode // ************************ Can Methods **************************** // ****** CanGet Methods ********* pointcut executiveCanGet(Executive emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Executive.canGet*(..) ) && within(Executive) ); 291 pointcut managerCanGet(Manager emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Manager.canGet*(..) ) && within(Manager) ); pointcut employeeCanGet(Employee emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Employee.canGet*(..) ) && within(Employee) ); // ------ boolean around(Executive emp, UserID uid) : executiveCanGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "g"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); }//advice boolean around(Manager emp, UserID uid) : managerCanGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "g"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); }//advice boolean around(Employee emp, UserID uid) : employeeCanGet( emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "g"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); }//advice // ****** CanSet Methods ********* pointcut executiveCanSet(Executive emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Executive.canSet*(..) ) && within(Executive) ); 292 Appendix F. The aspect EmployeeSDOAspect pointcut managerCanSet(Manager emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Manager.canSet*(..) ) && within(Manager) ); pointcut employeeCanSet(Employee emp, UserID uid) : target(emp) && args(uid,..) && ( execution(public * common.Employee.canSet*(..) ) && within(Employee) ); // ------ boolean around(Executive emp, UserID uid): executiveCanSet(emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "s"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); }//advice boolean around(Manager emp, UserID uid) : managerCanSet(emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "s"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); }//advice boolean around(Employee emp, UserID uid):employeeCanSet(emp, uid) { Signature sig = thisJoinPoint.getSignature(); String methodName = "s"+sig.getName().substring(4) ; String className = emp.getClass().getSimpleName(); return canCode(emp, uid, sig, className, methodName); } // ************ canCode ************* boolean canCode(Employee emp, UserID uid, Signature sig, String className, String methodName) { if (emp.staticAuthorisor==null) { System.out.println("staticAuthorisor is null"); 293 emp.staticAuthorisor = new SDOAuthorisor ("Employee"); } if (eDebug) System.out.println("Role="+ uid.getRole() + " className=" + className + " methodName=" + methodName); // to test of the get and set implementation: uncomment next line // and set flag usingCan in DataStoreImpl if (true) return true; boolean result = emp.staticAuthorisor.isMethodAccessPermitted( uid, className, methodName); if (eDebug) { System.out.print(uid.getRole() + " can "); if (!result) System.out.print( "NOT "); System.out.println( "call " + className + "." + methodName); } return result; } } // EmployeeSDOAspect 294 Appendix F. The aspect EmployeeSDOAspect Appendix G APIEMS’04 Conference Paper ARCHITECTURE FOR SECURING CRITICAL INFRASTRUCTURES USING CONTEXT-AWARE SELF-DEFENDING OBJECTS Harikrishna Vasanta, John W. Holford, William J. Caelli and Mark Looi. Faculty of Information Technology Queensland University of Technology GPO Box 2434, Brisbane Qld 4001 Australia h.vasanta, j.holford, w.caelli, [email protected] ABSTRACT The increasing use of general-purpose computer systems for critical infrastructure control, rather than the traditional dedicated system, raises significant security con- cerns. These concerns are further compounded by the integration of these control systems with general-purpose networks and the use of wireless technologies within these networks. Consequently, control systems are becoming increasingly vulnerable to a large range of attacks which may result in significant environmental and financial consequences such as a recent attack on a sewage treatment plant in Queensland. Cur- rent systems rely on singular border protection mechanisms like firewalls. Although such an approach is effective in the majority of cases, if breached, currently avail- able commercial operating systems provide little additional protection. Clearly, this is inadequate for critical infrastructures control systems. This paper proposes a secure context-based architecture to remedy this deficiency. It is based on the use of self- defending objects and location based authentication and authorisation. A hypothetical 295 296 Appendix G. APIEMS’04 Conference Paper chemical plant scenario is used to illustrate the use of the proposed mechanism. The proposed architecture is expected to help negate the security vulnerabilities introduced through the use of general-purpose computer systems and wireless technology to con- trol critical infrastructure. Key Words: Information Security, Information Technology, Telecommunica- tions. G.1 INTRODUCTION Critical control systems are computer systems that are used to monitor and control sen- sitive processes (e.g. chemical plants) and distribution systems (e.g. electricity distri- bution). Traditionally such control systems were specifically designed for their partic- ular application using special purpose components and were kept separate from other information systems. To gain efficiency and economic advantages, control systems are using wireless technologies and are being integrated into the general IT networks. Additionally, there is a move toward the standardization of the control system archi- tecture, for example, the adoption of standardized communications protocols within the Supervisory Control and Data Acquisitions (SCADA) architecture. Such changes significantly increase the vulnerability of control systems to attack. In 2000, attacks were mounted against a sewage pumping station in Queensland, resulting in the re- lease of very large amounts of raw sewerage. This insider attack was also significant in that it employed wireless technology and was specifically targeted at taking over the control system. The current approach to providing network security is based on the establishment of a secure perimeter by using firewalls. Such an approach is inherently flawed. Once these protection measures are breached, an intruder effectively has free access to the network. To overcome this deficiency, Ganger and Nagle [29, 30] (Ganger and Na- gle, 2000, 2001) proposed a security architecture in which individual network devices were responsible for their own protection, effectively establishing separate security perimeters around each device. In this paper, a variation to their approach is proposed to secure control systems. Rather than using dedicated hardware, a software solution based on the use of self- defending objects (SDOs) is proposed. The SDO approach is an extension to the current object oriented programming paradigm such that software objects which pro- G.2. BACKGROUND INFORMATION 297 vide security sensitive functionality or hold sensitive information, are responsible for protecting those resources. In control systems, a separate SDO will be responsible for both control and protection of each security significant device, ensuring that the device only responds to instructions from authorised users. To achieve this aim in an increasingly wireless environment, the SDOs will employ a location based access control mechanism. A secure context-based architecture based on these principles, we believe will be effective in securing control systems. Important aspects of the ar- chitecture include: (1) it requires limited changes to the existing infrastructure, (2) it prevents an attacker from gaining access to the whole system should a breach of the perimeter defences occur, and (3) through the use of a location based access control mechanism prevents attacks launched from external mobile wireless devices. This paper is organized in the following fashion: Section G.2 provides the reader with sufficient background information to be able to appreciate the significance of the proposed control system architecture; Section G.3 provides a detailed discussion of the deficiencies with the existing methods of securing the control systems of crit- ical infrastructures and how the proposed architecture addresses these deficiencies, Section G.4 provides an detailed description of the architecture, while Section G.5 outlines how the architecture might be applied to an effluent treatment unit of a sul- phuric acid plant and details a number of attacks that are mitigated by the adoption of the architecture . In Section G.6, the paper concludes with a discussion of issues relating to this architecture and identifies areas of future research. G.2 BACKGROUND INFORMATION In this section, the reader is introduced to a number of previously unrelated areas of research, which in combination form the basis of the proposed control system archi- tecture. G.2.1 Security Aware Applications & Access Control A security aware application (SAA) is an application program whose operation is dependent upon security information. That characteristic is normally reflected by pro- viding different functionality to different users. To clarify what is meant by the term ’security aware application’, consider the security requirements of the health care sec- tor. Patients demand, and legislation requires, that access to medical records should only be granted on a ’need to know’ basis. In a medical system, when access to a 298 Appendix G. APIEMS’04 Conference Paper patient’s medical record is requested, whether the access should be granted, depends on who is making the request. Due to the complexity of such access control decisions, a major component of such an SAA is the access control subsystem. Access control has two aspects: authentication, the process by which a user pro- vides proof of their identity, and authorisation, the determination of whether that user should be given access to a particular resource. Authentication of the user’s identity may be based on a combination of factors from the following classes: (1) something that they know, e.g. a password, (2) something that they have, e.g. a swipe card, and (3) something they are, e.g. a fingerprint or retinal scan. The authorisation decision is often based on the presentation of a token / credential obtained following authen- tication, and a set of rules that specify which users are able to access each protected resource. These rules are referred to as the application’s security policy. In our med- ical scenario, once the user has established that they are the doctor currently treating a particular patient, they would be permitted to both read and append to, the patient’s medical history. However, somebody who is not authorised to use the system, or an- other doctor not involved in the treatment of that patient, would be refused access to the medical record. Due to the complexity of allocating the large number of rights required by individ- uals to perform their duties, a form of access control called role based access control (RBAC) is increasingly being adopted. The approach reduces the administrative over- head as rights are assigned to roles and the individual users are associated with roles. For example, the role ’doctor’ is allocated the access rights needed by a doctor to perform their duties. The role ’doctor at hospital X’ will have those additional rights allocated that are needed by a doctor working at X, to access the information resources administered by that hospital. When a new doctor arrives at X, they need only be as- sociated with the role ’doctor at hospital X’ to gain all those numerous rights. A SAA must not only restrict access to its protected resources. It must also main- tain an audit trail. The audit trail records all attempted accesses to protected resources, regardless of whether the access was granted or not. Such information is vital for both verifying that the security policy is being correctly enforced, and when a security breach occurs, determining the extent of the breach and who was responsible. The information system as a whole also needs to ensure that the information can- not be viewed or modified by means other than through authorised applications. That requirement might be realized using such techniques as encryption (to secure infor- mation in transit across the network) and hosting the application, its security configu- G.2. BACKGROUND INFORMATION 299 ration information and persistent forms of the information, e.g. databases, on a secure platform. G.2.2 Self-Defending Objects (SDOs) The use of the self-defending object (SDO) concept in the construction of SAAs was described by Holford [1,2]. The SDO concept extends the current object oriented pro- gramming paradigm such that software objects which provide security sensitive func- tionality or hold sensitive information, are responsible for protecting those resources. This protection has two aspects: the enforcement of that portion of the application’s security policy which relates to its protected resources and the generation of the related audit trail entries. Within an SDO based application, the right of a user to call each method (function / procedure) which accesses a protected resource, is checked before the method is executed. To support this access control check, such methods are passed an application specific credential which is used to validate the user’s right to invoke the method. The rationale for using SDOs to protect sensitive resources is natural. In an object- oriented program, the relevant object provides the only means of accessing the re- source. That object is therefore the most appropriate point at which to perform access control checks and log accesses. This coupling of the single point of access and the checking of the validity of that access, ensures that the access control mechanism cannot be bypassed. The SDO approach cannot, by itself, guarantee the ultimate the protection of sen- sitive resources as it can only control accesses made from within the application. A protected operating environment, preferably a trusted operating system, is needed to ensure that the application level protection mechanisms cannot be bypassed, e.g. the databases and security policy configuration on which the application relies, must be protected from direct access by hackers. G.2.3 Issues In Wireless Local Area Networks Wireless local area networks, especially the 802.11 family of products, are being adopted to provide connectivity within industry, business and the home as they per- mit device mobility, are easy to deploy and are extremely cost effective. The use of wireless technologies is transparent to both applications and users connected to the network as the upper layers of the communication protocols remain the same. How- 300 Appendix G. APIEMS’04 Conference Paper ever, wireless networks are inherently different from their wired counterparts and as such pose a greater security risk. Wireless networks do after all rely on radio broadcast to provide their communication channel, making their signals available to all passive listeners tuned to the same communication frequency. A wired local area network lo- cated within a secured site and having the wiring isolated from normal access offers a significant degree of physical protection. Should a wireless connection be introduced into such a network, network traffic potentially becomes available to individuals pass- ing the site. This issue aside, both classes of network are vulnerable to similar types of attacks including: snooping or passive monitoring of the network traffic, modification of the traffic between the nodes, masquerading attacks (where an unauthorised person gets access to the network by pretending to be an authorised user), and the denial of service attacks. Cryptography is cited as being a cure for all security problems. However, the need to choose an appropriate cryptographic solution is highlighted by the occurrence of a number of successful attacks on the physical layers of IEEE 802.11 WLANs have been discovered and even the cryptographic protocols used to establish privacy and authentication in WLANs have been successfully broken [112]. Thus, along with the advantages of wireless technologies comes an inherent in- crease in security risk due to the loss of physical security. The proposed architecture addresses this problem through the use of location as a factor in the access control system. G.2.4 Context Aware Computing The widespread adoption of mobile communication and the ability to determine the location of such devices has lead to increased research into context aware computing. The majority of this research relates to the provision of new services including context based advertising and guiding systems [113]. Of particular interest to this paper is the possibility of enhancing the security of networks, which include mobile devices. In such systems, the location of the mobile device, hence its user is used as one factor in the multi-factor authentication and/or authorisation processes. The location of a device, which may or may not be in the possession of the user, can be determined using a range of technologies including Global Positioning sys- tems (GPS), Global System for Mobile Communications (GSM), Wireless LAN, ac- tive badges etc. Such location information is often of too coarse for making access control decisions so the integration of multiple positioning technologies is often used G.2. BACKGROUND INFORMATION 301 to provide sufficiently accurate location information. G.2.5 Incorporation Of Location Within Security Applications Secure systems normally incorporate strong authentication mechanisms that are based on multi-factor authentication to physically gain access to the system. The use of wireless technology bypasses the need to gain physical access to the system and these devices might only protected by a weak knowledge based authentication mechanism (e.g. password). The inclusion of location of the mobile device as a factor in the au- thentication process helps to improve this security deficiency. A user using a portable data assistant (PDA) might only be able to connect, if it can be established that the PDA is ’on site’, especially useful when the perimeter is secure. The use of location based authentication and authorisation has been described in a number of papers. Looi [114] presented an architecture in which location information was used to enhance authentication in Internet banking. Wullems [115] presented an access control mechanism that incorporated location information into the authorisa- tion process. In that system, an authenticated user was only permitted to remotely access resources while their PDA remained within a specified area. To authenticate a user or authorise a request, based on location information, the location information needs to be derived securely and its transmission tamper-proof. It has been estab- lished for some time that reliable location information can be obtained from multiple technologies, e.g. GSM using ’Cyber locator’ [116]. We believe that the use of location based access control mechanisms in both the au- thentication and authorisation processes, will be extremely useful in protecting critical infrastructures which permit the use wireless technologies in their control systems. G.2.6 Self Securing Devices Ganger and Nagle [29, 30] observed that current network security relies heavily on the establishment of a secure perimeter by using firewalls and the security features of COTS (commercial off the shelf) operating systems. They concluded that such an approach is inherently flawed as once these border protection measures have been breached, an intruder effectively has free access. In accordance with the principle of ’defence in depth’, they proposed a security architecture in which individual net- work devices, including storage devices, network cards, routers and switches, are re- sponsible for their own protection. Then the secure perimeter protection provided by 302 Appendix G. APIEMS’04 Conference Paper firewalls is supplemented by separate security perimeters around individual network devices. These enhanced devices, which they call ’self securing devices’, not “only protect their own resources, they can observe, log, and react to the actions of other nearby devices. Compromises of one security perimeter will compromise only a small fraction of the network environment” [30]. In related papers, Strunk et al. [31, 117] provides a description of how a self-securing device, namely a storage server, was implemented. Making hardware devices responsible for their own security provides both a novel and effective way of increasing the security within critical infrastructures, which are permitted to use wireless technologies. G.2.7 Critical Control Systems Critical control systems are computer systems that are used to monitor and control sensitive processes (including water treatment, petrochemical and chemical plants) and distribution systems (e.g. gas and electricity distribution). A number of different types of control systems are in use including Supervisory Control and Data Acquisi- tions (SCADA), Distributed Control Systems (DCS) and Programmable Logic Con- trollers (PLC). Various government bodies across the globe have recognized the need to protect control systems and declared that they constitute critical infrastructure that should be protected [118]. Control systems are vulnerable to a large range of attacks, which could result in: • disruption to their normal operation by delaying or blocking the flow of the information through their networks and hence loss of control. o taking control of PLCs or DCSs, causing them to perform unauthorised operations. The effect of loss of control includes equipment damage, supply disruption and significant environmental / financial damage. • false alarms being received that cause disruption to production or supply of essential services. Traditionally control systems were designed as dedicated stand-alone systems. Be- cause each control system was unique, an attack that worked on one system would be ineffective on other systems. With the use of COTS computing components and standardized communications protocols, the integration of control systems and the enterprise network (and even the internet) and the adoption of wireless technology, G.3. MOTIVATION 303 Critical Infrastrcutre Enterprise Network Laptop computer Workstation Firewall Enterprise network: The process where all the External Networks Printer Application business operations are carried Hub Server out along with correspondence to outside vendous,customers. Control System Supervisory Control & Monitoring Unit Supervisory Control & Monitoring Unit Contains the Servers,workstation and Human conrtol interfaces that collect monitor and log Human Control Interface information send by remote/local stations Engineering Server Workstation Remote station Contains the remote terminal Remote/Local Control Remote/Local Control unit (RTU), Programmable logic controller(PLC),or distributed control unit(DCS) controller DCS/RTU/PLC DCS/RTU/PLC which receives and interepts the signals from the sensor and Sensor generates corresponsding Control Control control signals to the supervisory systems Sensor systems control and monitoring unit Modem PDA Laptop computer Handheld device Figure G.1: Control System these systems are becoming vulnerable to cyber attacks or even cyber-terrorist attacks (see Figure G.1). Because only border protection mechanisms (firewalls) are normally used to protect such networks, an intruder who gains access to the local network also has access to the control systems. The increase in standardization also means that an attack successful on one control system may disrupt others. G.3 MOTIVATION As previously discussed, the control system is a vital component in most critical in- frastructures and as such, demands a high degree of protection. However control systems are increasingly being constructed using COTS components and integrated into the general IT networks. Consequently, the use of (1) standardized IT technolo- gies with their known vulnerabilities, (2) the adoption of wireless technologies, (3) the lack of physical access control barriers, and (4) the current reliance on singular border protection mechanisms, has significantly increased the vulnerability of control systems. Although they do not occur often, a number of recent events demonstrate that con- trol systems are vulnerable. In March/April 2000, an attacker mounted 46 attacks on 304 Appendix G. APIEMS’04 Conference Paper sewerage pumping station in Queensland, Australia. The subsequent release of very large amounts of raw sewerage into local waterways caused significant environmen- tal and financial damage. This attack was also significant in that it involved the use of wireless technology and specifically aimed at taking control of the control system. Although the attack was effectively an ’insider attack’, as the attacker had access to propriety radios and software, a concerning aspect of the attack was the apparent ease with which it was carried out [119]. In 1999, a group of hackers with help of an insider, gained control of Gazprom’s gas network allowing them to control pipeline gas flows for a short time [120]. (Gaz- prom is the world’s largest natural gas producer.) Worms and viruses pose a serious threat to control systems, which include standard IT components and communications protocols, even when they are not the intended target of the attack. In January 2003, the ’SQL Slammer Worm’ penetrated the Ohio nuclear plant, despite the presence of firewalls causing the temporary shutdown of the nuclear plant [121]. The slammer worm also affected electrical systems in the United States of America. The traffic generated by the worm swamped the network, blocking SCADA traffic. The worm penetrated the SCADA system via a remote computer using a virtual private network (VPN) connection, bypassing the network’s firewall protection [122]. These incidents demonstrate vulnerability of a modern, technology-dependent so- ciety to attacks on the control systems. Should a cyber-terrorist attack be mounted on a control system, with the aim of maximizing the damage or disruption that it causes, the consequences of the loss of control of critical infrastructures could be devastating. Such a scenario highlights the need to adequately secure control systems. An integral part of securing any computer system is the provision of access control, which limits access to both the system and individual resources, to authorised entities. One way of strengthening both authentication and authorisation is to incorporate con- textual information, rather than relying purely on establishing the identity of the user. Location information is particularly useful when wireless technology is being used. When used, a system might refuse access to an otherwise legitimate user because they are not ’on site’, simulating the physical access control mechanisms afforded by wired systems. The self-securing device approach also has a role to play in the strengthening of control network security. However, we believe that the adoption of such special- purpose hardware runs contrary to the current trend away from the use of dedicated hardware. Instead, a software means of providing self-securing devices, through the G.4. THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE 305 use of SDOs is considered more appropriate. The SDO concept would provide the underlying design paradigm for the control system. In addition to the protection of information resources, SDOs would also be responsible for the control and protection of security significant devices, transforming the devices into self-defending devices. SDOs take on a new emphasis in the control of industrial processes particularly where the associated messaging systems are based around wireless technologies. Wire- less transmissions received by a self-defending device might have originated from any wireless device within range, so the use of authorisation is vital. In accordance with the SDO approach, such control instructions must necessarily be accompanied by an appropriate authorisation token. The self-defending device will use the location of the transmitting device as a factor in determining whether the control instruction is legitimate and hence should be executed. The device should also be capable of acting autonomously, in a fail-safe manner, in event of an attack or communications dis- ruption. As identified in Section G.2.2, another important aspect of the protection provided by SDOs is the generation of an audit trail. The use of a context aware access control mechanism and SDOs helps to define a secure architecture, which we believe will be effective in securing control systems. An important aspect of the architecture is that it protects control systems with lim- ited changes to the existing infrastructure and in a scalable manner; while helping to prevent, or minimize, the potential damage and interruption in the event of an attack. The multi-layered approach prevents an attacker from gaining access to the whole system should a breach of the perimeter defences occur, while the use of a location based access control mechanism prevents attacks launched from ’off site’ mobile wire- less platforms (provided that the location information is both accurate and cannot be spoofed). G.4 THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE In this section, the security architecture and associated communication protocols will be described. It is believed that this architecture will overcome the security related de- ficiencies in the design of current control systems that were identified in Section G.3. How the architecture could be applied to the control system of a sulphuric acid plant is described in Section G.5. The architecture delivers multilayered security, by supplementing the border pro- 306 Appendix G. APIEMS’04 Conference Paper tection provided by firewalls and COTS operating systems, with application level, context aware access control measures. A basic assumption of the architecture is that the system will be implemented using an object oriented programming language and the design based on the SDO concept. In line with current trends, the SDOs will en- force role based access control on their protected resources. To counter the continued adoption of wireless communication within control systems, the architecture includes location as a crucial factor in the authorisation process. The adoption of the architec- ture will facilitate the construction of systems with sufficient strength to protect critical control systems, despite the security ramifications of using wireless technology. G.4.1 Self-defending Objects And Control Systems In control systems, the control of all devices and all access to sensitive information resources should be restricted to authorised users. Unfortunately the overhead of per- forming the authorisation checks needed to provide the additional security adversely impacts performance. The additional complexity introduced by incorporating contex- tual information such as location, into a security architecture is particularly problem- atic. The authorisation servers have the potential of becoming system bottlenecks. However, the inclusion of location information is warranted in order to combat the increased vulnerability of the system resulting from the use of wireless technologies. The overriding requirement for deterministic real-time performance of the system, and its safety critical nature, means that the need for complete security must be left unfulfilled. Conversely, the execution of control instructions sent by an attacker might have significant environmental, operational or safety consequences. The possibility of such an event occurring, particularly when wireless communication is involved, was demonstrated by the multiple successful attacks on a sewerage pumping station (see Section G.3 or [119]). To balance these opposing concerns, a risk analysis should be conducted to de- termine which hardware and software resources must be protected. The analysis will identify those objects, which should be self-defending. Given the need to perform authorisation before accessing the identified critical resources, the use of SDOs will ensure that the required checks will be performed. The audit trail generated by the SDOs will also be valuable in determining the actions preceding an incident, whether the cause was accidental or deliberate. G.4. THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE 307 G.4.2 Overview Of The Access Control Mechanism The access control mechanism proposed is similar to standard access control mech- anisms used elsewhere, other than the inclusion of location as a factor in the autho- risation process and the use of SDOs to ensure that the authorisation measures are consistently applied. The presence of wireless connections makes the direct connec- tion of an attacker to a control device or subsystem possible thereby bypassing the perimeter security measures. From a security viewpoint, it becomes essential for con- trol software to defend itself from potential attacks. Part of this defence is ensuring that not only is the user making the request is authorised, but also that any wireless communications (in particular) originated ’on site’ or from a trusted secure location. Location should be used as a factor within the authentication process thus ensuring that the user must be ’on site’ before being able to gain access to the system. However, as a result of the authentication process, a user credential, which certifies the identity of the user, their authenticated role and device identifier being used, is generated. As one might expect, the details of the user’s location at the time of authentication is not included. The user’s role is required for role based authorisation, while their identity is required to determine their location and for audit trail generation. The device ID is needed to determine the location of the user’s communication device. G.4.3 The Authorisation Mechanism The authorisation mechanism is illustrated in Figure G.2. The block diagram em- phasises authorisation decision-making mechanism, particularly the incorporation of location information. In the discussion, which follows, it will be assumed that the location of the user and their registered communication device will both be used in the authorisation process. Potentially, only one of these pieces of location information could be used, but the security would be diminished as a result. Each of the major components of the authorisation system is individually described in the remainder of this section, while the next section deals with the information exchange between these components. G.4.3.1 User The user is the entity that requests a service from the system. The request might be a command sent by a wireless hand held device connected to the control system or a workstation in the enterprise network trying to access files at the supervisory control 308 Appendix G. APIEMS’04 Conference Paper Access Control Unit Request for location DCSM Location Response for location server Authorisation Server Request for Authorisation Authorisation authenication Network Operator request response Authenication response Request for service Response for service Application User Server Figure G.2: The Authorisation System and monitoring station. If that request is being mediated by the system, it will result in a call to a method of the SDO which controls access to the relevant resource. G.4.3.2 Application Server The application server represents the entity that receives the request from the user, so represents all the software objects of the system. As discussed in Section G.4.1, only selected objects will be self-defending and will perform authorisation checks before performing the requested operation. G.4.3.3 Access Control Unit (ACU) The Access Control Unit is responsible for making the access control decision on be- half of an SDO. That decision is based on whether that user has the ’right’ to execute that SDO method and also whether the location of both the user and their communi- cation device are acceptable. Correspondingly, the access control unit is divided into two sub-units: the Authorisation Server and the Dynamic Context Service Manager (DCSM). G.4.3.3.1 Authorisation Server The authorisation server determines whether the user, acting in their current role, is permitted to call the SDO method. It enforces that portion of the access control policy, which relates to users and resources, and ignores the location of the user. If the user is found to have the right to access the resource, the G.4. THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE 309 DCSM is called to verify that the user request was sent from an acceptable location. Otherwise the request is rejected immediately. G.4.3.3.2 Dynamic Context Service Manager (DCSM) The DCSM is responsi- ble for verifying that the user’s request originated from an acceptable location, i.e. it is responsible for enforcing the context component of the access control policy. The DCSM obtains the location of the user and device from the location server. Depending on the nature of the request, the granularity of the location required and its recency is likely to vary. For some method calls, it might be sufficient to know the user is ’on site’, while for more sensitive calls the request might need to originate from a particu- lar terminal in the control room. An important consideration is whether the location of the user and their communicating device coincide. Based on the location information, the DCSM determines whether the access should be granted. G.4.3.4 Location Server (LS) The Location Server (LS) is responsible for providing the last recorded location of users and their communicating devices (to the required granularity) and times at which those readings were made. The LS continually monitors wireless transmissions, per- sonnel tracking devices, etc. which enables such requests satisfied immediately. Where possible, the location information is derived from multiple sources to ensure its accu- racy. G.4.3.5 Network Operator The network operator is responsible for maintaining up to date authentication and authorisation (security policy) information. G.4.4 Authorisation Communication Protocols In this section, the steps involved in the authorisation process and associated high level communication protocols will be discussed. Only the information flows needed to support the architecture are described. Numerous secure protocols have been pro- posed [123,124] to ensure that the communications are secure, i.e. message confiden- tiality, integrity and authenticity are preserved. That aspect of the communications protocols is considered to be out of the scope of this paper. The major steps involved in a providing a service to a user are: 310 Appendix G. APIEMS’04 Conference Paper 1. the request for service is sent by the user 2. the authorisation request is sent by an SDO 3. the authorisation decision is made by the Access Control Unit 4. if authorised, the SDO performs the service When presenting the content of messages, the notations presented in Table G.1 are used. Entities U Client requesting the service (the user) AS Application Server (an SDO is assumed) ACU Access Control Unit AuthSer Authorisation Server DCSM Dynamic Context Service Manager LS Location Server Elements UCred The user’s authorisation credential UID The user ID (from authorisation credential) DID The communication device ID (from authorisation credential) SerReq The Request for service SerRes The Service result MethodName The name of the SDO method being envoked Gran Granularity of location information required UserLoc Location of user DeviceLoc Location of device ΥUserLoc Time the user location was recorded ΥDeviceLoc Time the device location was recorded BoolRes A boolean authorisation result Table G.1: Protocol Notations G.4.4.1 Request For Service The user sends a request to the AS to provide a service. That request might originate from a device that the organisation provides to users, or potentially, any device which has access to the network. The request for service consists of the user’s authorisation credential and details of the service requested. U → AS : {UCred, SerReq} G.4. THE PROPOSED SECURE CONTEXT-BASED ARCHITECTURE 311 G.4.4.2 Authorisation Request On receiving a service request, an SDO ensures that the user is entitled to make that method call before satisfying the request. (If a non-SDO receives the request, it will be satisfied without an authorisation check.) The SDO delegates the authorisation decision to the ACU, and enforces that decision. The authorisation request sent to the ACU consists of the user’s authorisation credential and the identity of method being invoked by the user. AS → ACU : {UCred, MethodName} G.4.4.3 Making The Authorisation Decision The request from the SDO is received by the Authorisation Server sub-unit of the ACU. After checking the validity of the credential, the user’s name and role together with the device ID are extracted from the authorisation credential and the right of the user to invoke the requested method on the SDO is verified. If the user does not have the necessary rights, the Authorisation Server responds to the SDO with an authorisation failure. A successful initial authorisation check results in the sending of a request to the DCSM to determine whether the location of the user and device are acceptable. It should be noted that the user’s role is used for the initial authorisation, since RBAC is being enforced, while the identity of the user is sent to the DCSM, as the user’s location is required. AuthSer → DCSM : {UID,DID, MethodName} The DCSM is responsible for enforcing the context-based portion of the authori- sation process. The aim is to ensure that user’s request to access the SDO method originated from an acceptable location. That checking involves the following steps: • Based on the SDO method being invoked, the DCSM determines the required granularity of location information required and then requests the location of the user and communicating device (to that granularity) from the Location Server. DCSM → LS : {UID,DID,Gran} • The Location Server returns the most recent location of the user and device, and the times at which those locations were determined. 312 Appendix G. APIEMS’04 Conference Paper LS → DCSM : {UserLoc, ΥUserLoc, DeviceLoc, ΥDeviceLoc} • The DCSM verifies that the user and device locations coincide and that loca- tion is consistent with the access control policy requirements. The result of the access control check, a boolean value, is returned to the Authorisation Server. DCSM → AuthSer : {BoolRes} • The Authorisation Server returns either the negative result from its original au- thorisation check or the authorisation decision from the DCSM to the SDO. ACU → AS : {BoolRes} G.4.4.4 SDO Performs The Service The authorisation decision provided by the ACU determines whether SDO will per- form the requested service. Whether successful or not, the SDO will log the event. A critical requirement of the behaviour of the SDO to an authorisation failure is that the action taken must not cause the system to enter an unsafe state. If required, the SDO returns the result of performing the service to the user. AS → User : {SerRes} G.5 AN IMPLEMENTATION SCENARIO To illustrate how the architecture might be used in practice, its applicability to the protection of effluent treatment unit of a sulphuric acid plant will be discussed. A sul- phuric acid plant was chosen because of the commercial importance of sulphuric acid and the potential for a major disaster should a successful attack be mounted against the plant. The chemical is highly corrosive and can penetrate deep into the lung cavity causing respiratory distress in humans and other animals. It is also a source of acid rain. Consequently, tough legislative requirements apply to the release of sulphuric acid into the environment. G.5. AN IMPLEMENTATION SCENARIO 313 G.5.1 Analysis Of The Infrastructure The control system in the acid plant would adhere to the architecture shown in Figure 1. In the sulphuric acid plant, the ’Remote/Local Controls’ would correspond to the monitoring and control units for effluent treatment, gas cleaning, etc. The effluent treatment control unit is in turn responsible for the correct operation of numerous devices including: sensors for monitoring pH, pressure, temperature; gate and safety valves, etc. When deciding which software objects within the control system should be self- defending, the functionality provided by all components from the ’Supervisory Con- trol and Monitoring Unit’ to individual valve control objects, needs to be subjected to a risk analysis. Such an analysis would be performed, as part of the standard analysis process, to determine what operations, users acting in particular roles, should be able to perform. When using the proposed architecture, there is an additional requirement to specify the locations from which the user may perform these operations. Software objects, which perform highly sensitive operations, and so pose a serious safety, operational or other risk if under unauthorised (and probably external) con- trol, should be made self-defending. As argued previously, making too many objects self-defending might overload and undermine the performance of the access control unit, leading to delays, which might compromise the safe and critical operation of the system. G.5.2 Four Scenarios Legitimate users of the control system, following authentication, are issued with an authorisation token which certifies their identity, current role and their communicat- ing device. When the user requests the service, say open effluent treatment control valve 1 that token forms part of the request. This valve is a wireless controlled valve, which releases effluent to the environment. Since it provides a very sensitive service, it should be protected by an SDO. The access control rules stipulate that the service is only available to effluent treatment control staff, using either a control room work- station or their company issued handheld device, which must be located within the effluent treatment precinct. The valve 1 SDO on receiving a request, uses the token to verify that the user is permitted to open the value, before the valve is opened. Details of the authorisation process are provided in Section G.4.4. 314 Appendix G. APIEMS’04 Conference Paper To demonstrate how the authorisation process used by SDOs helps to safeguard the correct operation of the plant, attempts made by three users to open valve 1 will be considered. The three individuals are: • User A is an employee who is working in the effluent treatment unit and has right to control the flow of effluent. She has been assigned registered handheld wireless device A and has been authenticated. • User B is also an employee of the plant but belongs to a different operational unit and so is not permitted to control the flow of effluent. He has been assigned registered handheld wireless device B and has been authenticated. • User C is an external entity who is not associated with the plant but is in pos- session of user A’s registered wireless device. Consider the following scenarios: Scenario 1: User A attempts to release ef- fluent into the environment User A sends an open request to the valve SDO which includes the A’s authorisation token (which includes the ID of Device A). An autho- risation request is sent to the ACU. The Authorisation Server determines that User A is permitted to open the valve, provided the request was sent from an appropriate location. The DCSM establishes that both User A and her handheld device are both in the effluent treatment precinct, returns a positive response to the Authorisation Server which in turn, returns the positive response to the valve SDO. The valve SDO, opens the valve and logs the event. Thus the normal operation of the plant is not disrupted. If however, the authorised user was performing a malicious attack, details of the action, which were recorded by the SDO will facilitate further investigation. Scenario 2: External attack by User C using a stolen registered wireless de- vice. Assume that User C has managed to breach the security on User A’s device (which was stolen while ‘off site’) and thus has obtained a valid authorisation token. He was however, unable to breach the physical security surrounding the plant. User C sends an open request to the valve SDO, which in turn, sends an authorisation re- quest to the ACU. The authorisation server will authorise the request, so the request is forwarded to the DCSM. The DCSM requests the location of the Device A and User A from the Location Server. The DCSM will almost certainly reject the request either because User A, and certainly Device A are not within the effluent treatment precinct, or because User A had reported the loss of Device A would no longer be registered. The SDO will log the event and return the failure reply to User C. Thus, despite a G.6. CONCLUSIONS 315 powerful base from which to mount the attack, an attack from outside the perimeter will not succeed. One would assume that either the attempted access to the system from outside the plant perimeter, or the use of a stolen device, would have triggered an alarm at the control centre. Scenario 3: User B launches an attack User B sends an open request to the valve. The valve SDO sends an authorisation request to the ACU. The authorisation server checks the access rights of User B, and finds he does not have the right to open the valve and so rejects the request. An authorisation failure is returned to the valve SDO which sends a rejection response to User B, and logs the failed request. Scenario 4: User B has possession of Device A and requests the service: The scenario is similar to the previous scenario except that this time User B has stolen User A’s device (on which she has already been authenticated). When User B again makes the open valve request, the authorisation process will proceed as far as the DCSM. On this occasion, the attack may or may not be successful. Provided User B and hence Device A remain within the effluent treatment precinct, User A is also there and the authorisation token is still valid (has not timed out), this attack will be successful. It was only successful because a valid authorisation token was presented and both User A and their device were within the required area. If however, any of these conditions was not met, the attack will fail. Whether successful or not, the event will be logged and the appropriate action will be taken by the SDO. G.6 CONCLUSIONS In this paper we proposed a security architecture that makes use of self defending ob- jects and a location based access control mechanism to defend critical infrastructures from internal and external attacks. The use of SDOs to protect individual components provides multilayered protection which enhances the security of critical infrastruc- tures by supplementing the existing border protection mechanisms. Since the use of wireless technologies violates the notion of inside/outside that afforded by physical security measures, location is introduced as a factor within the access control mecha- nism to restore that notion. The security proposed architecture is applicable to SCADA systems and so permits the addition of security to legacy systems. Its applicability is not restricted to chemical plant control and may be adopted widely across multiple domains and infrastructures. 316 Appendix G. APIEMS’04 Conference Paper As discussed within the paper, the use of location information facilitates the suc- cessful mitigation of attacks against the critical infrastructure by both internal employ- ees trying to gain unauthorised access and both external entities using stolen propri- etary mobile devices. It should be noted that although the underlying cryptographic protocols were not discussed in the paper, such protocols are essential to ensure that the required information exchange can be performed securely. Future research work includes: 1) implementing the proposed architecture, 2) in- vestigating the safety implications of providing access control at the device level in real-time systems, and (3) the impact of implementing secure communication proto- cols at device level within real time systems. Of particular interest is how the use of location based authorisation, might impact of the control of systems during disaster situations which has forced the evacuation of personnel for safety reasons. Bibliography [1] John W Holford, William J Caelli, and Anthony W. Rhodes. The concept of self-defending objects in the development of security aware applications. In 4th Australian Information Warfare and IT Security Conference, Adelaide, Aus- tralia, 2003. [2] John W Holford, William J Caelli, and Anthony W. Rhodes. Using self- defending objects to develop security aware applications in Java. In V Estivill- Castro, editor, 27th Australasian Computer Science Conference, volume 26 of Conferences in Research and Practice in Information Technology, pages 341– 349, Dunedin, New Zealand, January 2004. Australian Computer Society. [3] Jia Zhang. Trustworthy web services: Actions for now. IT Pro, pages 32–36, January-February 2005. [4] Matt Hines. Cost-cutting drives outsourcing growth. CNET News.com, August 2005. [Online] Available: http://news.com.com/Cost-cutting+ drives+outsourcing+growth/2100-1008 3-5844018.html [5] EBS. Offshore outsourcing basics. Accessed December 2005. [Online] Available: http://www.ebstrategy.com/outsourcing/basics/ definition.htm [6] Heather L. Warren and Amber L. Fagan. Outsourcing: Implications for home- land security. In 10th International Command and Control Research and Technology Symposium (ICCRTS), June 2005. [Online] Available: http: //www.dodccrp.org/events/2005/10th/CD/papers/069.pdf [7] Bill Gates. Bill gates: Trustworthy computing. January 15 2002. email to all Microsoft employees. [Online] Available: http://www.wired.com/ news/print/0,1294,49826,00.html 317 318 BIBLIOGRAPHY [8] Clemens. Szyperski. Component software : beyond object-oriented program- ming. ACM Press Addison-Wesley, Reading Mass, 1997, c1998. [9] NSA. Security-Enhanced Linux homepage. http://www.nsa.gov/selinux/ in- dex.html, 2005. [10] Adele. Goldberg and David. Robson. Smalltalk-80 : the language and its im- plementation. Addison-Wesley, Reading,Mass, [rev. ed.]. edition, c1983 1985. Addison-Wesley series in computer science. [11] Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley, Read- ing, MA, 1986. ISBN: 0-201-12078. [12] David Flanagan. Java in a Nutshell A Desktop Quick Reference. The Java Series. O’Reilly & Associates, Sebastopol CA, 3rd edition, 1999. [13] Mark Curphey, David Endler, William Hau, Steve Taylor, Tim Smith, Alex Russell, Gene McKenna, Richard Parke, and Kevin McLaughlin. A Guide to Building Secure Web Applications. The Open Web Application Security Project (OWASP)., 2002. [14] P. Kearney, J. Chapman, N. Edwards, M. Gifford, and L. He. An overview of web services security. BT Technology Journal, 22(1):27– 42, March 2004. [Online] Available: http://springerlink.com/ media/3AA8LU4D756XTJCC5A2W/Contributions/L/4/1/5/ L415007T5305WV96.pdf [15] Preston Gralla. Demystifying web services: How they really work. THE WEB SERVICES ADVISOR, 22 Jan 2002. [Online] Available: http://searchwebservices.techtarget.com/tip/1, 289483,sid26 gci788326,00.html [16] OASIS. UDDI home page. [Online] Available: http://www.uddi.org/ [17] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weer- awarana. Web Services Description Language (WSDL) 1.1. Technical report, W3C, http://www.w3.org/TR/wsdl, 15 March 2001. [18] Preston Gralla. An inside look at WSDL. THE WEB SERVICES ADVISOR, 26 March 2002. [Online] Available: http://searchwebservices. techtarget.com/tip/1,289483,sid26 gci811272,00.html BIBLIOGRAPHY 319 [19] Jaideep Roy and Anupama Ramanujan. Understanding web services. IT Pro, pages 69–73, November-December 2001. [20] Endtrust. Web Services Trust and XML Security Standards Version 1.0. Tech- nical report, Entrust, April 2001. [21] Luis Felipe Cabrera, Christopher Kurt, and Don Box. An introduction to the web services architecture and its specifications version 2.0. Technical report, Microsoft Corporation, October 2004. [22] IBM and Microsoft. Security in a web services world: A proposed architecture and roadmap, version 1.0. Technical report, IBM and Microsoft, April 2002. [23] Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, and Ronald Monszillo. Web Services Security: SOAP Message Security 1.0 (WS-Security 2004). Technical report, OASIS, http://www.docs.oasis-open.org/wss/2004/01/oasis- 200401-wss-soap-message-security-1.0, March 2004 2004. [24] H. Kreger. Web Services Conceptual Architecture (WSCA 1.0). Technical report, IBM, May 2001. [25] Scott Seely. Understanding WS-Security. Technical report, Microsoft Corporation, http://msdn.microsoft.com/library/default.asp?url=/library/en- us/dnwssecur/html/understw.asp, October 2002. [26] O. Sibert, D. Bernstein, and D. Van Wie. The DigiBox: a self-protecting con- tainer for information commerce. In Proceedings of the First USENIX Work- shop of Electronic Commerce, pages 171–183, New York, NY, USA, 1995. USENIX Assoc, Berkeley, CA, USA. [27] T. Pack. Digital rights management: Can the technology provide long-term solutions?;. EContent, 24(3):22–27, May 2001. [28] U. Kohl, J. Lotspiech, and M.A. Kaplan. Safeguarding digital library contents and users. D-Lib Magazine, September 1997. [29] Gregory R. Ganger and David F. Nagle. Better security via smarter devices. In IEEE Workshop on Hot Topics in Operating Systems, pages 100–105, Elmau, Germany, 2001. IEEE. [Online] Available: http://www.pdl.cmu.edu/ PDL-FTP/Secure/hotos01\ abs.html 320 BIBLIOGRAPHY [30] Gregory R. Ganger and David F. Nagle. Enabling dynamic security manage- ment of via device-embedded security. Technical Report Technical Report CMU-CS-00-174, Carnegie Mellon University, http://www.pdl.cmu.edu/PDL- FTP/Storage/CMU-CS-00-174 abs.html, December 2000. [31] John D. Strunk, Garth R. Goodson, Adam G. Pennington, Craig A.N. Soules, and Gregory R. Ganger. Intrusion detection, diagnosis, and recovery with self-securing storage. Technical Report Technical Report CMU-CS-02-140, Carnegie Mellon University, Pittsburgh, PA, May 2002. [32] M.S. Olivier. Self-protecting objects in multipolicy federated databases: A prototype. Technical report, Department of Computer Science, Rand Afrikaans University, 1996. [33] M.S. Olivier. Self-protecting objects in a secure federated database. In JE Dob- son DL Spooner, SA Demurjian, editor, Database Security IX: Status and Prospects, pages 27–42. Chapman Hall, 1996. [34] M.S. Olivier and S.H. von Solms. Building a secure database using self- protecting objects. Computers and Security, 11(3):259–271, 1992. [35] Peter A. Loscocco and et. al. The inevitability of failure: The flawed assump- tion of security in modern computing environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, October 1998. [36] HHS. Summary of HIPAA Privacy Rule, 05/03 2003. [37] Charles P. Pfleeger. Security in computing. Prentice-Hall,, Englewood Cliffs, N.J. :, 1989. ISBN: 0137990162 (International Ed). [38] P.A. Loscocco and S.D. Smalley. Meeting critical security objectives with Security-Enhanced Linux. In Proceedings of the 2001 Ottawa Linux Sympo- sium, Ottawa, 2001. NSA. [39] D.F. Ferraiolo and D.R. Kuhn. Role based access control. In Proceedings of the NIST-NSA National (USA) Computer Security Conference, pages 554–563, 1992. BIBLIOGRAPHY 321 [40] D. Ferraiolo and et. al. Sandhu, R. A proposed standard for role based access control. ACM Transactions on Information and System Security, 4(3):224–274, 2001. [41] J. Barkley, D.R. Kuhn, and etal. Role-based access control for the web. In CALS Expo International and 21st Century Commerce 1998: Global Business Solutions for the New Millennium, 1998. [42] S. Wakid, J.F. Barkley, and M. Skall. Object retrieval and access management in electronic commerce. IEEE Communications Magazine, 1999. [43] S. Smalley. Configuring the SELinux policy. Technical Report NAI Labs Re- port #02-007, NAI Labs, January 2003. [44] P. Loscocco and S. Smalley. Integrating flexible support for security policies into the Linux operating system. In FREENIX Track: 2001 USENIX Annual Technical Conference (FREENIX ’01), 2001. [Online] Available: http:// www.nsa.gov/selinux/freenix01-abs.html [45] R. Spencer and et. al. Smalley, S. The Flask Security Architecture: System support for diverse security policies. In Proceedings of The Eighth USENIX Security Symposium, pages 123–139, 1999. [46] K. Beznosov and Y. Deng. A framework for implementing role-based ac- cess control using CORBA security service. In Proceedings of the fourth ACM workshop on Role-based access control, pages 19–30, Fairfax, Virginia, United States, 1999. ACM Press New York, NY, USA. [Online] Available: http://doi.acm.org/10.1145/319171.319174 [47] K. Beznosov and et. al. A resource access decision service for CORBA- based distributed systems. In Proceedings of the 15th Annual Computer Security Applications Conference, pages 310–319. IEEE, December 1999. [Online] Available: http://www.beznosov.net/konstantin/ professional/papers/Resource\ access\ decision\ service\ for\ CORBA-based\ distributed\ systems.html [48] H. Roeckle, G. Schimpf, and R. Weidinger. Process-oriented approach for role- finding to implement role-based security administration in a large industrial organization. In Proceedings of the fifth ACM workshop on Role-based access 322 BIBLIOGRAPHY control, pages 103 – 110, Berlin, Germany, 2000. ACM Press New York, NY, USA. [49] D.F. Ferraiolo, J. Barkley, and D.R. Kuhn. A role based access control model and reference implementation within a corporate intranet. ACM Transactions on Information Systems Security, 1(2), 1999. [50] M. Lebkicher. Role based access control. volume 203. Sans, 2000. SANS Se- curity Basics Training. [Online] Available: http://www.sans.org/rr/ securitybasics/RBAC.php [51] A.B. Ruighaver. A fresh look at small-granularity role-based access control. In Proceedings of the Twelfth Australasian Conference on Information Systems, 2001. [52] L. S. Bartz. hyperdrive: leveraging ldap to implement rbac on the web. In Proceedings of the second ACM workshop on Role-based access control, pages 69–74, Fairfax, Virginia, United States, 1997. ACM Press New York, NY, USA. [53] D. Bell and L. Lapadula. Secure computer systems: Mathematical foundations and model. Technical Report MTR 2547, v2, MITRE, Nov. 1973. [54] K. Biba. Integrity considerations for secure computer systems. Technical re- port, US Air Force Electronic Systems Division, 1977. [55] D.D. Clark and Wilson D.R. A comparison of commercial and military com- puter security policies. In IEEE Symposium on Security and Privacy, pages 184–194, 1987. [56] J. Saltzer. Protection and the control of information sharing in MULTICS. Communications of the ACM, 17(7):388–402, July 1974. [57] DOD. Trusted Computing System Evaluation Criteria, December 1985. [58] CCPSC. Common Criteria origin. http://www.commoncriteria.org/docs/origins. html. [59] CCPSO. Common Criteria for Information Technology Security Evaluation (CC 2.1). Technical Report CCIMB-99-031, CCIMB-99-032, CCIMB-99-033, the Common Criteria Project Sponsoring Organisations, August 1999. BIBLIOGRAPHY 323 [60] OASIS. eXtensible Access Control Markup Language (XACML) Version 2.0. Technical report, OASIS, http://docs.oasis-open.org/xacml/access control- xacml-2 0-core-spec-cd-04.pdf., 6 Dec 2004 2004. [61] N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The Ponder Policy Spec- ification Language. In M. Sloman, J. Lobo, and E. Lupu, editors, Interna- tional Workshop on Policies for Distributed Systems and Networks (POLICY 2001), volume 1995 of Lecture Notes in Computer Science 1995, pages 18–38. Springer-Verlag London, UK, 2001. [62] K.J. Gough. Stacking them up: a comparison of virtual machines. In 6th Australasian Computer Systems Architecture Conference, 2001. (ACSAC 2001), pages 55–61, Gold Coast, Qld. Australia, Jan 2001. [63] J. Barkley. Implementing role based access control using object technology. In Charles E. Youman, Ravi S. Sandhu, and Edward J. Coyne, editors, Pro- ceedings of the First ACM Workshop on Role-Based Access Control, volume 2, pages 93–98, New York, NY, USA, November 1995. ACM Press. [64] TCG. Trusted Computing Group homepage. https://www.trustedcomputinggroup.org, August 2003. [65] TCG. Trusted Computing Group: Backgrounder. https://www.trustedcomputinggroup.org/downloads/TCG Backgrounder.pdf, May 2003. Accessed: 22/12/03. [66] TCG. TCG PC Specific Implementation Specification ver- sion 1.1. Technical report, Trusted Computing Group, https://www.trustedcomputinggroup.org/downloads /tcg spec 1 1b.zip, August 2003. [67] TCPA. Building a foundation of trust in the PC. January 2000. [On- line] Available: http://www.trustedcomputing.org/docs/TCPA first WP.pdf [68] Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert Van Doorn. Design and implementation of a TCG-based integrity measurement architecture. Tech- nical Report RC23064, IBM Research Division, Thomas J. Watson Research Centre, 16 January 2004. 324 BIBLIOGRAPHY [69] Reiner Sailer, Trent Jaeger, Xiaolan Zhang, and Leendert Van Doorn. Attestation-based policy enforcement for remote access. In 11th ACM confer- ence on Computer and communications security, pages 308 – 317, Washington DC, USA, October 2004. ACM Press. [70] Reiner Sailer, Leendert VanDoorn, and James P Ward. The role of TPM in enterprise security. Number RC23363(W0410-029), October 6 2004. [Online] Available: https://www.trustedcomputinggroup.org/ press/news articles/rc23363.pdf [71] Wayne Jansen and Tom Karygiannis. Mobile agent security. Technical Report Special Publication 800-19, National Institute of Standards and Technology, August 1999. [72] William M Farmer, Joshua D Guttman, and Vipin Swarup. Security for mobile agents: Issues and requirements. In 19th National Information Systems Security Conference, pages 591–597, Baltimore, Md., 1996. [73] A. Corradi, R. Montanari, E. Lupu, M. Sloman, and C. Stefanelli. A flexi- ble access control service for Java mobile code. In Annual Computer Security Applications Conference (ACSAC 2000), New Orleans, Louisiana, 2000. IEEE Press. [74] Grzegorz Czajkowski and Thorsten von Eicken. JRes: A resource ac- counting interface for Java. In ACM Conf. on Object-Oriented Program- ming Systems, Languages and Applications, pages 21–35, Vancouver, Canada, October 1998. ACM. [Online] Available: citeseer.ist.psu.edu/ czajkowski98jres.html [75] Alfonso Fuggetta, Gian Pietro Picco, and Giovanni Vigna. Understanding code mobility. IEEE Transactions on Software Engineering, 24(5):342–361, May 1998. http://www.cs.ucsb.edu/ vigna/listpub.html. [Online] Available: citeseer.ist.psu.edu/fuggetta98understanding.html [76] Danny B. Lange and Mitsuru Oshima. Mobile agents with Java: The Aglet API. World Wide Web, 1(3):111–121, 1998. TY - JOUR. [On- line] Available: http://www.springerlink.com/openurl.asp? genre=article&id=doi:10.1023/A:1019267832048 BIBLIOGRAPHY 325 [77] Fritz Hohl. Time limited blackbox security: Protecting mobile agents from malicious hosts. In G. Vigna, editor, Mobile Agents and Security, volume 1419 of Lecture Notes in Computer Science, pages 92–113. Springer-Verlag, January 1998. [78] Tomas Sander and Christian F. Tschudin. Protecting mobile agents against ma- licious hosts. In G. Vigna, editor, Mobile Agent Security, volume 1419 of Mo- bile Agents and Security, pages 44–60. Springer-Verlag, Heidelberg, January 1998. [79] Ramnivas Laddad. I want my AOP! Java World, 2002. [80] D. Burgett, M. Baute, and etal. .NET e-business architecture. Sams, Indianapo- lis, Indiana, c2002. [81] Bill Venners. Java’s security architecture. JavaWorld, August 1997 1997. [Online] Available: http://www.javaworld.com/javaworld/ jw-08-1997/jw-08-hood\ p.html [82] M. Howard and D. LeBlanc. Writing secure code. Microsoft Press,, Redmond, Wash., 2002. [83] M.C. Daconta, A. Saganich, and E. Monk. Java 2 and Javascript for C and C++ programmers. Wiley, New York, rev. ed. edition, c1999. [84] Frederic Painchaud. Toward more efficient, flexible and robust Java(TM) secu- rity. Master’s thesis, Universite Laval (Canada), April 2002. Digital Disserta- tions (Proquest). [85] Bill Venners. Java security: How to install the security man- ager and customize your security policy. JavaWorld, November 1997 1997. [Online] Available: http://www.javaworld.com/javaworld/ jw-11-1997/jw-11-hood\ p.html [86] Sun Microsystems Inc. Support readiness document Java Authentication and Authorization Service 1.0. Technical report, Sun Microsystems, February 2000. [87] Ramnivas Laddad. AspectJ in Action - Practical Aspect-Oriented Program- ming. Manning Publications Co., Greenwich, CT 06830, isbn 1-930110-93-6 edition, 2003. ch 10: Authentication and authorization. 326 BIBLIOGRAPHY [88] Sun Microsystems Inc. Java Authentication and Authorization Service (JAAS) 1.0 - Developers Guide. Technical report, Sun microsystems, September 2001. http://java.sun.com/security/jaas/doc/api.html. [89] Sun Microsystems Inc. JavaTM Authentication and Authorization Service (JAAS) Reference Guide. Technical report, Sun Microsystems, August 2001. http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/JAASRefGuide.html. [90] Sun Microsystems Inc. JavaTM 2 Platform, Standard Edition 5.0 API Specifi- cation, 2004. [91] Li Gong. Inside Java 2 Platform Security: Architecture, API Design and Imple- mentation. The Java Series. Addison Wesley, Reading, Massachusetts, 1999. [92] Tim Lindholm and Frank Yellin. The Java(TM) Virtual Machine Specifica- tion (Second Edition). The Java series. Addison Wesley Professional, Reading, Mass, 1999. [93] K. J. Gough and D. Corney. Translating languages other than Java for the Java Virtual Machine. Technical report, Faculty of Information Technology, QUT, http://www.fit.qut.edu.au/ gough, 1999. [94] Bill Venners. Security and the class verifier. JavaWorld, October 1997 1997. [Online] Available: http://www.javaworld.com/javaworld/ jw-10-1997/jw-10-hood\ p.html [95] Bill Venners. Inside The Java Virtual Machine (2nd Edition). McGraw-Hill, 2000. http://www.artima.com/insidejvm/ed2/. [96] William J Caelli. B is for business : Mandatory security criteria and the oecd guidelines for information systems security. In 19th National Information Sys- tems Security Conference, Baltimore, MD, USA, October 1996. reference to SDOs. [Online] Available: http://cs-www.ncsl.nist.gov/nissc/ 1996/papers/NISSC96/paper005/ncsc96.pdf [97] Ken Thompson. Reflections on trusting trust. Communication of the ACM, 28(8):761–763, August 1984. 1983-ACM Turing Award Lecture. [Online] Available: http://www.acm.org/classics/sep95/ BIBLIOGRAPHY 327 [98] D.F. Ferraiolo, J. Cugini, and D.R. Kuhn. Role based access control: Features and motivations. In Proceedings of the 11 th Annual Computer Security Appli- cations Conference. IEEE Press, 1995. [99] Sun Microsystems Inc. Trusted Solaris 8 Operating Environment. Technical white paper, Sun Microsystems, November 2000. [100] Joe Wigglesworth and Paula Lumby. Java Programming: Advanced Topics. Course Technology, Cambridge Mass, 2000. ISBN: 0-7600-1098-6. [101] Sun Microsystems Inc. RMISSLClientSocketFactory download page. [Online] Available: http://java.sun.com/j2se/1.5.0/docs/ guide/security/jsse/samples/index.html [102] Carlisle Adams and Sharon Boeyen. UDDI and WSDL extensions for Web service: a security framework. In Proceedings of the 2002 ACM workshop on XML security, pages 30–35. ACM Press, 2002. Fairfax, VA. [103] R. Atkinson, G. Della-Libera, and etal. Web Services Security (WS-Security) Version 1.0. Technical report, IBM, Microsoft, VeriSign, April 2002. [104] Eric Newcomer. Understanding Web Services. Addison-Wesley, http://searchwebservices.techtarget.com/searchWebServices/downloads/ New- comer ch07.pdf, Jan 2004. chapter 7. [105] M. O’Neill. Web Services Security. Osborne, 2003. http://searchwebservices.techtarget.com/whitepaperPage/0,293857,sid26 gci 894195,00.html. [106] RSA Security. Web services security. 2002. [Online] Available: http://www.rsasecurity.com/products/cleartrust/ whitepapers/WSS\ WP\ 0802.pdf [107] Selim Seynur. Understanding web services and web services security, 2004. http://www.infosyssecurity.com/papers/WSSecurityOverview.doc. [108] C. Vawter and E. Roman. J2EE vs. Microsoft.NET: A comparison of build- ing web services. Technical report, The Middleware Company, June 2001. http://www.theserverside.com/resources/pdf/J2EE-vs-DotNET.pdf. 328 BIBLIOGRAPHY [109] G. Mohay, W. Caelli, Gough K.J., J. Holford, and G. Low. CASS - Computer Architecture for Secure Systems. In Gopal Gupta, George Mohay, and Rod- ney Topor, editors, Proceedings of the Sixteenth Australian Computer Science Conference (ACSC-16), volume 15 No 1 of Australian Computer Science Com- munications, pages 253–263. Australian Computer Science Communications, Queensland University of Technology, February 1993. [110] H. Schmidt. Trustworthy components–compositionality and predic- tion. Journal of Systems and Software, 65(3):215–225, 2003. [Online] Available: http://www.sciencedirect.com/science/article/ B6V0N-48F5SBP-5/2/8eb87d26637d8df452279863732fc297 [111] Mitch Betts. The future of software development (grady booch interview). COMPUTERWORLD, MAY 20 2002. Interview with Grady Booch. [Online] Available: http://www.computerworld.com/softwaretopics/ software/appdev/story/0,10801,71150,00.html [112] Rob Flickenger. Wireless Hacks. O’Reilly Media, Beijing, 1st edition, Septem- ber 2003. [113] Guanling Chen and David Kotz. A survey of context-aware mobile com- puting research. Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College, ftp://ftp.cs.dartmouth.edu/TR/TR2000-381.ps.Z, Novem- ber 2000. [114] Mark Looi. Enhanced authentication services for internet systems using mo- bile networks. In Global Telecommunications Conference, GLOBECOM ’01., volume vol.6, pages 3468 – 3472, San Antonio, TX USA, 2001. IEEE. [115] C. Wullems, M. Looi, and A. Clark. Enhancing the security of internet ap- plications using location: a new model for tamper-resistant gsm location. In Eighth IEEE International Symposium on Computers and Communication, (ISCC 2003)., volume 2, pages 1251– 1258, Kemer-Antalya, Turkey, 2003. IEEE. [116] Dorothy E. Denning and Peter F. MacDoran. Location-based authentica- tion:grounding cyberspace for better security. Computer Fraud and Security, February 1996. BIBLIOGRAPHY 329 [117] John D. Strunk, Garth R. Goodson, Michael L. Scheinholtz, Craig A.N. Soules, and Gregory R. Ganger. Self-securing storage: Protecting data in compro- mised systems. In 4th Symposium on Operating Systems Design and Im- plementation, San Diego, CA., October 2000. [Online] Available: http: //www.pdl.cmu.edu/ftp/Storage/s4\ abs.html [118] Robert F. Dacey. Critical infrastructure protection: Challenges in securing con- trol systems. Testimony before the subcommittee on technology, information policy, intergovernmental relations, and the census, house committee on gov- ernment reform, United States General Accounting Office, October 2003. [119] Garry Barker. Cyber terrorism a mouse-click away. The AGE Newspaper, July 8 2002. [120] Dorothy E. Denning. Cyberterrorism. Testimony before the special oversight panel on terrorism, Committee on Armed Services, U.S. House of Representa- tives, http://www.cosc.georgetown.edu/ denning/infosec/cyberterror.html, May 2000. [121] Kevin Poulsen. Slammer worm crashed ohio nuke plant network. Security Fo- cus, 19 August 2003. [Online] Available: http://www.securityfocus. com/news/6767 [122] NAERC. SQL Slammer worm lessons learned for consideration by electri- cal society. Technical report, North American Electric Reliability Council, http://www.esisac.com/publicdocs/SQL Slammer 2003.pdf, 20 June 2003. [123] Colin Boyd and Anish Mathuria. Protocols for Authentication and Key Estab- lishment. Springer-Verlag, New York, 2003. call number: 005.82 104 ISBN: 3540431071. [124] H. Vasanta, Yiu Shing Terry Tin, Colin Boyd, Mark Looi, and Juan Manuel Gonzalez Nieto. A secure framework for user privacy in heterogeneous location networks. In Ahmed Karmouch, Larry Korba, and Edmundo R.M. Madeira, editors, Mobile Aware Technologies and Applications (MATA2004), volume 3284 of Lecture Notes in Computer Science, pages 264–274. Springer- Verlag, 2004.