Modularizing Crosscutting Concerns in Software Nalin Saigal

/128 Publications [1] Nalin Saigal and Jay Ligatti. Modularizing crosscutting, overlapping concerns with IVCon. Journal of Computer Science and Technology. In submission. [2] Joshua Finnis, Nalin Saigal, Adriana Iamnitchi, and Jay Ligatti. A location-based policy- specification language for mobile devices. Pervasive and Mobile Computing Journal. In press. [3] Nalin Saigal and Jay Ligatti. Inline visualization of concerns. In Proceedings of the International Conference on Software Engineering Research, Management, and Applications, [4] Jay Ligatti, Billy Rickey, and Nalin Saigal. LoPSiL: A location-based policy-specification language. In International ICST Conference on Security and Privacy in Mobile Information and Communication Systems (MobiSec), June Jay Ligatti Adriana Iamnitchi Joshua Finnis Joint work with

/128 Software Development Lifecycle Design ◦ Create a structure for the software Implement ◦ Write code for the software Test ◦ Ensure it works correctly 3

/128 Software Development Lifecycle Design ◦ Create a structure for the software ◦ Organize software’s functionality into various modules ◦ Final software is modularized. 4

/128 Code Modularization The practice of organizing code into modules Helps separate different functionalities of software from one another 5

/128 More Specifically… All the code implementing one functionality, which otherwise might be scattered, gets organized into the same module, e.g., function, class, package, or aspect The programmer can deal with all invariants of one functionality in one place This makes code easier to write, locate, understand, and maintain GUI Security Authentication Networking Modularize 6

/128 Stack Example int stack[MAX_SIZE]; int size = 0;... //Pushing a onto stack stack[size] = a; size++; //Pushing b onto stack stack[size] = b; size++; //Popping b size--; int a1 = stack[size]; //Popping a size--; int a2 = stack[size];... We can modularize the operations being performed here by defining a class called stack. 7

/128 Stack Example class stack { int a[MAX_SIZE]; int size = 0; void push(int data) { stack[size] = data; size++; } int pop() { size--; return stack[size]; } }my_stack;... my_stack.push(a); my_stack.push(b); int a1 = my_stack.pop(); int a2 = my_stack.pop();... An application developer does not need to know how the stack is implemented We can make changes to the stack implementation without even letting the application developer know Modularized stack implementation Application developer’s code 8

/128 Stack Example class stack { int a[MAX_SIZE]; int size = 0; void push(int data) { if (size == MAX_SIZE–1) printErr(“Overflow”); stack[size] = data; size++; } int pop() { if (size == 0) printErr(“Underflow”); size--; return stack[size]; } }my_stack;... my_stack.push(a); my_stack.push(b); int a1 = my_stack.pop(); int a2 = my_stack.pop();... Observe that code written by the application developer doesn’t change 9

/128 Problem Conventionally, software engineers try to separate code segments that are orthogonal in their functionality into distinct modules In practice, this doesn’t happen Example ◦ This code implements login, security, GUI, and authentication concerns: JOptionPane.showMessageDialog(null,“Login Attempt Failed.”,“Error”,JOptionPane.ERROR_MESSAGE); Which module out of login, security, GUI, and authentication should this code be present in? Peri Tarr et al. call this problem the “tyranny of dominant decomposition” 10

/128 Crosscutting Concerns Previous problem: one code segment may implement many concerns Converse problem: one concern may be implemented by many code segments (i.e., the concern is scattered) If the code implementing C is scattered throughout code implementing other concerns, we say that C crosscuts through other functional concerns 11

/128 Example String passWord =(String)JOptionPane.showInputDialog(...); boolean allow = this.authenticate(passWord); File file = new File(“output.log”); if (allow) { file.write(“Access granted.”); file.close(); } else { file.write(“Access Denied”); file.close(); return; } The security concern crosscuts the rest of the code Therefore, the security concern is called a CrossCutting Concern (CCC). 12

/128 Example A security engineer would have to go through the whole program to locate code that implements security However, if code is isolated, the security engineer only needs to locate the security module Security 13

