Modularizing Crosscutting Concerns in Software

1
Modularizing Crosscutting Concerns in Software

• Nalin Saigal

2
Publications
Joint work with

• Jay Ligatti
• Adriana Iamnitchi
• Joshua Finnis

• 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, 2009.
• 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 2009.

3
Software Development Lifecycle

• Design
• Create a structure for the software
• Implement
• Write code for the software
• Test
• Ensure it works correctly

4
Software Development Lifecycle

• Design
• Create a structure for the software
• Organize softwares functionality into various
  modules
• Final software is modularized.

5
Code Modularization

• The practice of organizing code into modules
• Helps separate different functionalities of
  software from one another

6
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

7
Stack Example

• int stackMAX_SIZE
• int size 0
• ...
• //Pushing a onto stack
• stacksize a
• size
• //Pushing b onto stack
• stacksize b
• size
• //Popping b
• size--
• int a1 stacksize
• //Popping a
• size--
• int a2 stacksize
• ...

• We can modularize the operations being performed
  here by defining a class called stack.

8
Stack Example

• class stack
• int aMAX_SIZE
• int size 0
• void push(int data)
• stacksize data
• size
• int pop()
• size--
• return stacksize
• 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

9
Stack Example

• class stack
• int aMAX_SIZE
• int size 0
• void push(int data)
• if (size MAX_SIZE1)
• printErr(Overflow)
• stacksize data
• size
• int pop()
• if (size 0)
• printErr(Underflow)
• size--
• return stacksize
• my_stack

... my_stack.push(a) my_stack.push(b) int a1
my_stack.pop() int a2 my_stack.pop() ...
10
Problem

• Conventionally, software engineers try to
  separate code segments that are orthogonal in
  their functionality into distinct modules
• In practice, this doesnt 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

11
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

12
Example

• String passWord (String)JOptionPane.showInputDial
  og(...)
• 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).

13
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

14
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

Martin Fowler. Refactoring Improving the Design
of Existing Code. Addison-Wesley, 1999
15
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)

16
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)

Refactor

• void withdrawAndDisplay(float amt)
• this.balance this.balance - amt
• printDetails()
• void printDetails()
• System.out.println("Name " this.name)
• System.out.println("Balance " this.balance)

17
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)

Refactor

• void withdrawAndDisplay(float amt)
• this.balance this.balance - amt
• printDetails()
• void printDetails()
• System.out.println("Name " this.name)
• System.out.println("Balance " this.balance)

18
However

• Ultimately leads to relocation of code
• So, if changes need to be made to
  withdrawAndDisplays functionality, we would have
  to locate printDetails also and then edit it
• Unless withdrawAndDisplays functionality was
  completely unrelated to that of printDetails
  i.e., they were functionally orthogonal
• But its not
• Ultimately adds to the code-scattering problem
  discussed earlier

19
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

20
Reason

• The problem stems from these two properties of
  code
• A particular functionality is implemented by
  multiple code segments
• 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 1st property

21
Outline

• 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

22
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

23

• 1. Woven view Displays program code in colors
  that indicate which concerns various code
  segments implement

24

• 2. 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)

25
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

26
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())
accessLog.append("About to read from file
this.toString())
accessLog.append("About to read from file
this.toString())
X
accessLog.append("About to read from file
this.toString())
X
accessLog.append("About to read from file
this.toString())
27
Motivation for Token-level Granularity

• Finer granularity levels are inappropriate
  because tokens are the core semantic units of
  programming languages
• It wont make sense to start concerns from the
  middle of a token
• Coarser granularity in concern assignment would
  reduce precision in concern assignments

28
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

29
Related Work AOPLs

• Typical Aspect-oriented program

Aspects
AOPL Compiler
Core program

• IVCons unwoven view corresponds to a
  programmers view of an aspect-oriented program
• IVCons woven view corresponds to the runtime
  view of the aspect-oriented program

