Aspect-oriented Information Flow Control
Department of Computer Science
University of Pretoria
Pretoria 0002
South Africa
Keshnee Padayachee
padayk@unisa.ac.za
J.H.P Eloff
eloff@cs.up.ac.za
Judith Bishop
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 aspectorientated approach may be used to detect information leakage among objects in a software system.
Keywords: Information flow control, aspect-oriented programming, security
1. Introduction
It 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,
1
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 nonintrusive 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());
Figure. 1: Demonstrating Information Flow between objects
2
Keshnee Padayachee
Two basic types of information flow controls have been identified within the object-oriented
perspective, namely language-based information flow controls [Sabelfeld and Myers 2003] and
information flow controls based on message filtering [Jajodia and Kogan 1990, Samarati et al.
1997].
2.1 Language-based Information Flow Controls
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;
}
Figure. 2. Implicit Flow Example [Myers 1999]
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].
3
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 aspectorientation may be used to determine information flows between objects in a system to facilitate
information flow analysis.
4
Keshnee Padayachee
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
 to examine the given message and classification of the sender and receiver, or
 to permit the information flow or not.

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.
ASPECT FLOW
<<POINTCUT>>
<<POINTCUT>>
Intercept: Accessor Methods
Advice: Keep track of information flowing out
of objects
Intercept: Mutator Methods
Advice: Ensure information flowing into an
object is legal before allowing the flow to
proceed otherwise respond appropriately
crosscut
A
crosscut
crosscut
crosscut
B
C
INFORMATION FLOWING BETWEEN INTERACTING
OBJECTS IN A SYSTEM
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.
5
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).
public aspect Flow {
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.
6
Keshnee Padayachee
1 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.
public 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
}
}
Figure. 6. Intertype Declarations used supplement classes in the system with classifications
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)){
7
//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,
8
Keshnee Padayachee
where a larger object-oriented system will be woven with the information flow features and recompiled 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.
9
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.
10
Keshnee Padayachee