/128 Refactoring Restructuring code to improve readability, without changing its functionality ◦ An iterative process Martin Fowler mentions 72 refactoring techniques in his book * For example: ◦ Extract into Method ◦ Extract into Class 14 * Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999

/128 Extract into Method(Example) void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } Refactor 15

/128 Extract into Method(Example) void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } Refactor 16 void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); }

/128 Extract into Method(Example) void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; printDetails(); } void printDetails() { System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); } Refactor 17 void withdrawAndDisplay(float amt) { this.balance = this.balance - amt; System.out.println("Name: " + this.name); System.out.println("Balance: " + this.balance); }

/128 However… Ultimately leads to relocation of code So, if changes need to be made to withdrawAndDisplay ’s functionality, we would have to locate printDetails also and then edit it ◦ Unless withdrawAndDisplay ’s functionality was completely unrelated to that of printDetails i.e., they were functionally orthogonal ◦ But it’s not Ultimately adds to the code-scattering problem discussed earlier 18

/128 Affects Code Maintenance Traditional modularization constructs and code refactoring hinder code maintenance We observed this while working on a case study with JHotDraw (framework for developing graphical editors) ◦ Recursively refactored/modularized code ◦ Implemented in ~ 33,000 LoC ◦ To add one feature to JHotDraw, we had to make changes in 5 files 19

/128 Reason The problem stems from these two properties of code: 1.A particular functionality is implemented by multiple code segments 2.A particular code segment implements multiple functionalities Thus, there exist many-to-many relationships between code and concerns Traditional modularization constructs and refactoring techniques only allow users to encapsulate the 1 st property 20

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 21

/128 IVCon (Inline Visualization of Concerns) GUI-based tool to modularize CCCs in the presence of multi-concern code Users can switch back and forth between two equivalent views of their code: ◦ Woven view ◦ Unwoven view Users can also edit code in both these views 22

/ Woven view: Displays program code in colors that indicate which concerns various code segments implement 23

/ Unwoven view: Displays code in two panels, one showing the core of the program, and the other showing all the modularized concerns (each displayed in isolation) 24

/128 IVCon Feature: Relationships between Concerns and Code Users can assign scattered code to the same concern The same code can be assigned to multiple concerns IVCon allows users to define many-to-many relationships between concerns and code 25