30
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

31
Comparison of IVCon with Related Work
Tool Edit code in dual views Level of granularity Modify identical concern code in one place Isolates concerns Relationship between concerns and code GUI
AspectBrowser No Character-level No No One-to-many Yes
Aspect-jEdit Yes Line-level No Yes One-to-many Yes
Visualizer No Line-level No No One-to-many Yes
CIDE No Nodes in ASTs No No Many-to-many Yes
Hyper/J No Declaration-level No Yes Many-to-many No
C4 Yes Line-level No Yes One-to-many No
IVCon Yes Token-level Yes Yes Many-to-many Yes
32
Outline

• 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

33
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
34
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)

35
Motivation

• Increased computation power of phones
• Users need to treat and secure their phones like
  computers
• However, this doesnt happen
• Makes it easier for a motivated malicious user to
  gain access to a phone and private information on
  that phone

36
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 developers intent may
  be good, it does not necessarily translate into
  secure software.

37
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
• LoPSiLs novelty is that it provides abstractions
  for conveniently accessing and manipulating
  location information in policies
• Location constructs make LoPSiL ideal for mobile
  devices

38
Related Work

• Many expressive policy-specification languages
  and systems have been implemented
• Implemented as compilers that convert untrusted
  into trusted applications

Policy
Trusted Application Program
Compiler
Untrusted Application Program

• The trusted application program is equivalent to
  the untrusted program except that it contains
  inlined code that enforces the policy at runtime

39
Related Work

• 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

40
Comparison of LoPSiL with Related Work
Language Provides Location Constructs Turing Complete Allows flexible manipulation of location information Provides policy composition
Ponder No Yes No No
XACML No No No No
PoET/PSLang No Yes No No
Naccio No Yes No No
Polymer No Yes No Yes
Deeds No Yes No No
SpatialP Yes Yes No No
OpenAmbient Yes No Yes No
Geo-RBAC Yes No Yes No
Android Yes No Yes No
LoPSiL Yes Yes Yes No
41
Outline

• 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

42
Woven View
Woven-body panel is where users write and view
their complete code.
43
Woven View
Concern-legend panel lists all the concerns
defined by the user
44
Woven View
Concerns-at-current-position panel displays the
concerns implemented by the code at the current
cursor position.
45
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, its
  displayed in white text over a multi-concern
  background
• Users can edit code, including concern code,
  without restrictions

46
Other Operations in IVCons Woven View

• Edit concerns (name and/or color)
• De-assign concerns from code.
• Remove concerns
• Rename code regions
• Change multi-concern background

47
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

48
Unwoven View
49
Unwoven View
50
Unwoven View
51
Concern Modules
Concern modules display various code segments
that implement a concern along with the names of
the regions where they appear
52
Concern Modules
Concern modules can also contain constructs
called Flags, which are used to indicate overlap
between concerns
53
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

