Enforcing Security for Desktop Clients using Authority Aspects Brett Cannon & Eric Wohlstadter University of British Columbia Software Practices Lab Vancouver, BC, Canada
{drifty, wohlstad}@cs.ubc.ca ABSTRACT Desktop client applications interact with both local and remote resources. This is both a benefit in terms of the rich features desktop clients can provide, but also a security risk. Due to their high connectivity, desktop clients can leave a user’s machine vulnerable to viruses, malicious plug-ins, and scripts. Aspect-Oriented Software Development can be used to address security concerns in software in a modular fashion. However, most existing research focuses on the protection of server-side resources. In this paper we introduce an aspect-oriented mechanism, Authority Aspects, to enforce the Principle of Least Privilege on desktop clients. This helps to ensure that legitimate resource access is allowed and illegitimate access is blocked. We present a case study applying our approach on two desktop applications: an RSS feed aggregator and a Web browser.
Categories and Subject Descriptors D.2.13 [SOFTWARE ENGINEERING]: Reusable Software; K.6.5 [MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS]: Unauthorized access
General Terms Design, Security
1.
INTRODUCTION
Desktop client applications are a popular form of software which interact heavily with both local and remote resources, such as local disk and network resources. This is both a benefit in terms of the rich features desktop clients (DCs) can provide, but also a potential security risk. Resources must be handled by the application appropriately to ensure confidentiality and integrity of the user’s sensitive information. Aspect-Oriented Software Development can be used to address security concerns in software in a modular fashion. Popular middleware platforms (e.g. Spring Framework) commonly support mechanisms such as role-based access
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AOSD’09, March 2–6, 2009, Charlottesville, Virginia, USA. Copyright 2009 ACM 978-1-60558-442-3/09/03 ...$5.00.
255
control and encryption using pointcut-based deployment. Other research has proposed even more advanced scenerios where AOSD is applied to address security [4, 6, 7, 9, 16, 17, 20, 25, 26, 28]. However, most existing tools and research focus on the protection of server-side resources. There is little existing work which focuses specifically on the protection and privacy of end-user client-side resources. This is important as a recent report has identified “a significant growth in the number of client-side vulnerabilities ... [in] desktop applications” [2]. Resource misuse can arise in DCs in at least three ways. First, a virus, worm, or other kind of malware could introduce malicious code. This code may, for instance, try to open a back-channel, such as connecting to a server to report on user’s usage habits or to reveal sensitive information. Alternatively, it may simply attempt to corrupt or destroy the user’s files. Second, a plug-in might be used by the application which is not as well developed as the application itself. The plug-in could easily misbehave and accidentally delete or improperly write files. Finally, an application developer could be malicious or sloppy in the use of resources. A common methodology to mitigate resource misuse is to follow the Principle of Least Privilege: “Every program ... should operate using the least set of privileges necessary to complete the job” [21]. This could be done by sandboxing a DC and its resource access; then the application could only use those resources necessary for its operation. In the case of a security issue, any negative effects would be limited. The traditional approach for protecting client resources is to use code access security [12]. Platforms such as Java and .NET allow each application to be controlled by a policy that details which resources that code from various components (e.g. a “jar” file) are allowed to access. Essentially, the resource access concern is separated from the code into this policy. This provides the modularity necessary for system administrators and (security savvy) users to control and reason about resource access for third-party applications. Unfortunately it is just not possible to know statically what resources will be accessed by an application at runtime. This is because the resource identity can depend on dynamic program I/O. So to cover all possibilities, many applications are simply given access to all the user’s resources. This is obviously not an option for ensuring a high level of trust in a deployed application [12, 15, 21]. For example, as noted by Wagner [23], the UNIX program cp (i.e. copy) should only have access to the files specified on the command line. However, in its common implementation, cp inherits all the privileges of the current user. To avoid
this, it would seem reasonable to sandbox cp based on its I/O so that the file paths given to the program are the only resources cp has access to. Notice here that to address the example of the cp program, a pointcut could be used to identify the join points where command-line arguments were passed to the application from the console; e.g.
tions. Performance measurements show that the use of runtime monitoring results in little over-head even when entire file streams are monitored for specific data elements. The remainder of the paper is as follows: in Section 2 we present a motivating example, in Section 3 we outline the high-level design of our approach, in Section 4 technical details are presented, in Section 5 we present case-studies of using our approach, in Section 6 related work is presented, and we conclude in Section 7.
execution(void main(String[])) && !cflow(call(* *.*(..))) && args(cmdArgs)
2.
MOTIVATING EXAMPLE
To motivate our work, we use an example where our approach is applied to an open-source application, RSSOwl [18] (in Section 5 we present more details of RSSOwl). The primary function of RSSOwl is to maintain a list of news feeds that the user is subscribed to. When a user selects a news feed, it is downloaded, checked to see if any new items in the feed exist, and the headlines of the items are displayed. Naturally, RSSOwl will require access to a large set of resources such as: configuration files, news feed hosts, software update sites, etc. In some cases, the URI for resources that RSSOwl should have access to could be specified in a policy statically. However, in many cases the URIs of resources that a user wants to access can only be determined by the demands placed on RSSOwl at run-time; such as when a user enters a new feed subscription. When a URI is entered by the user, the GUI framework passes that string unmodified to RSSOwl. If we consider the GUI framework as part of our trusted code base, we do not need to worry about the URI being modified between the user input and the point where it enters the application code. Since we trust the user in their decision of which URI to enter, we could capture the URI at this application entry point to grant permission to access the URI. Our approach leverages authority aspects which capture input at these authorizing contexts and grant the proper permissions to the application. In some cases, resources which are needed by the application are not directly requested by the user but instead are indirectly referred to by other resources requested by the user. In these cases, a DC would first receive permission to read some resource from the file system or network. Then, based on URIs in the resource data, some additional permissions would be needed. Depending on application semantics, it may be useful to transitively grant permissions for these URIs without user intervention. An example is illustrated in Figure 1: a link tag from RSSOwl’s XML-based configuration file. The XML file specifies a link tag for each feed subscribed to in previous sessions. For RSSOwl, if the user gave permission to read the file knowing it is the configuration file, it implies that the application should be able to access the news feed URIs that it contains. In these cases, we use authority aspects to monitor file and network streams for URIs which appear in a context that implies a legitimate need for the resource. Since the semantics of URIs appearing in different contexts is application– specific, we provide support for policies which can be tailored to different deployment scenarios. Finally, in a remaining number of cases, neither a code access policy or dynamic monitoring provides appropriate grounds from which to base access control decisions. In these
Thus an advice could grant permissions necessary to access the files specified in cmdArgs, but no others. Based on this motivation, we are researching more dynamic forms of code access security by leveraging AOP. Using our approach, an application is monitored at run-time by authority aspects. These aspect components are given permission delegation rights to dynamically grant new permissions to base application components when certain preconditions are met. Authority aspects are guided by an extended form of code-access policy. Although the application may be written by an untrusted party, these aspects are implemented by a trusted third-party such as a middleware vendor, virtual machine vendor, or open-source consortium1 . For our approach to be used on an application, an enduser should obtain authority aspects which are specific to some I/O class library frameworks. These I/O frameworks include implementations of GUI widgets (such as Swing or SWT) and implementations of application protocols (such as HTTP protocol libraries). Then an end-user can make use of applications that rely on these frameworks for I/O. In this way, the aspects will serve as a neutral third-party to bridge a trust gap between the end-user and the DC developer. Our approach is not intended as a generic application sandbox which can be used to retrofit any arbitrary application. The technical details of our approach are guided by this methodology: instead of listing static resource identifiers in a policy, policies can list authorizing contexts. An authorizing context2 identifies black-box inputs to an application (e.g. file, network, or GUI input) and properties of data (e.g. XML tags) at those inputs. Authorizing contexts are identified through pointcut designators and XPath rules3 . XPath rules provide a declarative way for users to decribe which URIs4 should be accessible to the application. For example, a rule such as /html//img/@src would provide the application permission to download HTML images. Authorizing contexts are specified separately from the application source code, so it possible to separately audit what kinds of resources the application will be able to access. We have evaluated authority aspects through a case-study of two medium-sized (roughly 50K NCLOC) Java applica1
Currently these aspects are implemented by the authors of the paper. Here we are just laying the vision for how the research could be used in practice. 2 We use the generic term “context” rather than the specific term “join point” because sometimes properties of data (e.g. XML) need to be accounted for, in addition to program execution points. 3 XPath is a file-path like notation for identifying elements of XML documents. 4 Uniform Resource Identifier, a W3C standard for referencing resources.
256
1 2 3
http://www.microsite.reuters.com/rss/topNews
The framework expert binds an authority aspect to a platform-specific implementation for some type of I/O. The binding is performed by implementing abstract methods and/or pointcuts which require platform specific domainknowledge to implement correctly. This allows the abstract policies specified by the aspects to be available to more I/O frameworks used by DC application developers. Such frameworks would include various GUI platforms and applicationlayer protocol stacks. The DC developer develops a DC application with the awareness that only types of I/O with a corresponding authority aspect will be leveraged to avoid explicit user mediation. For some authority aspects, the application developer will be allowed to override abstract pointcuts/methods to include application-specific knowledge. Through a combination of AspectJ’s abstract aspect mechanism and the existing Java security mechanisms, this approach allows for a separation of concerns between the three developers based on their expertise of different requirements. The separation of concerns is paired with a corresponding separation of trust to ensure the safety of the final implementation. The end-user is expected to obtain the binaries for some authority aspect(s) from the trusted framework expert and then use these aspects in conjunction with a DC application that relies on any framework for which they have obtained the appropriate aspects. In order to make this process simple for the end-user a shell script is used to weave the aspects with the application using load-time weaving.
Figure 1: A link element from RSSOwl’s configuration file. RSSOwl lists all previously subscribed news feeds in a link element that is read during startup of the application. cases our approach falls back to explicit user prompting as a last resort. This ensures the approach is fail-safe but could make it impractical if too much user prompting is required. In this section we used an example to demonstrate that certain data flowing into an application from trusted sources can be used to guide resource access control decisions. In order to take advantage of this information coming into the application, some code describing the semantics of the sources must be provided. Unfortunately, we cannot depend on the application developer to provide this code which describes these input source, since it is their code which may be suspect. Our challenge then is to devise a methodology and mechanism that minimizes the amount of explicit user prompting, while securing the application. In the remainder of the paper we will describe an approach that allows this code to be implemented and distributed by a trusted third-party, separately from individual applications.
3.
ARCHITECTURE DETAILS
We describe the roles of different stakeholders of the DC application, followed an overview of the runtime architecture.
3.1
3.2
Runtime Architecture
The runtime architecture of a DC being monitored by authority aspects is shown in Figure 2. In this section we describe the architecture, making reference to this figure. The End User (top left) interacts with the Application (large box on the right), through the user interface. The goal of the monitoring mechanism is to ensure that the application has sufficient access to resources to meet the needs of the user, but not any additional access. The heart of the mechanism is the Java Security Manager (shown center). In Java a custom security manager subclass can be used for any application. It acts as a resource mediator, to determine whether a resource request by the application should be allowed. In order to be useful, the security manager needs instructions regarding which resource access’ to allow and which to block. These instructions are shown in the figure flowing into the security manager (shown as dotted lines labeled Add Permissions). In our approach, this protection state is derived from three sources: a Code Access Policy, dynamic monitoring using authority aspects which can be informed by an XPath Policy, and User Prompting. Here we describe each in turn; in Section 4 we focus on further details of the authority aspect framework since this is our primary contribution.
Stakeholders
We use an aspect-oriented approach which is designed to leverage knowledge that is provided by three developer roles in the construction of secure DC software: a trusted POLP5 policy expert (policy expert), a trusted I/O framework expert (framework expert), and a potentially untrusted authority-aspect aware DC application developer (DC developer). While these roles could potentially be filled by the same person, at least the code developed by the policy expert and the framework expert must be trusted by a DC end-user. Here we describe each of the responsiblities and assumptions of the three developer roles and the end-user. The policy expert designs abstract aspects which reify a crosscutting POLP policy in terms of abstract pointcuts, advice, and/or abstract methods. The details of abstract pointcuts and abstract methods can be left to be filled in by one of the other two developers. This promotes reuse of the policy on more frameworks and applications. The POLP policy expert can mark security critical pointcuts or methods as “package protected” to ensure that only a trusted I/O framework expert should be allowed to override them6 . If the abstract aspect includes pieces which are safe to be filled in by an untrusted application developer, these pieces should be marked “protected”, making them overridable by any sub-aspect.
3.2.1
Code Access Policy
In managed execution environments such as Java and .NET, resource access can be mediated through a code access policy. This policy is essentially a list of pairs of (software component, URI). In Java, for example, a software component is usually identified by a “jar” file. So in Java, a code access policy can describe which objects can access which
5
Principle of Least Privilege. Although packages are open in the Java programming language by default, the Java security policy language allows package membership to be open only to classes from certain binary components 6
257
Figure 2: Architecture of mechanism to monitor resource access for a DC.
URIs based on the “jar” file that the class of the object originated from. This is because some software components may be trusted more than others. Although the details vary, the important point for our purposes is that these code access policies are specified statically and do not consider dynamic program input. In our approach, authority aspect binaries are distinguished in a code access policy so that these components may dynamically grant new authority to undistinguished base application components, which have no authority by default.
3.2.2
to access a resource. URIs that appear in these authorizing contexts are then cleared through the security manager. The user needs to be aware of what consequences their actions may cause. When directly inputing text into the GUI, they know what they are typing. However, when they select items such as an HTML link using the mouse, the end user needs to be told what resource access their selection will require. A Status Bar (shown in the left side of the figure) updates the user as to what, if any, authority will be granted if they select a widget. This is much like a status bar in a Web browser like Mozilla Firefox that displays what URI a hyperlink points to when a user hovers their mouse over the link text. In spirit, our architecture is like the very simple cp example discussed in Section 1. The research challenge is to determine if this approach can scale to realistically–sized applications which may use many input and output channels.
Authority Aspects
Monitoring input provides the leverage needed to control resource access dynamically. This is because input data often implies the need for resource access, but output data does not. For example, HTML read as input to a Web browser creates a burden to retrieve additional resources such as images; however, requests originating from the browser to a Web server place no such burden on a browser. Consideration for output is only necessary to ensure that our safeguards are not circumvented. These details are described in Section 4. Monitoring input to authorize resource usage crosscuts the architecture of a desktop client application. In a typical DC, input comes from three primary sources: the disk, the network, and the GUI. Our approach leverages AspectJ [11] to weave into applications written in Java. Authority aspects are used to identify URIs which appear in authorizing contexts. At the lowest level, DCs read from disk and network resources through input streams (represented at the bottom of the figure). DCs often use standards such as HTTP to communicate over streams using other standards like XML to format the data. When data is read from streams, aspects monitor read operations to locate URIs appearing in an authorizing context. Advice can then grant permission to the application for a specific URI by contacting the security manager. The GUI is typically how a user directly interacts with a program. Users often request access to resources directly from keyboard input and indirectly through mouse selection. When data is input through the keyboard and mouse, aspects are used to monitor GUI inputs that imply the need
3.2.3
Explicit User Prompting
The easiest way to ensure no resources are accessed against a user’s wishes is to explicitly prompt the user [27]. These prompts are used, for example, in some client-side firewall programs. A typical prompt will ask: “The application is trying to access resource: allow once, allow always, or deny?”, where resource refers to a sensitive or suspicious resource. This is demonstrated in Figure 3.2 by the dotted line between the end user and the security manager. Explicit user prompting provides total resource mediation but also requires the explicit involvement of the user. This can easily be done by tying into the security manager and having all failed authority access requests trigger a prompting. So on the one hand, user prompting provides mediation for every single resource access attempt by the application and is totally dynamic. However, users may become frustrated or annoyed by frequent prompting. This is described in the literature as psychological acceptance [21] and was the subject of a recent television advertisement7 . Our approach is intended to ensure psychological acceptance by minimizing the amount of user prompting neces7 See the Apple security ad from 2007 at http://www.cs. ubc.ca/~drifty/macsecurity.html.
258
1 2 3 4 5 6 7 8 9 10 11 12 13
sary. This is done (as described in the previous sub-section) by monitoring contexts which imply that a user has already expressed their intention to access the resource. For example, if a user enters a URI to add an RSSOwl news feed, there is really no need to ask the user one more time if they want to access that resource. To evaluate our approach in Section 5, we discuss how much prompting is necessary for two medium-size DC applications after our approach is used.
4.
IMPLEMENTATION DETAILS
The following section discusses the details in implementing our approach.
4.1
if (format.equals(Format.XML)) // Parse XML from stream for URIs. else if (format.equals(Format.HTML)) // Parse HTML from stream for URIs. return delegate; }
Figure 3: The wrap method, written by a policy expert, is used in authority aspects to begin the monitoring process. The getDelegate method provides the wrapper which parses actual stream data (details not shown).
Network and Disk I/O
DCs interact with network and disk resources using stream buffers. In Java, the class InputStream serves as the superclass for network and disk-bound streams (shown as Application Streams in Figure 2). Authority aspects monitor information read from InputStreams in standard formats in order to capture URIs appearing in a context that implies a user’s intention to allow resource access by the application (shown as Aspects surrounding Application Streams in Figure 2). This intention is described using our XPath policies (shown being fed into the aspects of Figure 2). System administrators or users can control a policy file consisting of authorizing contexts specifying which URIs are authorized based on their location in some XML document from disk or network. The XPath policy file consists of a list of XPath rules. Each rule specifies if it applies to a specific document (e.g. configuration file), all network input, or to all documents selected by the user through the GUI. The rule then contains location steps which point to a specific XML tag. Consider RSSOwl and its configuration file (discussed in Section 2). The rule to grant permissions for the feeds listed in the file is:
handler starts consuming input in a separate thread from the application, launched on line 8 or 10 (details are not shown but are straightforward). This allows the DC and the content handler to execute concurrently. When a URI is matched in a context specified by the policy, the URI is cleared through the Security Manager (as shown by the Add Permissions edge in Figure 2). After returning from the advice, the DC will now read bytes from the wrapped input stream without awareness that it is being monitored. However, inside the decorator, whenever some bytes are read, they are also copied and passed on to the content handler. This handler executes in a separate thread, so the application is not required to block while the data is processed by the handler. Essentially, every byte that is pulled from the stream by the application is also simultaneously pushed to the content handler thread by the decorator. One final implementation detail needs to be handled for this approach to be sound. Since the DC and content handler execute in separate threads, there is a race condition where one thread finds URIs in the stream first. This is a problem if the DC requests access to a URI that it finds before the content handler has time to find and authorize the URI. For this reason, we impose a lock on the security manager which is released when all content handlers executing at the time of the resource request are finished. We use this approach rather than forcing a sequential execution of DC and content handler because it is unlikely the DC will ever beat the content handler in some race. That is because the content handler is only programmed to find URIs and pass them to the security manager, whereas the DC is a complete application, programmed to process all the data in a stream and apply arbitrarily complex program logic on the data. So, even though the lock is not likely to be necessary, it must be included to ensure correctness. In cases where it is not needed the content handler and DC are free to run concurrently.
document(configFile)/rssowl/favorites//link This rule acts as an authorizing context saying that the application should have access to any URI that is given in a link tag that is nested below the tags rssowl and favorites in the document located at configFile. Supposing this was the only rule in some policy file, the user would safely be assured that the only URIs which the DC will have access to are those identified by that rule or given explicitly through the GUI. The user would not have to be prompted to give explicit permission for all of these resources which are listed in the configuration file.
4.1.1
static T wrap(T stream, Format format) { PipedInputStream in = new PipedInputStream(); PipedOutputStream out; out = new PipedOutputStream(in); T delegate = getDelegate(stream, out);
Stream Monitoring
Monitoring of streams is achieved through a wrapping procedure in the method wrap (Figure 3). The method takes an InputStream captured at some join point in DC execution along with the format of data being read from the stream. Different authority aspect specializations of stream handling (file and network) rely on this method to initiate the stream monitoring process. The stream is wrapped (lines 2-5) by a decorator so we can monitor data read from the stream. The decorator forwards information read from the stream to a content handler which parses either XML or HTML data. This handler attempts to match rules from the XPath policy. The content
4.1.2
Network Input
Our current implementation supports DCs which make use of the HTTP protocol for application-level transport. Figure 4 shows an aspect which supports an HTTP library included with the JDK. Support for third-party HTTP libraries (e.g. Apache HTTPClient) could be added by a
259
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
public abstract aspect HttpURLConnectionAspect {
As mentioned previously, rules in the XPath policy file can be rooted at a specific document. For these rules, we read the specified documents upon the start of the security manager and before the application begins. This allows execution-critical permissions required for the application to begin functioning to be created before the application needs them. During program execution, aspects monitor the use of the GUI for any additional URIs to be cleared or URIs removed (described below in Section 4.2). Thus, the security manager state reflects both the URIs from configuration data and changes during execution. Still, we need to save this state in some way, so that it can be used the next time the application is launched. Ideally, since the application will save its own state in its configuration files, it may seem possible to simply leverage the application’s behavior. That way the security manager would not need to persist it’s own state; when the application starts up again, the protection state could be reconstructed by interpreting the configuration files. However, this approach is difficult to apply in practice directly. The problem with this ideal approach is that we may not be able to trust the data written by the application to disk. Even if we trust the software component which writes the data, the data itself may have become tainted by some other malicious piece of code. In our framework, we leverage the application’s own behavior for saving configuration data, but also perform additional run-time verification. This is achieved by postprocessing the configuration files written by the application. Each configuration file is read by the security manager during program exit8 to determine if it matches the state of the security manager. If it does not, a warning is issued to the user. Post-processing of configuration files is achieved using the same content handlers which are used to interpret the reading of file streams during regular program execution. The only difference is the way in which URIs are handled when they are discovered. In this case, instead of authorized URIs which are discovered, the security manager ensures that the URI already exists as part of its state.
pointcut monitor(): call(InputStream HttpURLConnection.getInputStream()) && !restrict(); protected pointcut restrict(); InputStream around(HttpURLConnection that): target(that) && monitor() { String url = that.getURL().toString(); if (SecurityManager.isURLSafe(url)) { SecurityManager.allowProceed(); } InputStream stream = proceed(that); if (that.getContentType().contains("html")) return wrap(stream, Format.HTML); else if (that.getContentType().contains("xml")) return wrap(stream, Format.XML); else return stream; } }
Figure 4: HttpURLConnectionAspect. Network stream monitoring aspect written by a framework expert. The protected pointcut restrict can be overridden by a DC developer for application specific optimization. framework expert familiar with the third-party library. The package protected pointcut on line 3 identifies the input stream objects which are subject to monitoring. The protected pointcut restrict can be used by a DC developer to further restrict the set of connections that are monitored. This is useful for optimization if a developer has application specific knowledge that some HTTP connections will never be used to read in resource identifiers. Connections are handled by the advice on lines 10-27. The aspect allows the application to open a new stream only if the URI specified has been previously cleared (lines 13-16). As was described, this clearance would have been made by some other authority aspect. Lines 20-23 are used to deduce whether HTML or XML was received. We monitor the HTTP Content-Type header to make the determination. Based on this information a call to the wrap method, provided by the policy expert, is used to begin monitoring the content as described in the previous section.
4.1.3
4.2
GUI I/O
In addition to monitoring information from I/O streams, authority aspects are also used to monitor the GUI (shown as Application GUI Widgets in Figure 2). Our framework also provides several types of feedback to the user. This is done through special views such as the Status Bar (as shown in Figure 2). These views are presented in a separate part of the screen which the DC is prevented from using.
4.2.1
Disk I/O
Text I/O
To monitor URIs entered as text strings by the user, we make use of the DirectGUIInput aspect, in Figure 5. This abstract aspect is parameterized by the type of the widget, for example, JTextField (Swing), Text (SWT), etc. Concrete specializations of this aspect must be provided by a framework expert because these aspects must be trusted. The method toURI (line 3) is overridden to provide the URI which is currently input to the widget (or null if none is available). The pointcut textReady (line 4) is used to
DCs often use configuration files stored on disk to list resources that the application will need to access. For example, RSSOwl saves previously added news feeds in its configuration. A FileStreamAspect, similar to HttpURLConnectionAspect is used to monitor file I/O (details not shown). A DC will typically read configuration data into memory when an application is launched. Then, during program execution, the data in memory can be mutated by the user through a GUI. When the program exits, the new data is written back to disk.
8 Java provides for the execution of a shutdown hook which is executed whenever a JVM terminates.
260
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
abstract aspect DirectGUIInput {
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
abstract String toURI(T widget); abstract pointcut textReady(); after(T that): target(that) && textReady() { if (that.tainted) return; SecurityManager.authorize(toURI(that)); } abstract pointcut catchTainting(); boolean T.tainted; before(T that): target(that) && catchTainting() { that.tainted = true; } }
Figure 5: Abstract class for tracking text entered into the GUI. Written by a policy expert. A framework expert specializes this aspect for GUI widgets that accept text directly. Each sub-aspect overrides toURI() to retrieve the text. Detection of potential manipulation by the application is done through catchTainting() to prevent inappropriate authority being granted. Although AspectJ does not support inter-type declarations on parametric types, it is used for illustrative purposes.
public abstract aspect IndirectGUIAspect { protected abstract pointcut monitor(); after() returning (T widget): monitor() { register(widget); } abstract void register(T widget); protected abstract String toURI(T widget); String T.mappedURI = null; void hover(T widget) { widget.mappedURI = toURI(widget); SecurityManager.notify(widget.mappedURI); } void select(T widget) { String uri = widget.mappedURI; if (uri == null) uri = toURI(widget); SecurityManager.authorize(uri); } }
Figure 6: Abstract class for managing indirect GUI input. Written by a policy expert. Callbacks are registered on a widget by a framework expert by implementing the register method. A DC developer can implement the monitor pointcut and toURI() to control how to map the widget to a URI.
signal when the widget should be checked for text input (typically when a method used to read from the widget is called). At this point, the URI is read from the widget and cleared by the security manager (line 10) unless the widget has been tainted. Although we can trust the user who enters text to the GUI, most text based widgets also support values being fed into the widgets programmatically. For example, many widgets include a method such as setText. This is a problem if we cannot trust all code which might influence these values. Consider that a virus may modify the fields arbitrarily or a plug-in may be able to influence the value through data-flow from its interaction with a plug-in API. Our aspect considers any text widget to be tainted if its value was set by the application. The pointcut catchTainting (line 13) is triggered at these points, so a widget will not be trusted. A taint flag is added to the widget from the inter-type declaration on line 14. The DirectGUIAspect includes some details which are framework specific but would not be safe to be specified by an untrusted application developer. Since the DirectGUIAspect receives text input from some widget directly we have made the toURI method package protected. Essentially, a framework expert can “vouch” for the integrity of some widget implementation by providing a sub-aspect which binds the abstract pointcuts to that widget. We currently have implemented concrete aspects for various widgets from the Swing and SWT toolkits. Unlike stream data where users could specify specific elements to be monitored, we don’t provide a way for the user to specify which widgets are monitored for input. A user who makes use of our framework is advised that any URI they enter may lead to the application having access to that URI.
4.2.2
Mouse Input
Not all input in a GUI is through a direct specification of URI text. In many cases, mouse-driven GUI widgets represent some URI resource indirectly. Because of this, proper support needs to be given to map a user’s interaction, to the URI that some GUI widget may represent. Consider hyperlinks in a Web page. Each of those hyperlinks represent a URI to a site that the user wants to visit. Permission should not be granted to the various links automatically as that would allow the application to essentially crawl the Internet. However, if a user clicks on a link then the permission to connect to the URI should be granted. Interpreting a user’s intentions from mouse interactions can be more difficult than the case of URI text input. This is because DCs typically present the user with representative references to URIs instead of URIs themselves. For example, the HTML anchor tag,
, is presented based on its content rather than the associated URI. Still, selecting the anchor should cause the associated URI to be retrieved. Essentially, we must deal with this additional mapping of widgets to URIs in our framework. To monitor the selection of widgets that indirectly refer to URI resources, we make use of the IndirectGUIAspect aspect, in Figure 6. This abstract aspect is parameterized by the type of the widget, for example, JList (Swing), List (SWT), etc. For our authority aspect, two kinds of mouse events are monitored on these widgets: one to provide feedback to the user about the URI mapping and one to authorize mapped URIs. The monitor pointcut (line 3) is used to identify widget objects for monitoring. These widgets then have listeners added to them to catch these events (line 5-7). The aspect includes an abstract method toURI which is
261
1 2 3 4 5 6 7 8 9
public aspect ListAspect extends SWTAspect {
5.
CASE-STUDY
For this case study we wanted to understand two properties of the approach better. First, we wanted to know if the monitoring capabilities presented were sufficient to cover the implementation of realistic applications. We anticipated that off-the-shelf applications may use some features that our approach would not be able to support. For example, we knew before we began the case study that applications using our approach could not make use of native methods. Even though it is not our intention for our approach to be used as a way to automatically retrofit applications with security, it is useful to elucidate where some existing applications diverge from the methodology required by our approach; this case-study is not intended to test the hypothesis of whether our framework would work well for any randomly chosen off-the-shelf application. Second, we wanted to better understand the effort involved in applying our approach for a realistic application. By applying the approach ourselves, we hoped to report our experiences and some of the lessons that we learned. We looked to select DCs that had no security in place but could benefit from restricting its permissions to access resources. We evaluated two such applications: RSSOwl and Lobo [1]. RSSOwl is a 46K NCLOC RSS reader written in Java. It makes use of the SWT widget toolkit, HTTP protocol, RDF and Atom XML formats, and an XML configuration file. Lobo is a 61K NCLOC Web browser written in Java. It makes use of the Swing widget toolkit, HTTP protocol, and HTML format. We estimated coverage of each application’s features by using the GUI as a coverage criteria. Essentially, we manually exercised each feature of the application that was induced by GUI input and noted what permissions were requested to perform the action. Although we believe we have covered all the features of the applications, it is possible we had somehow missed a feature that was not obviously accessible in the GUI. However, since any overlooked feature was not obviously accessible, it is probably not frequently needed by users. Therefore the fact that access control for the feature may be covered by explicit user prompting is not likely to be irritating for the end user. Here we describe our experiences of the case-study, covering each of the steps of our methodology.
protected pointcut monitor() : call(List.new(..)); protected String toURI(List widget) { return widget.getItem(widget.getFocusIndex()); } }
Figure 7: Implementation of IndirectGUIAspect for SWT’s List widget The toURI() method is implemented to return the URI represented by the list item the user is hovering/clicking on.
implemented by an application developer to provide the URI which some widget is mapped to. This mapping is application specific so it must be provided by the developer of a specific application. Since we cannot assume the developer is trusted, special care is required in the handling of these widgets. This is achieved by querying the toURI method when a user places the mouse over some widget but before the widget is selected. The URI retrieved from the developer’s implementation of the method is then presented to the user in the status bar (as described in Section 3). This way the user can review the mapping between the widget and a URI before they select the widget. If they find no problem with the mapping they can select the widget and the URI is cleared by the authorizing aspect. Using the status bar in this way is less intrusive than forcing the user to interact with a prompt after they have selected the widget. Browsers such as Mozilla and IE use this technique. Our aspect allows the technique to easily be added to any DC. We have designed the abstract IndirectGUIAspect (Figure 7) to reify one policy for granting resource access to a DC, based on mouse input. The policy includes the Status Bar feedback mechanism for end-users to evaluate which URIs will be accessed when a widget is clicked. This makes it safe for us to allow an untrusted DC application developer to provide a widget to URI mapping through the protected toURI abstract method. An example of a concrete IndirectGUIAspect implementation is shown in Figure 7. The aspect SWTAspect (not shown) extends from IndirectGUIAspect and provides an implementation of event listeners that make calls to the hover and select methods of IndirectGUIAspect. ListAspect then extends from SWTAspect to provide List specific implementation details. Here a developer maps a widget to a URI based on the item in a list which is the focus of mouse events. Deletion of items stored in a configuration file is also typically done indirectly through the GUI. These GUI interactions tend to be application-specific. For this purpose, we provide an aspect the developer can use to inform the security manager to delete some permissions. When the deletion of a permission has occurred, the user is notified through the status bar of the deletion. That way, if the user deletes something that she expects to lead to the removal of a permission, they can watch for the deletion notification. If the notification never occurs, the user then knows the application is not acting in a way that is expected.
5.1
RSSOwl
As an overview of our experience, Table 1 shows the tallies of what kind of mechanism was needed to support the features of RSSOwl we tested. The first column, Authority, lists the name of an authority aspect, specifies user prompting, or the traditional Java code access policy. The second column, Details, lists either a specialization of the authority aspect for a specific kind of widget or the XML format which is addressed by an XPath policy, or the number of cases the mechanism was used.
5.1.1
Code Access Policy
At startup RSSOwl connects to www.rssowl.org to perform a version check to see if the user is running the newest version of the software. This URI can easily be included by the developer in a code access policy distributed with the application.
262
Authority Code Access Policy DirectGUIAspect IndirectGUIAspect DeletionAspect FileStreamAspect HttpStreamAspect User Prompt
Details 1 instance swt.Text swt.FileChooser swt.Table 2 instances RSSOwl XPath OPML XPath RSS XPath Atom XPath RSS XPath Atom XPath 1 instance
of RSSOwl would need our framework to provide explicit support for this API in order to properly control its use. This support was not difficult to add, but would need to be added on a case-by-base basis.
5.1.4
Table 1: Mechanisms used to support RSSOwl security.
5.1.2
User Prompting
The first step to startup for RSSOwl is determining what directory contains RSSOwl’s configuration data. RSSOwl uses an algorithm to create a URI for the directory, depending on the current machine’s operating system. Since this path is determined at run-time and it does not depend on any input, it had to be cleared through user prompting. We felt this was reasonable since the application was going to determine on its own where to begin placing new files on the user’s machine. We think that in many cases the user would appreciate being notified of this fact. Other than for initial configuration an application, RSSOwl did not require any permissions to be specified through explicit user prompting once pieces of our framework from Table 1 were put in place.
GUI I/O
Several GUI interactions in RSSOwl lead to the user directly entering a URI. For these situations we used our DirectGUIAspect to monitor the interactions. A GUI interaction such as selecting File -> New -> Favorite pops up a dialog box that accepts a URI to a feed. The URI entered by the user should be accessible by RSSOwl without requiring any additional prompting of the user. The DirectGUIAspect was useful for 8 use-cases. Our IndirectGUIAspect was used to define an authorizing context to inform users of the hosts for various news items in a feed. This way the user could evaluate whether or not a news item should be retrieved from a specific host. When the user deletes a feed, the permission to access that feed should be removed. Our DeletionAspect was needed in two cases. Once for removing news feed categories and once for removing news feeds themselves.
5.2
Lobo
As an overview of our experience, Table 2 shows the tallies of what mechanisms were used for Lobo. Authority Code Access Policy DeletionAspect HTTPStreamAspect FileStreamAspect DirectGUIAspect IndirectGUIAspect
Specialization 5 instances 1 instance HTML XPath HTML XPath JFileChooser JTextField cobra.HTMLLink JMenuItem
Table 2: Mechanisms used to support Lobo security.
5.1.3
Disk/Network I/O
RSSOwl uses an XML configuration file to specify the URIs for the feeds the user is subscribed to. Here we used our FileStreamAspect equipped with authorizing contexts defined as XPath rules for the RSSOwl configuration file format. To create these rules we inspected the RSSOwl configuration file to understand which XML elements were used to encapsulate URIs that were needed by the application. The second situation where disk I/O must be handled is when XML is read from outside the application’s configuration directory based on user input. This is exemplified by importing an OPML file. OPML is an XML file format for storing directories of RSS feed providers. Similar to the previous example, we used the FileStreamAspect with OPML XPath rules. Since the semantics of the OPML file are standard, it was simple for us to create the rules which provided the necessary interpretation. RSSOwl uses the network to download representative icons for the various feeds. The HttpStreamAspect was used to gather the authority needed to download the proper icons as specified in the various RSS and Atom formats. For displaying the Web pages for new items, RSSOwl uses an SWT API9 to launch an external browser. We did not anticipate this use-case. Using our approach, the developers 9
5.2.1
Code Access Policy
There are five specific instances of whitelisting for Lobo. The most important one is whitelisting the application directory. Since it is specified as ${user.home}/.lobo in the source code, the directory can be specified in the whitelist since system properties are supported by Java’s code access policy. Three instances of using the whitelist is for the Page Services menu. The menu options use the current page as part of a query performed at three different Web sites (e.g. google.com). One can statically list those sites and thus allow the query to take place without requiring any prompting of the user. Lastly, Help -> Project Home takes the user to the Lobo project home page. Much like with the menu option that takes the user to Google, whitelisting the Lobo project home page allows the initial connection to the site occur.
5.2.2
GUI I/O
In Lobo, GUI I/O is used when a URI is specified in a traditional browser navigation bar. By monitoring what is entered in the bar, Lobo can be granted the permission to download the HTML for the page desired. Here the DirectGUIAspect was used and specialized for a Swing text field.
The org.eclipse.swt.browser.Browser class.
263
Alternatively, Web pages can be loaded from disk using the File -> Open -> File menu option. In this case the DirectGUIAspect was specialized for the Swing file chooser. To support browsing behavior through clicking on hyperlinks, tags were monitored using the IndirectGUIAspect. Lobo did not include a status bar feature like traditional browsers so our aspect added this additional feature. Our implementation originally assumed applications would only use the widgets provided by a GUI toolkit. Lobo uses a custom HTML renderer (named Cobra) which draws directly to the screen10 . To support this use-case in our framework required adding lower-level support for Swing’s direct screen mapping. Finally, Lobo allows users to select bookmarked Web pages through menu items (as in traditional Web browsers). This indirection between the bookmark title and the bookmark URI was also handled by the IndirectGUIAspect similarly to the case for tags.
5.2.3
Disk/Network I/O
To properly display HTML downloaded from the Internet, certain tags need to have permission to access the URI the tag refers to. In some cases, images and scripts are loaded from a host name that is different from the host of the initial web page. Since the user only authorized the download of the initial web page, these auxiliary resources still need to be handled. This can be handled through the use of XPath rules which automatically clear the hostname for the image or script URI. If the user is careful to only visit trusted sites, then it is safe to clear connections to these image and script resources. We do not attempt to help the user choose which sites should be trusted or not, this kind of decision making is outside the scope of our security mechanism implementation.
5.2.4
User Prompting
Lobo has no need for user prompting. We were able to provide all needed permissions from monitoring input or from the code access policy.
5.3
Performance
Feed CNET mozillaZine MajorGeeks freshmeat PC Mag. BetaNews Slashdot SnapFiles
Size
14 38 6 103 16 9 34 18
K K K K K K K K
Items
Original
Aspectized
Parsing
25 12 20 68 10 15 15 48
305/7 143/2 97/3 256/2 87/4 112/6 129/6 133/3
315/3 149/9 98/2 303/3 94/4 105/7 139/6 135/7
19/08 20/08 8/02 79/46 9/04 11/06 12/01 7/01
Table 3: Overhead in RSSOwl from parsing feeds for URIs. Items is the number of news items in each feed. All timings are in milliseconds, followed by the standard deviation over 10 trials. The Parsing time is how long it took to parse.
6. 6.1
RELATED WORK Explicit Authorization
Yee [27] introduced the Principle of Explicit Authorization: the safest way to ensure that resources are accessed according to a user’s wishes is to allow the user to mediate resource use. As a proof-of-concept, a custom file chooser GUI widget is given by Yee. The use of the file chooser is natural for users as it provides a transparent way to monitor the intentions of
We wanted to test application performance with and without our monitoring mechanism. The most performanceintensive part of our framework is certainly the additional 10
parsing of stream input. We chose to test RSSOwl feed loading with and without authority aspects. Initially we planned to report performance numbers from Lobo, however we quickly realized that rendering HTML pages is more CPU-intensive than loading news feeds. This masked the overhead introduced by our authority aspects, so we chose to study RSSOwl. Table 3 shows the performance numbers for RSSOwl. The time that was measured is from when a feed is selected to when the news items are displayed by RSSOwl. All times were run on a 1.6 GHz Intel Core 2 with 3 GB of memory on Windows Vista Home using Java 6. All timings represent how long it took RSSOwl to load a news feed. These news feeds were chosen since they are defaults in the Software category of RSSOwl. Each feed represents the news from the host indicated on September, 29 2008. The news feeds were saved to file and loaded from disk. This was done to remove effects of network latency from the measurements. The Original times are using an unmodified copy of RSSOwl. The Aspectized times are running RSSOwl with our framework. The FileStreamAspect is used to monitor the feeds as they are loaded. The Parsing times show just the time spent parsing the data by the content handler. The Aspectized times include the Parsing times, but since the parsing is done in parallel the overhead does not lead to a linear increase in time. Typically the performance overhead is quite small, and 16% slower in the worst case. Since RSSOwl is I/O–bound and typically is waiting for user input, even if the slowdown applied uniformly across our test feeds it would still be negligible overhead. But most of the timings are very close (and in one case, better) where the difference is less than 10 ms. Note that because of the standard deviation it would be wrong to conclude the aspectized version was faster in any case. To decide if the memory usage of our approach is reasonable, we considered a conservative scenario involving Web pages. Consider a user who visits 1,000 Web pages, each containing 100 hyperlinks with URIs containing hostnames that have a character length of 255 characters (the maximum allowed by DNS [5]) and an overall URI length of 300 characters, and link text that is 100 characters long. Creating a mapping between the link text and the URI as if the user hovered on every link would require storing each once. If the user also visited every link, that would lead to each URI being stored along with the permission to connect to the URI. Working with Java’s internal string encoding of UTF-16 [3], 80 MB is used to store the characters mapping link text to the URI and 60 MB is used to store the URIs: 140 MB total. To lower this cost we could provide a way for policies to indicate whether permissions were granted persistently or transiently.
Direct screen drawing is done through java.awt.Graphics.
264
users resource access decisions. Other work provides implementations of this file chooser widget for both Windows and Solaris [10, 22]. However, their implementation only handles explicit authorization for one specific widget type.
6.2
A DSL was introduced in [16] to help harden existing applications. Their goal is to provide a DSL that non-security experts can use to secure an open source application. This varies from our approach as the developer is a trusted participant in the hardening process instead of as a possible adversary. The authors also focus on adding security to preexisting applications while we prefer (but do not require) to have our approach introduced during the development process. AOP has also been harnessed for intrusion detection [17, 28]. Haley et. al. enumerate key assets and potential attacks to discover the crosscutting concerns involved in security issues [7]. Others have created access control systems specifically for use with AOP [20]. Our framework differs from all of these approaches by supporting the POLP by restricting resource access for applications. None of the previous work in AOSD has described how to support this particular security requirement. The approach we proposed relies on monitoring the use of I/O channels which crosscut the application source code and connect an application to its environment. Specifically, we considered special requirements for I/O channels such as graphical user interaction and structured data formats such as XML. Since it is common for I/O channels to be implemented as frameworks or middleware libraries, we leveraged AspectJ’s abstract aspect mechanism to separate highlevel policy from framework specific deployment. Differing from previous work which has explored abstract aspects, we needed to consider the decomposition of aspects based on separation of concerns of the developers in conjunction with the trust associated with different developers (e.g. policy expert, framework expert, and DC developer described in Section 3).
Privilege separation
As noted by Provos et al. [19] in their work on privilege separation, it is useful to isolate code that is critical to security to specific modules. Our approach helps with minimizing the amount of code that needs a security audit for DCs, because the resource access behavior of the application is refactored into auditable policies.
6.3
Object Capabilities
Object-capabilities enforce security through the control of references to security-critical objects, as covered by [15]. Work with Java and capabilities has been done in both [8] and [14]. These approaches allow for a very fine-grained level authority control that can be dynamically determined. However, mainstream programming languages and execution platforms are not capabilities-based. Additionally, these capabilities languages do not expose external policies to control resource access.
6.4
Language-Based Information Flow Analysis
Language-based information flow analysis can be used to ensure that untrusted data does not flow to some sensitive operation; this can be achieved both dynamically and statically. Tainting is the technique of dynamically marking input into a program as untrusted and preventing all such input from being used in any sensitive way at runtime [13]. Static analysis can also be used to provide a conservative approximation of whether untrusted data may be used in a sensitive operation. Our approach can be viewed as an information flow policy which mandates that resource identifiers used in resource access operations have originated from a trusted source: GUI, disk , or network I/O. The implementation of our security mechanism is more similar to tainting-based systems than to static analysis since it is based on run-time enforcement. This is motivated by the need to distinguish between different elements which can only be determined at runtime, e.g. the content of an XML document.
6.5
7.
CONCLUSION
In this paper we have presented a framework to allow desktop application developers to apply the Principle of Least Privilege for resource access while being an untrusted participant in the security mechanism. By monitoring I/O through authority aspects, our framework is able to detect a user’s intention in terms of accessing resources. This allows the user to have complete security coverage when used in conjunction with explicit user prompting. We did not compare to a standard OO decomposition in terms of crosscutting metrics because the code for the policy expert and framework expert roles must be separated from the implementation of application code for security reasons. This code needs to be deployed separately but it needs to be activated by events occurring in the application code. For this reason we chose to leverage AspectJ with its support for binary load-time weaving. This, however, brings up the important question of whether we could have achieved the same secure decomposition by using a custom program instrumentation, for example implemented on top of BCEL, rather than a full-fledged AOP language. Hypothetically, this would be achieved by the policy expert writing the binary instrumentation tools. The tools would need to take as input some specifications from the framework expert and DC developers to customize the instrumentation with their domain knowledge. However, a specification-driven instrumentation that is simpler than AspectJ is not likely to be flexible enough for our purposes. Such a specification language would need to
AOP security
Security is a well known crosscutting concern which can be described and implementing using an aspect-oriented methodology [25]. As with any software methodology, the benefits and costs of using a specific methodology can depend on the precise requirements of a particular software development project. AOP’s flexibility has allowed its use to introduce security into an application, like Walker et. al. who used their declarative event patterns to add user authentication for FTP [24]. Leveraging existing security libraries and weaving them into an application was explored in [9]. Other research explores using AspectJ to implement an entire security kernel for Java [26]. In [6] security policies based on different types of role-based access control are implemented using AOP. Tying together several security systems at once into a compositional framework is even possible. Charfi et. al. integrate security policies into business workflows using AOP [4].
265
include primitives that were powerful enough to capture the peculiarities of every potential I/O framework and DC application. For example, in the IndirectGUIAspect, the abstract method, toURI, is called by advice to obtain the mapping from a widget to a URI. The policy expert would have no way of knowing how the mapping would be implemented in the DC application; it could be through a hash table, object associations, string manipulations, etc. We don’t believe such a specification language exists which is simpler than a standard programming language. For this reason we believe AspectJ’s model of advice, which provides for arbitrary code to be executed at specified points in program execution, provides the right model for separation of concerns in this context. We performed a case-study on RSSOwl and Lobo, and successfully applied our framework with only moderate effort. The performance cost was found to be negligible, especially for what was gained by the user.
8.
[13]
[14]
[15]
[16]
[17]
REFERENCES
[1] Anonymous. The Lobo Project. http://www.lobobrowser.org/. [2] Anonymous. Sans top-20 2007 security risks. http://www.sans.org/top20/, The SANS Institute, 2007. [3] Anonymous. Java International FAQ. http://java.sun.com/javase/technologies/core/ basic/intl/faq.jsp, 09 2008. [4] A. Charfi and M. Mezini. Using aspects for security engineering of web service compositions. In Proceedings of the IEEE International Conference on Web Services, pages 59–66, Washington, DC, USA, 2005. IEEE Computer Society. [5] R. Elz and R. Bush. Clarifications to the DNS Specification. http://www.ietf.org/rfc/rfc2181.txt, 07 1997. [6] S. Gao, Y. Deng, H. Yu, X. He, K. Beznosov, and K. Cooper. Applying Aspect-Orientation in Designing Security Systems: A Case Study. In The Sixteenth International Conference on Software Engineering and Knowledge Engineering, 2004. [7] C. B. Haley, R. C. Laney, and B. Nuseibeh. Deriving security requirements from crosscutting threat descriptions. In Proceedings of the 3rd international conference on Aspect-oriented software development, pages 112–121, New York, NY, USA, 2004. ACM. [8] C. Hawblitzel, C.-C. Chang, G. Czajkowski, D. Hu, and T. von Eicken. Implementing Multiple Protection Domains in Java. In Proceedings of the 1998 USENIX Annual Technical Conference, 1998. [9] M. Huang, C. Wang, and L. Zhang. Toward a Reusable and Generic Security Aspect Library. In AOSD Technology for Application-Level Security Workshop, 2004. [10] A. H. Karp. POLA Today Keeps the Virus at Bay. Technical Report HPL-2003-191, HP Laboratories Palo Alto, 2003. [11] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold. An Overview of AspectJ. In Proceedings of the 15th European Conference on Object-Oriented Programming, 2001. [12] L. Koved, M. Pistoia, and A. Kershenbaum. Access
[18] [19]
[20]
[21]
[22]
[23] [24]
[25]
[26]
[27]
[28]
266
rights analysis for Java. In Proceedings of the 17th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, 2002. L. C. Lam and T. cker Chiueh. A general dynamic information flow tracking framework for security applications. In Proceedings of the 22nd Annual Computer Security Applications Conference, 2006. A. Mettler and D. Wagner. The Joe-E Language Specification (draft). University of California, June 2006. M. S. Miller and J. S. Shapiro. Paradigm Regained: Abstraction Mechanisms for Access Control. In Asian Computing Conference, 2003. A. Mourad, M.-A. Laverdi´ere, and M. Debbabi. A High-level Aspect-oriented-based Framework for Software Security Hardening. Information Security Journal: A Global Perspective, 17(2):56–74, 2008. K. Padayachee and J. Eloff. Innovations and Advanced Techniques in Computer and Information Sciences and Engineering, chapter An Aspect-Oriented Model to Monitor Misuse, pages 273–278. Springer Netherlands, 09 2007. B. Pasero. RSSOwl. http://www.rssowl.org/. N. Provos, M. Friedl, and P. Honeyman. Preventing privilege escalation. In Proceedings of the 12th conference on USENIX Security Symposium, 2003. A. Prunicki and T. Elrad. Aclamate: An aosd security framework for access control. In Proceedings of the 2nd IEEE International Symposium on Dependable, Autonomic and Secure Computing, pages 293–300, Washington, DC, USA, 2006. IEEE Computer Society. J. H. Saltzer and M. D. Schroeder. The Protection of Information in Computer Systems. In Communications of the ACM, volume 17, 7, 1974. M. Stiegler, A. H. Karp, K.-P. Yee, and M. S. Miller. Polaris: Virus Safe Computing for Windows XP. Technical Report HP:-2004-221, HP Laboratories Palo Alto, 2004. D. Wagner. Object Capabilities for Security. Invited Talk, PLAS 2006, June 2006. R. J. Walker and K. Viggers. Implementing protocols via declarative event patterns. In SIGSOFT FSE, pages 159–169, 2004. B. D. Win, V. Shah, W. Joosen, and R. Bodkin. Report of the AOSD2004 workshop on AOSD technology for application-level security. Technical report, Department of Computer Science, K.U.Leuven, Leuven, Belgium, 2005. B. D. Win, B. Vanhaute, and B. D. Decker. Security Through Aspect-Oriented Programming. In Network Security, 2001. K. Yee. User Interaction Design for Secure Systems. In International Conference on Information and Computer Security, 2002. Z. J. Zhu and M. Zulkernine. Towards an Aspect-Oriented Intrusion Detection Framework. In COMPSAC ’07: Proceedings of the 31st Annual International Computer Software and Applications Conference - Vol. 1, pages 637–638. IEEE Computer Society, 2007.