/128 Another IVCon Feature: Concern- assignment Granularity IVCon enforces token-level granularity in concern assignments Code assigned to a concern must begin and end at the beginning and ending of language-level tokens accessLog.append("About to read from file “ + this.toString()); 26

/128 Motivation for Token-level Granularity Finer granularity levels are inappropriate because tokens are the core semantic units of programming languages ◦ It won’t make sense to start concerns from the middle of a token Coarser granularity in concern assignment would reduce precision in concern assignments 27

/128 Related Work IVCon relates most closely to Aspect- oriented programming (AOP) and aspect- visualization tools AOP strives to ease the specification and manipulation of CCCs in software AOPLs use aspects to do so AspectAdvice Code that implements CCCs Joinpoints Locations in program where the advice should be executed 28

/128 Related Work: AOPLs Typical Aspect-oriented program: Aspects Core program Programmer’s viewView during execution AOPL Compiler IVCon’s unwoven view corresponds to a programmer’s view of an aspect-oriented program IVCon’s woven view corresponds to the runtime view of the aspect-oriented program 29

/128 Related Work: Concern Visualization Tools Unlike existing tools, IVCon does all of the following: ◦ Provides dual views (woven and unwoven) of user code ◦ Enforces token-level granularity in concern assignments ◦ Enables users to modify identical concern-code in one place ◦ Isolates concerns into modules ◦ Enables users to define many-to-many relationships between concerns and code ◦ Provides a GUI 30

/128 Comparison of IVCon with Related Work 31

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 32

/128 Policy-specification Languages Policy-specification languages are domain- specific programming languages designed to make it easier to specify and enforce sound security policies policy allowOnlyHTTP(Socket s) { if (s.getPort() == 80 || s.getPort() == 443) then ALLOW else DISALLOW } 33

/128 Policy-specification Languages Useful for modularizing security implementations Security is a functionally orthogonal concern ◦ Thus, security implementations could be effectively modularized using traditional modularization techniques To examine this claim further, we have designed and implemented a policy- specification language for mobile devices ◦ Based off traditional modularization constructs (aspects) 34

/128 Motivation Increased computation power of phones ◦ Users need to treat and secure their phones like computers ◦ However, this doesn’t happen Makes it easier for a motivated malicious user to gain access to a phone and private information on that phone 35

/128 Motivation (contd…) Open mobile platforms (iPhone, Android, etc.) allow any programmer to write software for phones Most programmers might not test their software to ensure minimal security holes Thus, even when a software developer’s intent may be good, it does not necessarily translate into secure software. 36

/128 LoPSiL: A Location-based Policy-specification Language LoPSiL is a location-based policy- specification language As far as we are aware, LoPSiL is the first expressive (Turing-complete) policy- specification language that targets location- based policies ◦ LoPSiL’s novelty is that it provides abstractions for conveniently accessing and manipulating location information in policies Location constructs make LoPSiL ideal for mobile devices 37

/128 Related Work Many expressive policy-specification languages and systems have been implemented Implemented as compilers that convert untrusted into trusted applications Policy Untrusted Application Program Compiler Trusted Application Program The trusted application program is equivalent to the untrusted program except that it contains inlined code that enforces the policy at runtime 38

/128 Several languages and systems employ this architecture ◦ E.g., Naccio, PoET/PSLang, Polymer ◦ But it can be inconvenient to specify mobile-device policies in these languages because they lack primitives for managing location information On the other hand, some policy-specification languages do provide primitives for managing location information ◦ E.g., OpenAmbient, Geo-RBAC ◦ But these languages are Turing-incomplete and limited to access-control policies Related Work 39

/128 Comparison of LoPSiL with Related Work Language Provides Location Constructs Turing Complete Allows flexible manipulation of location information Provides policy composition PonderNoYesNo XACMLNo PoET/PSLangNoYesNo NaccioNoYesNo PolymerNoYesNoYes DeedsNoYesNo SpatialPYes No OpenAmbientYesNoYesNo Geo-RBACYesNoYesNo AndroidYesNoYesNo LoPSiLYes No 40

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 41

/128 Woven View Woven-body panel is where users write and view their complete code. 42

/128 Woven View Concern-legend panel lists all the concerns defined by the user 43

/128 Woven View Concerns-at-current-position panel displays the concerns implemented by the code at the current cursor position. 44

/128 Woven View Users explicitly assign code to concerns Each time users assigns code to a concern, they define a region Code gets displayed in color of the concern it implements If code implements multiple concerns, it’s displayed in white text over a multi-concern background Users can edit code, including concern code, without restrictions 45

/128 Other Operations in IVCon’s Woven View Edit concerns (name and/or color) De-assign concerns from code. Remove concerns Rename code regions Change multi-concern background 46

/128 Unwoven View The concern-legend panel and the concerns-at-current- position panel remain the same as in the woven view The woven-body panel gets divides into two panels: the unwoven-body panel, and the unwoven-concerns panel 47

/128 Unwoven-body panel displays the core of the user’s program i.e., code that has not been assigned to any concerns Unwoven View 48

/128 Replaces code assigned to concerns with holes ( □) of the appropriate color. Unwoven View 49

/128 Unwoven-concerns panel shows each concern in an isolated module Unwoven View 50

/128 Concern Modules Concern modules display various code segments that implement a concern along with the names of the regions where they appear 51

/128 Concern Modules Concern modules can also contain constructs called Flags, which are used to indicate overlap between concerns 52

/128 Centralized Code Updates Syntactically equal code assigned to the same concern gets displayed only once in the unwoven-concerns panel Enables users to modify syntactically equal code segments centrally 53

/128 Centralized Code Updates - Example if (buffer.getSize() > 512) buffer.truncate(512); if (getTimeElapsed() > 2000) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE); if (buffer.getSize() > □) buffer.truncate(□); if (getTimeElapsed() > □) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE); concern constant { max_buffer_size_1 § 512 § timeout_ms_0 § 2000 § } Unweave 54