54
Centralized Code Updates - Example
if (buffer.getSize() gt 512) buffer.truncate(512)
if (getTimeElapsed() gt 2000)
JOptionPane.showMessageDialog(frame,
"Request timed out","Error",
JOptionPane.ERROR_MESSAGE)
if (buffer.getSize() gt ?) buffer.truncate(?) if
(getTimeElapsed() gt ?) JOptionPane.showMessageDial
og(frame, "Request timed
out","Error", JOptionPane.ERROR_MESSAGE)

concern constant subconcern _at_
max_buffer_size_0 _at_
max_buffer_size_1 512 subconcern _at_
timeout_ms_0 2000
55
Centralized Code Updates - Example
if (buffer.getSize() gt 1024) buffer.truncate(102
4) if (getTimeElapsed() gt 2000)
JOptionPane.showMessageDialog(frame,
"Request timed out","Error",
JOptionPane.ERROR_MESSAGE)
if (buffer.getSize() gt ?) buffer.truncate(?) if
(getTimeElapsed() gt ?) JOptionPane.showMessageDial
og(frame, "Request timed
out","Error", JOptionPane.ERROR_MESSAGE)

concern constant subconcern _at_
max_buffer_size_0 _at_
max_buffer_size_1 1024 subconcern _at_
timeout_ms_0 2000
56
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

57
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

58
Flags An Example
We assign all this code to the security concern
59
Flags An Example
We assign the two accessLog.append(..) statements
to the audit concern
60
Flags An Example
61
Outline

• 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

62
Data Structures

• IVCon stores information about concern
  assignments in three key data structures
• regionMap
• concernMap
• regionTree

63
regionMap (HashTable)
64
concernMap (HashTable)
65
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.

66
Outline

• 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

67
Language Overview

• Due to the popularity of Java (particularly Java
  ME) as an application programming language for
  mobile devices, well talk about (and weve
  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

68
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
• Locations 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

69
Core Linguistic Construct 2

• LocationDevice
• Is LoPSiLs interface to real-time location
  information
• LocationDevices must implement two methods
• To return the devices current location
• To return the devices 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

70
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 policys
  granularity or frequency-of-updates assumptions

71
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
  Actions passed to it will execute

72
Core Linguistic Construct 5

• Reaction
• Conveys a policys decision about whether and how
  an action is allowed to execute
• Policies can react to a given Action a by
  returning one of four Reactions
• OK a is safe to execute
• Exception a is unsafe exception should be
  raised
• Replace a is unsafe a precomputed return value
  should be returned instead of executing a
• Halt a is unsafe program should be halted

73
Core Linguistic Construct 6

• Policy
• Specifies constraints on untrusted software
• Five parts to a LoPSiL Policy
• PolicyAssumptions
• void handleGranularityViolation()
• void handleFrequencyViolation()
• void onLocationUpdate()
• Invoked when any LocationDevice associated with
  the policy updates its Location information
• Reaction react(Action a)
• Return a reaction to any security-relevant action

74
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
75
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
76
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
77
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
78
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
79
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
80
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
81
Example Policy AllowAll
public class AllowAll extends Policy public
LocationDevice devices new
LopsilGPS(LopsilGPS.GARMIN)
public LocationGranularityAssumption lga
new LocationGranularityAssumption(15,
Units.METERS) public FrequencyOfUpdatesAssumpti
on foua new FrequencyOfUpdatesAssumption(
10, Units.SECONDS) public PolicyAssumptions pa
new PolicyAssumptions(this, devices,
lga, foua) public void handleGranularityViolati
on()System.exit(1) public void
handleFrequencyViolation()System.exit(1)
public synchronized void onLocationUpdate()
System.out.println("new location "
devices0.getLocation())
public synchronized Reaction react(Action a)
return new Reaction("ok")
82
Outline

• 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

83
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

LoPSiL Compiler
84
Compiler Architecture

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

85
Compiler Architecture
LoPSiL policy (.lopsil)
Security-relevant methods (.srm)

• User specifies desired policy in a .lopsil file
• User creates a listing of security-relevant
  methods in .srm file

86
Compiler Architecture
LoPSiL Compiler
LoPSiL policy (.lopsil)
lopsil2aj converter
Security-relevant methods (.srm)

• 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

87
Compiler Architecture
LoPSiL Compiler
Policy-enforcement code (.java)
LoPSiL policy (.lopsil)
lopsil2aj converter
AspectJ pointcut definition for
security-relevant methods (.aj)
Security-relevant methods (.srm)

• 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
• which policy code is to be executed and
• when should that policy code be executed

88
Compiler Architecture
LoPSiL Compiler
Policy-enforcement code (.java)
LoPSiL policy (.lopsil)
AspectJ compiler
lopsil2aj converter
AspectJ pointcut definition for
security-relevant methods (.aj)
Security-relevant methods (.srm)
Untrusted application (.class)

• The compiler inputs the .java file, the .aj file,
  and the untrusted application (.class) into a
  standard AspectJ compiler

89
Compiler Architecture
LoPSiL Compiler
Policy-enforcement code (.java)
LoPSiL policy (.lopsil)
Trusted application (.class)
AspectJ compiler
lopsil2aj converter
AspectJ pointcut definition for
security-relevant methods (.aj)
Security-relevant methods (.srm)
Untrusted application (.class)

• 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

90
Outline

• 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

91
Case Studies

• Added features to several applications
• IVCon, JHotDraw, Java Scientific Calculator
• Purpose To improve our understanding of IVCons
  software engineering advantages

92
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

93
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

(1.03 overhead)
94
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

95
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

(1.59 overhead)
96
Experiential Observations

• 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.

97
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.

98
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

99
Performance Evaluation

• Tested IVCon by assigning code to concerns in two
  of IVCons 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

100
Test-file Characteristics
File Name File Size (LoC) Total of Concerns Total of Regions Avg Region Size (chars) Max Region Size (chars)
IVCON.java 61 5 7 135.9 337
Windows.java 2,849 20 84 914.4 24,902
StressTest.java 100,000 1,000 5,000 998.0 3,794

• Measured time taken for the following operations
  assign code to a concern, edit a concern, remove
  a concern, weaving, and unweaving

101
Results
File Name Assign Code to a Concern (ms) Edit a Concern (ms) Remove a Concern (ms) Weaving (ms) Unweaving (ms)
IVCON.java 23.78 7.34 9.41 7.03 18.76
Windows.java 295.51 30.15 98.40 943.22 625.45
StressTest.java 104,976 810 1,050 537,959 89,534
102
Outline

• 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

103
Case Study

• Implemented and tested several interesting
  location-based policies
• Purpose To test the usefulness of LoPSiLs
  location constructs

104
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
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
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
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
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
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")

110
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

111
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

112
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

113
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

114
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

115
Deviation-from-path Policy

• Requires that navigational aid appear when the
• devices current location deviates from its
  expected path

• public class ShowNavigation extends Policy
• public LocationDevice devices new
• LopsilGPS(LopsilGPS.GARMIN)
• public PolicyAssumptions pa
• ...
• public synchronized void onLocationUpdate()
• if(devices0.getLocation().
• distance(getExpectedCurrentLocation(),
• Units.METERS)gt10)
• AppGUI.displayNavigationalAid()

116
Other Policies

• Safe-region Policy
• Requires a robot to encrypt all outgoing
  communications when the robots 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 users
  address book who are located within 20km of the
  new location get invited to rendezvous

117
Experiential Observations

• Our location-dependent policies consistently
  based policy decisions on
• Absolute location of the device
• Geographic relationship of devices 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

118
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

119
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

120
Results
Policy Policy Time taken (ms) Memory Usage (Bytes) Battery Usage (age) Code size (Bytes)
AllowAll Base 36.981 2,967 16.25 13,379
AllowAll w/ Policy 37.725 3,211 16.88 68,939
AllowAll Overhead 0.744 244 0.63 55,560
AccessControl Base 86.203 3,976 27 14,386
AccessControl w/ Policy 102.458 4,168 26.88 70,394
AccessControl Overhead 16.255 192 -0.12 56,008
ShowNavigation Base 3.258 4,821 6.38 15,419
ShowNavigation w/ Policy 26.254 5,196 10.5 71,602
ShowNavigation Overhead 22.996 375 4.12 56,183
SocialNetworking Base 2.450 4,679 5.38 14,142
SocialNetworking w/ Policy 82.860 5,035 9.88 71,357
SocialNetworking Overhead 80.410 356 4.5 57,215
121
Outline

• 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

122
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.

123
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

124
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

125
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
  Eclipses Extract into Method/Class refactorings
• IVCon programming language
• Annotations to indicate concern-assignments

126
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

127
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?