sandbox configuration that will allow it to be executed safely on the host machine. In this way, not only are we able to ensure a high level of security by imposing.
An Extensible Framework for Practical Secure Component Composition in a Ubiquitous Computing Environment David Llewellyn-Jones, Madjid Merabti, Qi Shi, Bob Askwith School of Computing and Mathematical Sciences, Liverpool John Moores University {d.llewellyn-jones, m.merabti, q.shi, r.askwith}@livjm.ac.uk Abstract Establishing the security properties of executable code provides an important challenge for advocates of ubiquitous computing. We provide a framework that utilises component composition techniques in order to establish such properties for a composed application in a ubiquitous environment. The framework accounts for the need to establish the properties of individual components, and draws on composition results in order to establish overall properties for composed applications. The framework utilises XML composition templates to provide extensibility, so that new composition results will further enhance its effectiveness.
1. Introduction One of the greatest advantages brought by computers is their ability to be a ‘universal tool’ that can theoretically be extended infinitely via the installation of new executable code. This has been enhanced by computer networks which provide an ideal medium for the transportation of this code between devices. To this end, many of the most exciting research topics in computer science have embraced the combination of networking with executable code: programmable and active networks [1], mobile agents [2] and distributed computing generally. Another emerging area – that of ubiquitous computing [3, 4] – requires highly fluid data movement, the easy transfer of executables across a network being crucial to its design. Though generally highly useful, the security problems associated with executable mobility are serious and well known. In many ways computers are simply too flexible and it is often desirable to selectively restrict what they are able to do [5]. The ability of a virus to replicate itself across a network is one such example where restrictions on
the transfer of executables are used in order to maintain security and quality of service. Equally the complexity of much software means that it will often behave in a way that is unpredictable or unintended. Thus we have a combined problem of unintentionally dangerous software and intentionally malicious code both causing security issues in a networked environment. When considering programmable networks, mobile agents or ubiquitous computing, these problems become particularly acute, since with flexibility comes power and in these environments that power is gained via the flow of executable code through the system. In a ubiquitous computing environment, a classic example might involve a business user transferring an application from their desktop machine onto a PDA, so that they are able to continue their work on the way to a meeting. Alternatively in a home environment devices may be designed to automatically update their operating software based on newer versions, or the user choosing a task that requires additional software (such as playing a new video format). These are just two examples amongst many possibilities, but in both cases code transportation becomes an enabling device that nonetheless poses serious security questions. Clearly there is a need to bridge this gap between the flexibility and security of such systems. A large body of work exists that looks at particular security properties and much of this also lies in relation to executable code However, for many techniques some of the biggest difficulties in terms of implementation relate to scalability and resource use. For example, one of the most powerful techniques that might be deployed in order to prevent malicious or faulty code from being executed involves analysing the code to establish if it fails any predefined security requirements [6], a technique we call Direct Code Analysis. One of the main reasons that it is difficult to deploy such
Figure 1: Ubiquitous computing security framework techniques universally concerns the high level of resource usage associated with such analysis. This difficulty is exacerbated by a lack of scalability in relation to code size. One solution to this general difficulty proposed in the literature (e.g. by Mantel [7] or Jürjens [8]) is to make greater use of component composition; a process by which larger applications are built from a collection of smaller component pieces. If each piece can be analysed separately, scalability can be maintained. Much of the research relating to component composition has concentrated on establishing properties that will remain applicable across composition; that is, properties that will hold for a combined application of components given the assumption that the property holds for each of the individual components. Examples include noninterference and separability [9], Persistent_BNDC [10], noninference, forward correctability and nondeducibility on outputs [7], and others. However in spite of this existing body of work, little progress has been made in actually applying the techniques into any form of practical integrated framework. We address this issue in a novel way by presenting such a practical implementation. We go beyond the specifics of individual composition results and provide a generalised framework in which these diverse results can actually be applied. In doing so our overall aim has been to provide an extensible framework in order to allow component composition techniques to be used to address security issues in relation to execution of arbitrary code. We especially expect such a framework to have applicable value in a ubiquitous computing environment. This paper is organised as follows. The next section describes the proposed framework. Section 3 discusses
a generalised method intended to match composition properties with composition patterns. We conclude and make recommendations in section 4.
2. Proposed security framework The implementation of a framework aimed at reducing the security risks associated with executing arbitrary code will inevitably need to draw upon a variety of different techniques. Although we wish to concentrate on the component composition aspects of the framework, we cannot do this in isolation and so give a brief outline of the other techniques that will also be used. For an overview of these techniques see Rubin and Geer [11]. The framework accepts executables and special ‘extended executables’ containing additional properties that apply to the executable code. A two stage process is then undertaken which is depicted diagrammatically in figure 1. At the first stage, individual components are analysed in order to establish the properties of the executable code. We make use of a simple assembled bytecode (that we are able to execute using a virtual machine) intended for use purely within the framework. Unlike the case with Java bytecode [12], this is not intended as a security measure, but to allow easier analysis, and to ensure we produce a relatively generic framework transferable to other execution environments. During this first stage the code is analysed using a number of established techniques with the intention of discovering the security properties applicable to it. Specifically we establish properties through trust using certificates [11], Proof Carrying Code [13, 14] and Direct Code Analysis.
Binary tree Defined to be any property A particular property
Figure 2: XML template for a binary tree the second (not faulty) will indicate that safe array The extended executable structure is utilised to bounds are maintained for the code. provide the additional data required for signed Referring again to figure 1, we see that this properties and property proofs. However we stress that collection of properties is then analysed as a combined although desirable for minimising resource usage, these unit. In the situation presented, the result should be that extensions are not required in order to allow code the execution wrapper is directed to execute the faulty execution. Hence ‘plain vanilla’ executables are component using run-time array bound checking, whilst acceptable to the framework with properties discovered the conformant component is executed without. In this through Direct Code Analysis techniques. way, the overall security of the combined application is Although the issues relating to Direct Code maintained without the overhead associated with array Analyses are interesting in themselves, our present bound checks for the safe piece of the code. focus relates to the second stage of the framework that In terms of component composition this example is takes place once properties are known for a particular simplistic, but it nonetheless demonstrates the process executable. embodied by the framework. We premise a situation in which a number of Our main focus, which we have yet to describe, is individual components are to be combined in order to the component composition process. We will consider execute a larger application. Each of the components is this in the next section. analysed to establish its properties, as already described, and these details are passed to a data processor charged with establishing the properties of 3. Component composition the composed application. The aim is to use the properties of the composed application to establish a As already discussed, the second stage of the sandbox configuration that will allow it to be executed process as depicted in figure 1 is primarily concerned safely on the host machine. In this way, not only are we with component composition and the use of this to able to ensure a high level of security by imposing ultimately dictate the sandboxing methods used during sandbox restrictions on the executable, but we also the execution of an application. We gave an example maintain the maximum power of those applications by situation where one component suffered from potential invoking only the minimal restrictions necessary to buffer overruns whereas a second maintained safe array provide that security. bounds. The system currently being developed will in A simple example may elucidate the process more general be able to utilise much finer grain and intricate fully: consider an application to be composed from two component composition techniques, such as those components, one of which suffers from potential buffer described by Shi and Zhang [15]. To achieve this we overruns, the other of which has no such fault. The two use an XML application to associate sandboxing components are transferred over the network to the techniques with composition patterns. In this context a framework and each undergoes the first stage of composition pattern relates to the topological structure analysis. The executables may have extensions or may of a set of components linked by inputs and outputs, simply consist of the code itself, but on completion of combined with the properties of those components. We this stage the code will have extensions that indicate are primarily interested in security properties. their properties. For the first (faulty) executable these These patterns amount to the graphs resulting from extensions will signify potential buffer overruns, whilst the input and output links between component
1
2
4
3
5
Figure 3: Testing the binary tree template interfaces. We will now describe the XML format in greater detail. For the case cited from Shi and Zhang [15] the technique must match with a strict component hierarchy. We use a similar example – that of a binary tree – to demonstrate how a template can be constructed using the XML format for a component composition pattern. We believe the format to be both simple and powerful, allowing a wide variety of graphs to be matched (a fact that will be justified later). In its simplest form this includes distinguishing cycles and restrictions on the number and properties of ancestor and predecessors of a node in the component composition pattern. Figure 2 shows the XML file for a binary tree for which all inputs and outputs must satisfy the property that we represent as ‘id1’. Toward the start of the file we find a ‘sandbox’ element. These relate to the processes used by the execution wrapper in order to contain security vulnerabilities. Each such element contains a ‘config’ attribute that is used to establish what component configurations require the use of this technique. The attribute contains a list of IDs that relate to ‘configuration’ attributes constructed later in the document. In figure 2 we can see that the sandbox technique with ID ‘s2’ will apply if a component satisfies the configuration with ID ‘c3’ shown later in the document. A configuration consists of a collection of properties linked together to form a graph. Any composition of components can be tested against this graph to discover, given the properties of the components, whether the patterns match. In figure 3 we present a graph matching the configuration ‘c3’ from figure 2. The configuration patterns are determined as follows. Within the configuration we find a number of
nested ‘component’ elements. In the example there are two levels of nesting, but further nesting may apply for alternative configurations. This nesting forms part of the syntax, since at any given level of XML nesting, elements must be satisfied in a disjunctive manner. At the innermost level of the example file we see that there are two ‘output’ elements. Only one of these must be satisfied for the pattern to match. By contrast, the depth of the XML nesting represents the vertical hierarchy of the component tree to be satisfied. Since we are interested in properties that apply to inputs and outputs of components, the language has been designed so that links are defined in a number of ways:Within each ‘component’ we find ‘input’ and ‘output’ elements that must be satisfied for the pattern to match. Every ‘input’ and ‘output’ element contains a ‘format’ attribute. These describe the number of input and output links of the component (respectively), and the properties that these links must satisfy. The ‘cycle’ attribute dictates whether it is acceptable for a link to return to a previously visited component and hence form a cycle. Cycles can be required, disallowed or left unspecified. In order to allow for larger or repeating patterns of components we can insert recursive loops or jumps into the XML code by utilising the ‘config’ attribute. In the case of the example, we can see there is a line
specifying a loop to the element with id ‘c4’. In other words, any component attached to a link satisfying this output requirement must also satisfy the requirements imposed by the component element with the ID ‘c4’. We will briefly describe the elements in the example file, with reference to the diagram in figure 3. The first ‘component’ element has an ID tag specifying that it is ‘c4’. This will be used to refer back to this component later in the file. Inside component c4 there is a single ‘input’ element with empty ‘format’ attribute. This is to signify that the first (root) element of the binary tree has no inputs and corresponds to the component marked ‘1’ in figure 3. Following this is the unique ‘output’ element for this component. Here the output format is specified as “id1 id1” dictating that there must be two outputs from the root element, both of which must satisfy the property termed ‘id1’. Nested into the root element is a further component. As can be seen from the unique ‘input’ element for this component, it may have only a single input that is required to satisfy property ‘id1’. However, there are now two ‘output’ elements. If either of these is satisfied
then the pattern will be satisfied. The first tells us that the component may have two outputs both satisfying the property ‘id1’. The ‘config’ attribute within this ‘output’ element tells us that the components attached to these outputs must satisfy a ‘component’ element within our original component with id ‘c4’. This allows the pattern to loop, ensuring that there is no bound to the height of tree that may satisfy the template. The component marked ‘2’ in figure 3 satisfies these requirements. The second ‘output’ element here has an empty ‘format’ attribute. This ensures the tree can have leaf nodes that have no outputs. The components marked ‘3’, ‘4’ and ‘5’ in figure 3 represent examples of this. This specifies the binary tree in its entirety. Figure 3 shows the result of applying this XML composition template to the tree pictured in the figure. As we can see, as a binary tree it does indeed satisfy the template. Even in this limited form the template format is able to describe a wide variety of different composition trees in a generalised manner. To ensure the maximum flexibility, three further attributes and a single ‘process’ element can be used in addition to those described in the example above. Space limitations prevent us providing a full description of these, but an example of how they may be used is shown in figure 4. With these additional features it is possible to show that the format provides a Turing complete language for describing the composition patterns. As such we achieve the maximum possible flexibility for matching sandboxing methods with composition structures. As a demonstration, the XML document in figure 4 will be satisfied by any “string” of components connected in
series, as long as the length of the string is prime. It is necessary to point out, however, that this flexibility currently only applies in the vertical direction; the format does not allow for an unspecified number of outputs from a single component. A method for establishing composition patterns is of course only the start of the process. Although the system described here provides a basis on which to apply more concrete component composition techniques, it does not itself provide any details as to which compositions apply to which sandbox restrictions. This is a potentially wide area of research and many applicable results exist. For example we have already mentioned the work of Shi and Zhang [15], McLean [9], Focardi and Rossi [10], and Mantel [7]. However, in general these results take a common approach that states that a particular property holds for a composed application given that the individual components of the application also satisfy the property individually. This amounts to a situation in which the properties of a composed application are the properties of the least secure components. We take the view of Shi and Zhang [16] that an effective approach to component composition requires greater flexibility in the configurations that are considered. Crucially, they show that it is not necessary for the weakest components to dictate the properties of a composed application. It is this flexibility that we are attempting to address by proposing a generalised method for linking configurations to sandbox methods. Further research is needed in the area of component composition to establish other potential links that may be fruitfully used in this way.
Linear prime
Figure 4: XML template for a unary tree with prime height
4. Conclusion and future work We have described a framework being implemented that draws on a number of techniques with the aim of reducing the security impact posed by the arbitrary execution of potentially malicious or faulty code in a networked environment. We have outlined the need for such a framework, particularly in relation to ubiquitous computing, programmable networks and mobile code, all of which derive power from the fluid movement of executable code across a network. Our main concern has been to highlight the benefits of component composition in such a scenario – especially in relation to components with varying properties – where components individually enhance rather than restrict the properties of the composed application. To this end we described a flexible XML application used by the framework to establish composition templates. Although we have a fully implemented interpretation engine for these composition templates, it remains to integrate this into or test it with any real world system. Further work into composition properties
References [1] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. Wetherall, and G. J. Minden, "A survey of active network research," IEEE-Communications-Magazine, vol. 35(1), pp. 80-6, 1997. [2] M. S. Greenberg and J. C. Byington, "Mobile Agents and Security," IEEE Communications Magazine, pp. 76-85, 1998. [3] M. Weiser, "The computer for the 21st century," Scientific American International Edition, vol. 265(3), pp. 66-75, 1991. [4] G. Banavar and A. Bernstein, "Software infrastructure and design challenges for ubiquitous computing applications," Communications of the ACM, vol. 45(12), pp. 92-6, 2002. [5] W. Cheswick, S. M. Bellovin, W. Ford, and J. Gosling, "How computer security works," Scientific American International Edition, vol. 279(4), pp. 78-81, 1998. [6] J. M. Wing, "A symbiotic relationship between formal methods and security," in Proceedings Computer Security, Dependability, and Assurance: From Needs to Solutions, 7-9 July 1998 & 11-13 November 1998, York, UK & Williamsburg, VA, USA, 1999. [7] H. Mantel, "On the composition of secure systems," in Proceedings 2002 IEEE Symposium on Security and Privacy, 2002. [8] J. Jürjens, "Composability of secrecy," in Information Assurance in Computer Networks. Methods, Models and Architectures for Network Security. International Workshop MMM-ACNS 2001, 21-23 May 2001, St. Petersburg, Russia, 2001.
may be needed to provide the basis for this work and greater “horizontal” flexibility may also be required, especially to address the restriction of unspecified numbers of inputs and outputs. In terms of the overall framework, a number of novel techniques are needed for the application of Direct Code Analysis within the framework. Many of these techniques will form the basis for future work, but we see the most fertile area of future development lying within the composition process. We have already mentioned several theoretical component composition results, and it remains to take such results and integrate them into the framework in a practical way. From this perspective, the framework provides an initial – yet nonetheless indispensable – step on the way towards a truly practical solution.
Acknowledgements This work was made possible by an EPSRC grant (reference GR/S01634/01) under the Programmable Networks initiative. [9] J. McLean, "A general theory of composition for a class of "possibilistic" properties," IEEE Transactions on Software Engineering, vol. 22(1), pp. 53-67, 1996. [10] R. Focardi and S. Rossi, "Information flow security in dynamic contexts," in Proceedings 15th IEEE Computer Security Foundations Workshop. CSFW 15, 2002. [11] A. D. Rubin and J. D. E. Geer, "Mobile Code Security," IEEE Internet Computing, pp. 31-4, 1998. [12] L. Gong, "Secure Java class loading," IEEE Internet Computing, vol. 2(6), pp. 56-61, 1998. [13] G. C. Necula and P. Lee, "Safe kernel extensions without run-time checking," Operating Systems Review, vol. 30, pp. 229-43, 1996. [14] C. Colby, K. Crary, R. Harper, P. Lee, and F. Pfenning, "Automated techniques for provably safe mobile code," Theoretical Computer Science, vol. 290(2), pp. 117599, 2003. [15] Q. Shi and N. Zhang, "An effective model for composition of secure systems," Journal-of-Systemsand-Software, vol. 43(3), pp. 233-44, 1998. [16] Q. Shi and N. Zhang, "A general approach to secure components composition," in Proceedings. IEEE High Assurance Systems Engineering Workshop Cat. No. 96TB100076, 1997. [17] G. C. Necula, "A scalable architecture for ProofCarrying Code," in Functional and Logic Programming. 5th International Symposium, FLOPS 2001. Proceedings Lecture Notes in Computer Science vol. 2024, 2001. [18] C. Colby, P. Lee, G. C. Nedula, F. Blau, M. Plesko, and K. Cline, "A certifying compiler for Java," SIGPLAN Notices, vol. 35(5), pp. 95-107, 2000.