/128 if (buffer.getSize() > 1024) buffer.truncate(1024); if (getTimeElapsed() > 2000) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE); if (buffer.getSize() > □) buffer.truncate(□); if (getTimeElapsed() > □) JOptionPane.showMessageDialog(frame, "Request timed out","Error", JOptionPane.ERROR_MESSAGE); concern constant { max_buffer_size_1 § 1024 § timeout_ms_0 § 2000 § } Weave Centralized Code Updates - Example 55

/128 Display of Multi-concern Code: Woven view Displayed in white text over multi- concern background Concern information is present in concerns-at-current-position panel Users can move mouse pointer over the code to see those concerns in a tool-tip 56

/128 Display of Multi-concern Code: Unwoven view Unwoven-body panel uses white holes( □ ) over the multi-concern background Unwoven-concerns panel uses Flags ◦ Appear when there is overlap between two concerns ◦ Two types of flags: Green Flags and Red Flags ◦ Green flags indicate the beginning of nested concerns ◦ Red flags indicate the end of nested concerns 57

/128 Flags – An Example We assign all this code to the security concern 58

/128 Flags – An Example We assign the two accessLog.append(..) statements to the audit concern 59

/128 Flags – An Example 60

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 61

/128 Data Structures IVCon stores information about concern assignments in three key data structures: ◦ regionMap ◦ concernMap ◦ regionTree 62

/128 regionMap (HashTable) Unique Region Indentifier User-visible name Beginning and ending positions of the region List of concerns to which region has been assigned 63

/128 concernMap (HashTable) Unique Concern Name Concern’s display color List of regions assigned to that concern 64

/128 regionTree (R-tree) R-trees dynamically store data about potentially overlapping regions in space. Upon querying about a region r, an R-tree can efficiently return the set of stored regions that overlap r. We use R-trees to determine the regions that overlap the current cursor position. From those regions, regionMap tells us the concerns assigned to the current cursor position. 65

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 66

/128 Language Overview Due to the popularity of Java (particularly Java ME) as an application programming language for mobile devices, we’ll talk about (and we’ve implemented) LoPSiL in the context of Java However, LoPSiL is based on six core abstractions (each implemented as a Java class) that we expect to be portable to other languages and platforms 67

/128 Core Linguistic Construct 1 Location ◦ May refer to a room, chair, floor, building, campus, GPS coordinates, region of a network topology, etc.  Definition of locations is not “baked in”  Users can define their own (possibly abstract) locations by extending the Location class Location s have an identity (e.g., name or GPS coordinates) LoPSiL provides many built-in utility methods for manipulating GPS locations (e.g., calculate distance between two locations) ◦ Users are free to define others 68

/128 Core Linguistic Construct 2 LocationDevice Is LoPSiL’s interface to real-time location information LocationDevice s must implement two methods: 1.To return the device’s current location 2.To return the device’s location granularity: with what precision/accuracy the current location is known (e.g., within 0.5m, 2km, 1 room etc.) Policies can require devices to provide location information with particular granularity thresholds 69

/128 Core Linguistic Construct 3 PolicyAssumptions ◦ Encapsulates two assumptions made by policies about a LocationDevice :  LocationGranularityAssumption : Policy may require location information with a particular accuracy  FrequencyOfUpdatesAssumption : Policy may require that location updates arrive with a particular frequency A LoPSiL policy gets notified automatically whenever a LocationDevice violates that policy’s granularity or frequency-of- updates assumptions 70

/128 Core Linguistic Construct 4 Action ◦ Encapsulates information (method signature, run-time arguments, calling object, return value, etc.) about a security-relevant method An Action object gets passed to a policy before and after every security-relevant method executes The policy can analyze an Action object passed to it to determine which security-relevant method is being invoked or has just been invoked Policies get to decide whether and how the Action s passed to it will execute 71

/128 Core Linguistic Construct 5 Reaction ◦ Conveys a policy’s decision about whether and how an action is allowed to execute Policies can react to a given Action a by returning one of four Reaction s 1.OK : a is safe to execute 2.Exception : a is unsafe; exception should be raised 3.Replace : a is unsafe; a precomputed return value should be returned instead of executing a 4.Halt : a is unsafe; program should be halted 72

