Aspect-oriented Information Flow Control
Download 61.99 Kb.
|
- Navigate this page:
- Keywords
- 2. Background on Information Flow Control
- 2.1 Language-based Information Flow Controls
- 2.2 Message Filtering Algorithm
- 3. Aspect-oriented programming and its application to security
- 4. An Aspect-based approach to modeling Information Flow Control
- 5. Case Study: Testing the Applicability of the Flow Aspect
|
1Aspect-oriented Information Flow Control Department of Computer Science University of Pretoria Pretoria 0002 South Africa
padayk@unisa.ac.za eloff@cs.up.ac.za jbishop@cs.up.ac.za Abstract: An initiative towards including security in the earlier phases of the software life-cycle is gaining momentum, as it is much easier to design with security from the onset, than to use the penetrate-and-patch approach. Unfortunately, incorporating security into software development takes time and developers tend to focus more on the features of the software application. The aspect-oriented paradigm can facilitate the implementation of additional security features to legacy systems without modifying existing code. One kind of security is information flow control which primarily aims at preventing information leakage in software systems. In this paper it is proposed that aspect-oriented programming and design may be used to perform information flow analysis by augmenting an existing system with information flow control features. The paper concludes that the aspect-orientated approach may be used to detect information leakage among objects in a software system. Keywords: Information flow control, aspect-oriented programming, security 1. Introduction 1It has become evident that the means by which software is designed and implemented can have a significant impact on software security. There is often a confusion between security software and software security: the former entails a set of add-on features such as cryptography while the latter is an ‘emergent property’ of a complete system [Mcgraw 2003]. Software security involves designing, analyzing and coding for security over the whole life cycle. Developing secure software systems requires more than protecting objects from illegal manipulation: it implies preventing illegal information flow among objects in a system [Izaki et al 2001]. This paper presents an aspect-oriented approach for detecting this illegal information flow. Emergent properties of software have been studied in other fields as well, for example in high performance computing [Subotic and Bishop 2005] . Incorporating information flow control during software development is extremely challenging. Firstly, there is the problem of interfacing real applications that have information flow features with an existing infrastructure that was not designed with information flow in mind. Secondly, it is difficult to manage and assign security policies during software development Thirdly, the programmer needs to not only understand the algorithm to be implemented but also what the desired security policy is and how to formalize it [Zdancewic 2004]. This paper proposes employing the aspect-oriented paradigm to address these problems. We will show that the aspect-oriented paradigm can facilitate the insertion of additional security features into legacy systems without modifying existing code. As roles between application developers and security specialists are separated aspect-oriented programming can also simplify the management of security polices [Bodkin 2004]. This paper considers the possibility of developing an information flow security aspect to augment an existing system to address illegal information flow. Several authors have cited the benefits of using aspect-oriented programming (AOP) for implementing security concerns ([De Win et al 2002, Viega et al 2001]). According to Bodkin [2004], AOP, is relevant for all major pillars of security: ‘authentication, access control, integrity, non-repudiation, as well as for supporting the administration and monitoring disciplines required for effective security’. The primary argument supporting AOP is that the average programmer does not have the requisite skills in security [Viega et al. 2001]. Programming tasks such as authentication, access control and integrity should be abstracted away from developers and allocated to security experts. Secondly, it is observed that security concerns such as encryption and access control tend to crosscut objects. Thirdly, a security aspect can be reused for other applications since access control has the same requirements for most applications [De Win et al 2001]. Fourthly, aspect-oriented software design is flexible enough to accommodate the implementation of additional security features after the functional system has been developed. This paper investigates the possibility of using the aspect-oriented paradigm to facilitate the non-intrusive insertion of information flow control features into an existing system. We show that crosscutting concerns can be added without making invasive modifications on the original code. Sections 2 and 3 discuss the concepts of information flow control, AOP and its influence on software security. Section 4 and 5 presents a generalized aspect-oriented approach to detecting the flow of information between objects in a system and a small case-study to demonstrate its practicability. Section 6 concludes with the possibility of testing the prototype presented here on a more scalable system. 2. Background on Information Flow Control A software system that manipulates and stores sensitive information such as employee salaries, tax information or identification numbers must prevent such information from leaking out during execution [Myers 1999]. Security controls, such as firewalls, anti-virus software and access control mechanisms, are not sufficient to protect against information leakage. For instance, determining whether a communication violates confidentiality is outside the scope of a firewall mechanism. Similarly, with encryption, there is no guarantee that once data is decrypted its confidentiality will be respected [Sabelfeld and Myers 2003]. Information is exchanged among variables in procedural programs and by messages in object-oriented systems. An illegal flow arises when information is transmitted from one object to another object in violation of the information flow security policy [Samarati et al 1997]. A transfer of information does not necessarily occur every time a message is passed. An object acquires information by changing its internal state, as a result of changing the values of some of its attributes. Thus, if no such changes occur as a result of a message invocation in response to a message then no information has been transferred [Jajodia et al 1992]. For example in the statements below (Figure 1) information from object W, is being transferred to object P, via two messages namely getHoursWorked()and Get_Hours(). The former, returns a value which is passed as argument to the latter. This value is used within the context of object P, either by assigning one of its attributes to the value obtained from getHoursWorked()or by performing some operation as a result of the value obtained from getHoursWorked(). Either way information is flowing into P via W. Pay_Info P = new Pay_Info(new Double(1.99)); WorkInfo W = new WorkInfo(new Double(5)); P.Get_Hours(W.getHoursWorked());
The control of information flow was not a widely used practice compared to the control of access, as it was considered to be highly impractical until the advent of security typed languages [Sabelfeld and Myers 2003]. In a security typed language, program variables and expressions are augmented with annotations that specify policies about the use of the typed data (see Figure 2 below). This type of program analysis was pioneered by Denning and Denning [1977]. These security policies are then enforced by compile-time type checking and thus have little runtime overhead [Sabelfeld and Myers 2003]. int {public} x; boolean {secret} b; int x = 0; if (b) {
x = 1; }
Language-based information-flow techniques require annotations where the programmer must not only understand the algorithm to be implemented but must also understand the desired security policy [Zdancewic 2004]. For example, JFlow (see Figure 2 above) developed by Myers [1999] requires the programmer to be responsible for annotating data values with security labels. Further security policies may not be available during functional design, thereby resulting in inconsistencies. As the language-based information flow control method forces the programmer to consider the security issues together with the functional issues, it conflicts with the separation of concerns principle advocated to resolve security issues. The aspect-oriented paradigm enables security policies to be separated from the code thereby enabling developers to write the main application and the security experts to specify the security policies [Viega et al. 2001]. 2.2 Message Filtering Algorithm Jajodia and Kogan [1990] first proposed the message filtering algorithm for object-oriented systems where every object is assigned a unique classification. Messages between objects are intercepted by the message filter which decides upon examining the given message and classification of the sender and receiver, whether to permit the information flow or not. The message filtering model is relatively complex to implement within the traditional object-oriented paradigm. Consequently, Jajodia and Kogan [1990] only consider primitive operations such as read and write methods and provide no specification of how the message filtering algorithm might be implemented. The aspect-oriented paradigm allows a more generic implementation of the message filter aspect through the use of wildcards, instead of only considering primitive operations such read and write methods. Using wildcards eliminates the need for explicit naming [Kiczales et al 2000]. The next section elaborates on aspect-oriented terminology and relevant security applications within aspect-orientation. 3. Aspect-oriented programming and its application to security Aspect-oriented programming was developed to avoid redundancy in programs, hence it has the potential to improve the reliability, maintainability, reusability [Viega and Voas 2000] and the robustness of an application [Padayachee and Eloff 2006]. An aspect is a modular unit of a crosscutting implementation that is provided in terms of pointcuts and advices, specifying what (advice) and when (pointcut) its code is going to be executed. In the execution of a program, there will be certain well-defined points called join points where calls to aspect code would be inserted. The pointcut is used to find a set of join points where aspect code would be inserted. An advice declaration can be used to specify code that should run when the join points specified by the pointcut expression is reached. The advice code will be executed when a join point is reached, either before or after the execution proceeds. A before (or after) advice on a method execution defines code to be run before (after) the particular method is actually executed. Around advice defines code which is executed when the join point is reached and has control over whether the computation at the join point (i.e. an application method) is allowed to execute [Kiczales et al 2001]. The final application is generated by taking both the application functional code and its specific aspects. These two entities will be combined at compile time by invoking a special tool called a weaver. There has been a significant amount of work done in aspect-oriented security to warrant making the process more systematic in terms of software design and development. Aspect-oriented technology has been found to be suitable in terms of implementing some of the major pillars of security such as access control and authentication, accountability and audit, data protection and information flow controls in software systems. There is a duality between access control and information flow control as both mechanisms are concerned with the flow of information. We highlight the relevance of aspect-oriented technology in terms of both access control and informational flow control. However, information flow control is more than access control, as an illegal flow might occur even when only authorized requests are performed on an object. As such most access control models are supplemented with some form of information flow control. De Win et al.[2001] provided a practical solution to access control within the aspect-oriented paradigm by delineating three types of aspects, an Identification aspect, an Authentication aspect and an Authorization aspect. Ramachandran et al [2006] also addressed authentication and authorization within the aspect-oriented paradigm but provided a more generic approach, which has been adopted by this paper. They propose forfeiting explicit naming in favor of more generic pointcut designators. Due to the duality between information flow and access control the model developed here does share some parallels with algorithms provided by Ramachandran et al.[2006]. However they do not address information flow. Masuhara and Kawauchi [2003] commented on the difficulty of determining the source of information flow within aspect-orientation. They found that although sanitizing was a crosscutting concern, there was no possible way to define a pointcut that would be able to detect whether a string was from an unauthorized source or not, or contained unwanted information. Hence they proposed a new pointcut called dflow that addresses the data flow between join points as an extension to the AspectJ language, but they do not comment on the propagation of information among objects in a system. The model proposed below shows how aspect-orientation may be used to determine information flows between objects in a system to facilitate information flow analysis. 4. An Aspect-based approach to modeling Information Flow Control Identifying illegal flows between objects would require an aspect based on the principle of the message filtering algorithm developed by Jajodia and Kogan [1990]. Here pointcuts would be utilized to identify flows between objects. Such an aspect will observe objects, and intercept messages flowing between them. For instance, the aspect’s advice could decide
Figure 3 illustrates sender object (A) sending information to receiver object (B). The flow is intercepted and tested if it violates the specified information flow policy. If the flow does not disobey the specified information flow policy then the aspect allows the flow to proceed to receiver object (B). Otherwise the aspect does not allow the flow to occur or perhaps issues a warning indicting that there is a possible problem.  Figure. 3. Aspect Flow Intercepts Information Flow between Objects. The Flow aspect considered those actions that resulted in an attribute being assigned (set) or returned from an object. Note the set and get are constructs of AspectJ specifically and do not indicate the method names of the object. For instance, get will identify any method that returns an attribute, irrespective of whether it is actually named 'get'. This notion actually addresses all interactions between objects including those that occur when objects are being instantiated. When an attribute is returned from a message, the reference of this attribute is stored in an appropriate container. When an attribute in an object is being assigned to a particular value, this container is inspected to check if the value was obtained from another object. If this value was obtained from another object then an appropriate action may be taken if the information flowing should not be permitted according to the information flow policy (see Figure 4 below).
pointcut getMethods(): get(* *.*); before( )returning(Object x): getMethods() && (within (A || B || C //...and other objects being tracked )){ //Information flowing out of this object //Store information about this joinpoint //such as the reference of this object. } pointcut setMethods(Object x): ((set (* *.*) || call (* *(..))) && args(x) && within( A || B || C //...and other objects being tracked )); before(Object x): setMethods(x) { //if there is an illegal flow between the sender //and receiver objects // Respond appropriately //else
// Allow Process to proceed as normal } } Figure. 4. A generalised Aspect to intercept the flow between objects With respect to the aspect-oriented flow model described above, a small system was built to test the applicability of the generalized Flow Aspect. 5. Case Study: Testing the Applicability of the Flow Aspect The system was built using AspectJ (ajdt_1.2_for_eclipse_3.0) as an extension to Java (J2SDK1.4.2_05), and the Eclipse 3.0 IDE. Firstly a system containing three classes namely WorkInfo, Employee and Pay_Info was built, integrated and tested as a fully functional Java application by a single programmer. For clarity, we refer to this system as SystemX. As we wanted to demonstrate that information flow could be considered after a system was built, SystemX did not reflect any notion of information flow. The next step involved determining the specification of the final system with regard to the system’s response to information flow leaks. The simplest strategy was adopted, where warnings were issued as information leaks were detected within SystemX. The subsequent process involved ascertaining the information flow policy, where each class was given a specific classification either classified as ‘secret’ or ‘unclassified’. For example consider the code below taken from SystemX (Figure 5), where Pay_Info was classified as secret, and WorkInfo and Employee objects were classified as ‘unclassified’, then Line 5 should be acceptable information flow while Line 7 would result in an information leak and a warning issued. 11 Employee Micky = new Employee ("MStevens","1234","7,23rd Street Menlo Park"); 2 Pay_Info P = new Pay_Info(new Double(1.99)); 3 WorkInfo W = new WorkInfo(new Double(5)); 4 //this should be allowed 5 P.Get_Hours(W.getHoursWorked()); 6 //this should not be allowed and a warning issued 7 Micky.pay(P.getPay()) Figure. 5. Demonstrating Information Flow between objects The next consideration involved determining the implementation of the security classifications given to each class. To maintain the notion that information flow control features could be added non-invasively to an existing system, the classifications had to be considered as a separate aspectual unit. This involved creating a special type of an aspect known as an intertype declaration. The classification system was implemented by adding an extra data member to each class, named “tag”, where “tag” was a value denoting the class as 1 (secret) or 0 (unclassified) (See Figure 6 below) using intertype declarations. The intertype declaration construct is supported by aspect-oriented programming languages such as AspectJ and Hyper/J. An intertype declaration is generally used to add on information such as methods or fields to an object without modifying the existing class. A design liberty was taken, in that the data members were made public - it is possible to make these data members private and create accessors to them within the intertype declaration. The data members were made static as the classifications were considered to be common to the class. 1public aspect Classifications { public static int Employee.tag = 0; //unclassified public static int Pay_Info.tag = 1; //secret public static int WorkInfo.tag = 0; //unclassified public static int FindTag(String s){ //return classification of object } }
The Flow aspect below (Figure 7) was derived from the generalised Flow aspect presented in Section 4. The classes that were being tracked for information leakages were named within this aspect, namely Employee, Pay_Info and WorkInfo. A special reference variable called thisJoinPoint (which contains reflective information about the current joinpoint) and Vector containers were used to gather and store the information about the originating object respectively. The Vector containers were made static as only one copy of this data member should exist as it is common to the whole aspect. The Flow aspect and Classifications Aspect was then weaved together with SystemX. public aspect Flow { private static Vector References = new Vector(); private static Vector JoinPoint_String = new Vector(); private static Vector Tag = new Vector(); private static int Count = 0; pointcut getMethods(): get(* *.*); before( )returning(Object x): getMethods() && (within (Employee||Pay_Info||WorkInfo)){ //Store info about this joinpoint, //the reference & classification String Signature = thisJoinPoint.getThis().toString(); JoinPoint_String.add(Count,thisJoinPoint.toString()); References.add(Count,x); Tag.add(Count, new Integer(Classifications.FindTag(Signature))); Count++;
} pointcut setMethods(Object x): ((set (* *.*) || call (* *(..))) && args(x) && within(Employee||Pay_Info||WorkInfo)); before(Object x): setMethods(x) { String Signature = thisJoinPoint.getTarget().toString(); for(int i = 0; i < Count; i++){ if (References.get(i)== x){ { int tag = ((Integer) Tag.get(i)).intValue(); int e = Classifications.FindTag(Signature); if (e < tag){ //Issue Warning } } } } } }} Figure. 7. Showing an Aspect to intercept information flowing between objects Several insights were gathered from this experiment. Evidently, it is possible to add on information flow to a system without modifying the existing system. It is alsopossible to omit the Classifications aspect and the Flow aspect, thereby allowing SystemX to be a fully functional Java application, without information flow controls. There were limitations to this experiment though. Firstly, only explicit information flows are considered. Secondly, the classification system was based on classes rather than objects, as specified by Jajodia et al[1992]. However, it is possible to modify the Classifications aspect to classify objects based on specific information, thus extending the classification system to objects. It is probable that information flow control slows down program execution, as it involves including additional code to the functional system. However aspect-oriented programming can alleviate this problem. Information flow control can be “weaved” in and the program checked for leakages and then omitted from the final application. 6. Conclusion Despite its appeal, information flow mechanisms have not yet been successfully applied in practice. They are difficult to apply and manage in practice and they require programmers to be security experts. The aspect-oriented paradigm can be used to add security to legacy systems and due to the separation of roles between application and security developers, and it can make the management of security polices easier. In this paper, an information flow control model for existing systems using the aspect-oriented paradigm is posited. Aspects offer several benefits in terms of compact code and increased confidence but there could be drawbacks as it is a new technology. Future research will involve a case-study approach with multiple programmers, where a larger object-oriented system will be woven with the information flow features and re-compiled under the aspect-oriented paradigm. This study will also exploit and comment on aspect-oriented features such as inter-type declarations and wildcards, and as such will provide valuable insight into the benefits of using aspect-orientation. We have shown that it is possible to add on. an albeit limited, information flow without adapting the existing. The model presented here is certainly useful for tracing purposes during software testing and it may also be used to track the propagation of software bugs as they ‘flow’ from one object to another. References BODKIN, R. 2004. Enterprise Security Aspects. In AOSD'04 International Conference on Aspect-Oriented Software Development Lancaster, UK, 22-26 March 2004, 1-12. DE WIN, B., VANHAUTE, B. AND DE DECKER, B. 2002.How aspect-oriented programming can help to build secure software. Informatica, 26(2), 141-149. DE WIN, B., VANHAUTE, B. AND DECKER, B. 2001. Security Through Aspect-Oriented Programming. In Advances in Network and Distributed Systems Security, IFIP TC11 WG11.4 First Working Conference on Network Security, Leuven, Belgium, November 2001, DECKER, B. D., PIESSENS, F., SMITS, J.ANDHERREWEGHEN, E. V. (Eds.), Kluwer Academic Publishers, Boston, 125-138. DENNING, D. E. AND DENNING, P. J. 1977.Certification of Programs for Secure Information Flow. Communications of the ACM, 20(7), 504 -513. IZAKI, K., ANAKA, K. AND TAKIZAWA, M. 2001. Information Flow Control in Role-Based Model for Distributed Objects. In Eighth International Conference on Parallel and Distributed Systems Kyongju City, Korea, 26-29 June 2001, 363-370. JAJODIA, S. AND KOGAN, B. 1990. Integrating an Object-Oriented Data Model with Multilevel Security. In 1990 IEEE Symposium on Security and Privacy Oakland, California, 7-9 May 1990, 76-85. JAJODIA, S., KOGAN, B. AND SANDHU, R.1992.A multilevel-secure object-oriented data model. Technical Report. George Mason University. KICZALES, G., HILSDALE, E., HUGUNIN, J., KERSTEN, M. AND PALM, J. 2001.Getting Started with AspectJ. Communications of the ACM, 44(10), 59-65. KICZALES, G., HUGUNIN, J., KERSTEN, M., LAMPING, J., LOPES, C. AND W.G., G. 2000. Semantics-Based Crosscutting in AspectJ. In Workshop on Multi-Dimensional Separation of Concerns inSoftware Engineering (ICSE 2000), 1-6. MASUHARA, H. AND KAWAUCHI, K. 2003. Dataflow Pointcut in Aspect-Oriented Programming. In Proceedings of The First Asian Symposium on Programming Languages and Systems (APLAS'03) Beijing, China, 27-29 November, OHORI, A. (Ed.), LNCS2895, 105-121. MCGRAW, G. 2003.From the Ground Up: The DIMACS Software Security Workshop. IEEE Security and Privacy, 1(2), 59-66. MYERS, A. C. 1999. JFlow: Practical Mostly-Static Information Flow Control. In Proceedings of the 26th ACM Symposium on Principles of Programming Languages(POPL ‘99) San Antonio,Texas, USA, 20-22 January 1999, 228-241. PADAYACHEE, K. AND ELOFF, J. H. P. 2006. The Next Challenge: Aspect-Oriented Programming. In Proceedings of the Sixth IASTED International Conference on Modelling, Simulation and Optimization Gaborone, Botswana, 11-13 September 2006, NYONGESA, H. (Ed.), ACTA Press, 304-307. RAMACHANDRAN, R., PEARCE, D. J. AND WELCH, I. 2006. AspectJ for Multilevel Security. In The 5th AOSD Workshop on Aspects, Components, and Patterns for Infrastructure Software (ACP4IS) Bonn, Germany, 2006, 21 March 2006, 1-5. SABELFELD, A. AND MYERS, A. C. 2003. Language-Based Information-Flow Security. IEEE Journal on Selected Areas in Communications, 21(1), 5-9. SAMARATI, P., BERTINO, E., CIAMPICHETTI, A. AND JAJODIA, S. 1997.Information Flow Control in Object-Oriented Systems. IEEE Transactions on Knowledge and Data Engineering, 9(4), 624-538. SUBOTIC, S. AND BISHOP, J. 2005. Emergent Behaviour of Aspects in High Performance and Distributed Computing. In Proc. SAICSIT White River, South Africa, September 2005, 11-19. VIEGA, J., BLOCH, J. T. AND CHANDRA, P. 2001.Applying Aspect-Oriented Programming to Security. Cutter IT Journal, 14(2), 31-39. VIEGA, J. AND VOAS, J. 2000.Can Aspect-Oriented Programming Lead to More Reliable Software. IEEE Software, 17(6), 19 -21. ZDANCEWIC, S. 2004. Challenges in Information-flow Security. In The First International Workshop on Programming Language Interference and Dependence (PLID) Verona, Italy, 25 Aug. 2004, 1-5. Directory: papers papers -> From Warfighters to Crimefighters: The Origins of Domestic Police Militarization papers -> The Tragedy of Overfishing and Possible Solutions Stephanie Bellotti papers -> Prospects for Basic Income in Developing Countries: a comparative Analysis of Welfare Regimes in the South papers -> Weather regime transitions and the interannual variability of the North Atlantic Oscillation. Part I: a likely connection papers -> Fast Truncated Multiplication for Cryptographic Applications papers -> Reflections on the Industrial Revolution in Britain: William Blake and J. M. W. Turner papers -> This is the first tpb on this product papers -> Basic aspects of hurricanes for technology faculty in the United States papers -> Title Software based Remote Attestation: measuring integrity of user applications and kernels Authors Download 61.99 Kb. Share with your friends:
|