Z. Cliffe Schreuders

Empowering End Users to Confine Their Own Applications: The Results of a Usability Study Comparing SELinux, AppArmor, and FBAC-LSM

Protecting end users from security threats is an extremely difficult, but increasingly critical, problem. Traditional security models that focused on separating users from each other have proven ineffective in an environment of widespread software vulnerabilities and rampant malware. However, alternative approaches that provide more finely grained security generally require greater expertise than typical end users can reasonably be expected to have, and consequently have had limited success. The functionality-based application confinement (FBAC) model is designed to allow end users with limited expertise to assign applications hierarchical and parameterised policy abstractions based upon the functionalities each program is intended to perform. To validate the feasibility of this approach and assess the usability of existing mechanisms, a usability study was conducted comparing an implementation of the FBAC model with the widely used Linux-based SELinux and AppArmor security schemes. The results showed that the functionality-based mechanism enabled end users to effectively control the privileges of their applications with far greater success than widely used alternatives. In particular, policies created using FBAC were more likely to be enforced and exhibited significantly lower risk exposure, while not interfering with the ability of the application to perform its intended task. In addition to the success of the functionality-based approach, the usability study also highlighted a number of limitations and problems with existing mechanisms. These results indicate that a functionality-based approach has significant potential in terms of enabling end users with limited expertise to defend themselves against insecure and malicious software.

Techniques for Automating Policy Specification for Application-oriented Access Controls

By managing the authority assigned to each application, rule-based application-oriented access controls can significantly mitigate the threats posed by malicious code due to software vulnerabilities or malware. However, these policies are typically complex and difficult to develop. Learning modes can ease specification, however, they still require high levels of expertise to utilise correctly, and are most suited to confining non-malicious software. This paper presents a novel approach to automating policy specification for rule-based application-oriented access controls. The functionality-based application confinement (FBAC) model provides reusable parameterised abstractions. A number of straightforward yet effective techniques are presented that use these functionality-based abstractions to create application policies a priori, that is, without running programs before policies are specified. These techniques automate the specification of policy details by analysing program dependencies, program management information, and file system contents.

A Policy Language for Abstraction and Automation in Application-Oriented Access Controls: The Functionality-Based Application Confinement Policy Language

This paper presents a new policy language, known as functionality-based application confinement policy language (FBAC-PL). FBAC-PL takes a unique approach to expressing application-oriented access control policies. Policies for restricting applications are defined in terms of the features applications provide, by means of parameterised and hierarchical policy abstractions known as functionalities. Policies also include metadata for management and the automation of policy specification. The result is a novel scheme for application confinement policy that reuses, encapsulates and abstracts policy details, and facilitates a priori policy specification: that is, without having to rely solely on learning modes for creating policies to restrict applications. This paper presents the policy language, and illustrates its use with examples. A Linux-based implementation, which uses FBAC-PL, has demonstrated that this approach can overcome policy complexity and usability issues of previous schemes.

The functionality-based application confinement model

This paper presents the functionality-based application confinement (FBAC) access control model. FBAC is an application-oriented access control model, intended to restrict processes to the behaviour that is authorised by end users, administrators, and processes, in order to limit the damage that can be caused by malicious code, due to software vulnerabilities or malware. FBAC is unique in its ability to limit applications to finely grained access control rules based on high-level easy-to-understand reusable policy abstractions, its ability to simultaneously enforce application-oriented security goals of administrators, programs, and end users, its ability to perform dynamic activation and deactivation of logically grouped portions of a process’s authority, its approach to process invocation history and intersection-based privilege propagation, its suitability to policy automation techniques, and in the resulting usability benefits. Central to the model are ‘functionalities’, hierarchical and parameterised policy abstractions, which can represent features that applications provide; ‘confinements’, which can model simultaneous enforcement of multiple sets of policies to enforce a diverse range of types of application restrictions; and ‘applications’, which represent the processes to be confined. The paper defines the model in terms of structure (which is described in five components) and function, and serves as a culmination of our work thus far, reviewing the evaluation of the model that has been conducted to date.

Security implications of running windows software on a Linux system using Wine: a malware analysis study

Linux is considered to be less prone to malware compared to other operating systems, and as a result Linux users rarely run anti-malware. However, many popular software applications released on other platforms cannot run natively on Linux. Wine is a popular compatibility layer for running Windows programs on Linux. The level of security risk that Wine poses to Linux users is largely undocumented. This project was conducted to assess the security implications of using Wine, and to determine if any specific types of malware or malware behavior have a significant effect on the malware being successful in Wine. Dynamic analysis (both automated and manual) was applied to 30 malware samples both in a Windows environment and Linux environment running Wine. Behavior analyzed included file system, registry, and network access, and the spawning of processes, and services. The behavior was compared to determine malware success in Wine. The study results provide evidence that Wine can pose serious security implications when used to run Windows software in a Linux environment. Five samples of Windows malware were run successfully through Wine on a Linux system. No significant relationships were discovered between the success of the malware and its high-level behavior or malware type. However, certain API calls could not be recreated in a Linux environment, and led to failure of malware to execute via Wine. This suggests that particular malware samples that utilize these API calls will never run completely successfully in a Linux environment. As a consequence, the success of some samples can be determined from observing the API calls when run within a Windows environment.

Source Camera Identification Using Non-decimated Wavelet Transform

Source Camera identification of digital images can be performed by matching the sensor pattern noise (SPN) of the images with that of the camera reference signature. This paper presents a non-decimated wavelet based source camera identification method for digital images. The proposed algorithm applies a non-decimated wavelet transform on the input image and split the image into its wavelet sub-bands. The coefficients within the resulting wavelet high frequency sub-bands are filtered to extract the SPN of the image. Cross correlation of the image SPN and the camera reference SPN signature is then used to identify the most likely source device of the image. Experimental results were generated using images of ten cameras to identify the source camera of the images. Results show that the proposed technique generates superior results to that of the state of the art wavelet based source camera identification.