/128 Core Linguistic Construct 6 Policy ◦ Specifies constraints on untrusted software Five parts to a LoPSiL Policy 1.PolicyAssumptions 2.void handleGranularityViolation() 3.void handleFrequencyViolation() 4.void onLocationUpdate()  Invoked when any LocationDevice associated with the policy updates its Location information 5.Reaction react(Action a)  Return a reaction to any security-relevant action 73

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 74

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 75

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 76

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 77

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 78

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 79

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 80

/128 Example Policy: AllowAll public class AllowAll extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public LocationGranularityAssumption lga = new LocationGranularityAssumption(15, Units.METERS); public FrequencyOfUpdatesAssumption foua = new FrequencyOfUpdatesAssumption(10, Units.SECONDS); public PolicyAssumptions pa = new PolicyAssumptions(this, devices, lga, foua); public void handleGranularityViolation(){System.exit(1);} public void handleFrequencyViolation(){System.exit(1);} public synchronized void onLocationUpdate() { System.out.println("new location = " + devices[0].getLocation()); } public synchronized Reaction react(Action a) { return new Reaction("ok"); } } 81

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 82

/128 Compiler Architecture A LoPSiL compiler needs to input a policy, a list of security- relevant methods, and an untrusted application A LoPSiL compiler needs to output a trusted application formed by inserting (inlining) policy code before and after every security-relevant method in the untrusted application List of security-relevant methods LoPSiL Policy LoPSiL Compiler Trusted Application Untrusted Application 83

/128 We use AspectJ as a convenient tool for inlining policy code into the untrusted application LoPSiL inherits AspectJ’s limitation that it can only inline code into application files (and not standard Java libraries) ◦ So, LoPSiL monitors can’t make decisions about the execution of security-relevant methods invoked by (non-application) library classes Compiler Architecture 84

/128 User specifies desired policy in a.lopsil file User creates a listing of security-relevant methods in.srm file LoPSiL policy (.lopsil) Security-relevant methods (.srm) Compiler Architecture 85

/128 LoPSiL Compiler LoPSiL policy (.lopsil) Security-relevant methods (.srm) lopsil2aj converter User inputs the.lopsil and the.srm file into a lopsil2aj converter, because it converts LoPSiL files into files that can be input into an AspectJ compiler Compiler Architecture 86

/128 LoPSiL Compiler AspectJ pointcut definition for security-relevant methods (.aj) Policy-enforcement code (.java) The compiler converts the.lopsil file to Java version (. java ) of the policy by inserting three lines of code to import LoPSiL-library classes The compiler converts the.srm file to an AspectJ-code file (. aj ) that has definitions indicating 1. which policy code is to be executed and 2. when should that policy code be executed LoPSiL policy (.lopsil) Security-relevant methods (.srm) lopsil2aj converter Compiler Architecture 87

/128 LoPSiL Compiler AspectJ pointcut definition for security-relevant methods (.aj) Policy-enforcement code (.java) Untrusted application (.class) AspectJ compiler The compiler inputs the. java file, the. aj file, and the untrusted application (. class ) into a standard AspectJ compiler LoPSiL policy (.lopsil) Security-relevant methods (.srm) lopsil2aj converter Compiler Architecture 88

/128 LoPSiL Compiler AspectJ pointcut definition for security-relevant methods (.aj) Policy-enforcement code (.java) Trusted application (.class) Untrusted application (.class) AspectJ compiler AspectJ compiler inlines policy code before and after all security-relevant methods and produces an application that is secure w.r.t. the original LoPSiL policy LoPSiL policy (.lopsil) Security-relevant methods (.srm) lopsil2aj converter Compiler Architecture 89

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 90

/128 Case Studies Added features to several applications: ◦ IVCon, JHotDraw, Java Scientific Calculator Purpose: To improve our understanding of IVCon’s software engineering advantages 91

/128 Extending IVCon Added the following features to IVCon: ◦ Search for text in code ◦ Jump to a line number ◦ Open multiple files simultaneously ◦ Show in a tool-tip, concerns implemented at the current mouse cursor position ◦ Linked editing in the unwoven-concerns panel ◦ View flags in the woven view ◦ Jump to a specified concern module in unwoven- concerns panel ◦ Compile and execute code directly from IVCon 92

/128 Implementation Effort Added 1591 lines of code to our existing implementation Total time spent implementing: 45 hours, 13 minutes Time spent defining and assigning code to concerns: 28 minutes Defined 43 concerns across 125 regions in 7 files 93 (1.03% overhead)

/128 Extending JHotDraw and Java Scientific Calculator To JHotDraw (a framework for developing graphics editors) we added: ◦ A feature for asking users, before exiting the program without saving changes to open files, whether they wish to save those changes To Java Scientific Calculator we added: ◦ Three extra memory slots ◦ Grades as a unit for measuring angles ◦ A button that displays the modulus of a complex number 94

/128 Implementation Effort Added a total of 851 lines of code Total time spent implementing: 14 hours, 42 minutes Time spent defining and assigning code to concerns: 14 minutes For JHotDraw, defined 8 concerns in 18 regions across 5 files For Java Scientific Calculator, defined 10 concerns in 27 regions across 19 files 95 (1.59% overhead)

/128 Feature-specific concerns ◦ e.g., FindText, MultiFiles (in IVCon); AskUsersForSave (in JHotDraw); GradeAngle (in Java Scientific Calculator) ◦ Helped readily locate code segments we were working on ◦ Particularly helpful because of code-scattering, e.g., MultiFile crosscut several classes and methods  Allowed us to view all code implementing Multiple- file feature in one place. Experiential Observations 96

/128 Experiential Observations (contd…) Other concerns defined were for implementations that we were referring to regularly ◦ e.g., RTreeFunctions, LexerFunctions Overlapping concerns: e.g., MultiFile overlapped with OpenFile and SaveFile ◦ Flags helped identify where to make changes in unwoven-concerns. 97

/128 Experiential Observations (contd…) To implement the Multiple-file feature, IVCon maintains state information for each open file ◦ Code that saves/updates this information is present in three different places. ◦ Each instance is partially similar to the other ◦ Assigning each one of those instances to a concern helped because we could centrally update it in the unwoven view 98

/128 Performance Evaluation Tested IVCon by assigning code to concerns in two of IVCon’s source-code files: ◦ IVCON.java ◦ Windows.java Also, created an impractically large file ( StressTest.java ) of 100,000 lines, each containing 20 randomly generated single-character tokens 99

/128 Test-file Characteristics Measured time taken for the following operations: assign code to a concern, edit a concern, remove a concern, weaving, and unweaving 100

/128 Results File Name Assign Code to a Concern (ms) Edit a Concern (ms) Remove a Concern (ms) Weaving (ms) Unweaving (ms) IVCON.java Windows.java StressTest.java104, ,050537,95989,534 IVCon performed all operations tolerably quickly on reasonably-sized files. 101

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 102

/128 Case Study Implemented and tested several interesting location-based policies Purpose: To test the usefulness of LoPSiL’s location constructs 103

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 104

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 105

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 106

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 107

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 108

/128 Access-control Policy Prevents an application from reading GPS data outside of work hours public class NoGpsOutsideWorkTime extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized Reaction react(Action a) { if(ActionPatterns.matchesLocationRead(a) && !TimeUtils.isWorkTime()) //return a null location to the application return new Reaction("replace", null); else return new Reaction("ok"); } 109

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 110

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 111

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 112

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 113

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 114

/128 Deviation-from-path Policy public class ShowNavigation extends Policy { public LocationDevice[] devices = {new LopsilGPS(LopsilGPS.GARMIN)}; public PolicyAssumptions pa =... public synchronized void onLocationUpdate() { if(devices[0].getLocation(). distance(getExpectedCurrentLocation(), Units.METERS)>10) AppGUI.displayNavigationalAid(); } Requires that navigational aid appear when the device’s current location deviates from its expected path 115

/128 Other Policies Safe-region Policy: ◦ Requires a robot to encrypt all outgoing communications when the robot’s location is outside a secure-region perimeter Social-networking Policy: ◦ If the policy infers that the device has completed a journey of at least 100km over the past 2 hours, then all friends in the user’s address book who are located within 20km of the new location get invited to rendezvous 116

/128 Experiential Observations Our location-dependent policies consistently based policy decisions on: ◦ Absolute location of the device ◦ Geographic relationship of device’s location with another location, or with a region of locations ◦ Velocity or acceleration of the device Therefore, LoPSiL provides several utility methods for calculating distances, boundaries, velocities, and acceleration Users can access all these methods and can implement other custom operators when built-in methods are insufficient 117

/128 Experiential Observations We found that LoPSiL was sufficiently expressive to specify all the location- dependent policies we considered enforcing None of the example policies mentioned earlier took much time (more than a few hours) to design, specify, and test Therefore, we believe that the six core constructs underlying LoPSiL serve as good abstractions for specifying location- dependent policies 118

/128 Performance Evaluation Tested overhead (on an Android Phone) from four LoPSiL policies: ◦ AllowAll ◦ AccessControl ◦ ShowNavigation ◦ SocialNetworking Recorded the following metrics for the base application vs. the policy-enforced application: ◦ Time taken to execute ◦ Memory usage ◦ Battery usage ◦ Code size 119

/128 Results PolicyTime taken (ms) Memory Usage (Bytes) Battery Usage (%age) Code size (Bytes) AllowAll Base , ,379 w/ Policy , ,939 Overhead ,560 AccessControl Base , ,386 w/ Policy , ,394 Overhead ,008 ShowNavigation Base , ,419 w/ Policy , ,602 Overhead ,183 SocialNetworking Base , ,142 w/ Policy , ,357 Overhead ,

/128Outline Introduction ◦ Motivation ◦ Inline Visualization of Concerns ◦ A Location-based Policy-specification Language An Implementation of IVCon ◦ User Interface ◦ Implementation Details Modularizing Runtime Security Policies ◦ LoPSiL ◦ An Implementation of LoPSiL Validation of Approach ◦ IVCon ◦ LoPSiL Conclusions and Future Work 121

/128 Conclusions Modularizing CCCs in the presence of multi- concern code involves augmenting traditional modularization constructs with extra information about the multi-concern code: ◦ IVCon utilizes a GUI to encapsulate that information Traditional modularization constructs are appropriate for modularizing funtionally orthogonal CCCs ◦ LoPSiL uses aspects to modularize security implementations. 122

/128 IVCon Summary IVCon attempts to help users conveniently create, examine, and modify code in the presence of crosscutting concerns IVCon differs from existing aspect-visualization tools by providing a combination of: ◦ Translations between woven and unwoven views ◦ Token-level granularity in concern assignment ◦ Central code-updates for syntactically equal code segments ◦ Isolation of concerns into distinct modules ◦ Many-to-many relationships between concerns and code ◦ GUI designed to make all of the above convenient 123

/128 LoPSiL Summary LoPSiL is a language for specifying location- dependent runtime security policies LoPSiL is Turing-complete Its novelty lies in its expressive abstractions for accessing and manipulating location information in policies 124

/128 Future Work: IVCon Get usage data and feedback from more users Provide support for multiple languages Use concern information in files to see relations between different concerns ◦ Could possibly help improve suggestions for Eclipse’s Extract into Method/Class refactorings IVCon programming language ◦ Annotations to indicate concern-assignments 125

/128 Future Work: LoPSiL Provide support for composeable policies ◦ Users would have to write effectless policies ◦ We would have to define combinators Write our own code-inliner ◦ Enforce complete mediation of security- relevant methods Model LoPSiL into a formal calculus 126

Thanks/Questions?

/128 Contributions What benefits does a dual view of software and the ability for programmers to define multi-concern code provide? In terms of user effort, can these benefits be achieved with reasonable overheads? What kind of language constructs are useful for policies that reason about a program's execution based on a system's location? ◦ Does LoPSiL provide useful constructs for specifying such policies? What kind of policies would be useful to specify and implement in a language that enables users to specify location-based policies? ◦ How convenient is it to specify those policies in LoPSiL? 128