SEEdit: SELinux Security Policy Configuration System with Higher Level Language

Security policy for SELinux is usually created by customizing a sample policy called refpolicy. However, describing and verifying security policy configurations is difficult because in refpolicy, there are more than 100,000 lines of configurations, thousands of elements such as permissions, macros and labels. The memory footprint of refpolicy which is around 5MB, is also a problem for resource constrained devices. We propose a security policy configuration system SEEdit which facilitates creating security policy by a higher level language called SPDL and SPDL tools. SPDL reduces the number of permissions by integrated permissions and removes label configurations. SPDL tools generate security policy configurations from access logs and tool user’s knowledge about applications. Experimental results on an embedded system and a PC system show that practical security policies are created by SEEdit, i.e., describing configurations is semiautomated, created security policies are composed of less than 500 lines of configurations, 100 configuration elements, and thememory footprint in the embedded system is less than 500KB

SEEdit: SELinux Security Policy Configuration System with Higher Level Language

Security policy for SELinux is usually created by customizing a sample policy called refpolicy. However, describing and verifying security policy configurations is difficult because in refpolicy, there are more than 100,000 lines of configurations, thousands of elements such as permissions, macros and labels. The memory footprint of refpolicy which is around 5MB, is also a problem for resource constrained devices. We propose a security policy configuration system SEEdit which facilitates creating security policy by a higher level language called SPDL and SPDL tools. SPDL reduces the number of permissions by integrated permissions and removes label configurations. SPDL tools generate security policy configurations from access logs and tool user’s knowledge about applications. Experimental results on an embedded system and a PC system show that practical security policies are created by SEEdit, i.e., describing configurations is semiautomated, created security policies are composed of less than 500 lines of configurations, 100 configuration elements, and thememory footprint in the embedded system is less than 500KB

Beyond SELinux: the Case for Behavior-Based Policy and Trust Languages

Despite the availability of powerful mechanisms for security policy and access control, real-world information security practitioners---both developers and security officers---still find themselves in need of something more. We believe that this is the case because available policy languages do not provide clear and intelligible ways to allow developers to communicate their knowledge and expectations of trustworthy behaviors and actual application requirements to IT administrators. We work to address this policy engineering gap by shifting the focus of policy language design to this communication via behavior-based policies and their motivating scenarios

Functionality-based application confinement: A parameterised and hierarchical approach to policy abstraction for rule-based application-oriented access controls

Access controls are traditionally designed to protect resources from users, and consequently make access decisions based on the identity of the user, treating all processes as if they are acting on behalf of the user that runs them. However, this user-oriented approach is insufficient at protecting against contemporary threats, where security compromises are often due to applications running malicious code, either due to software vulnerabilities or malware. Application-oriented access controls can mitigate this threat by managing the authority of individual applications. Rule-based application-oriented access controls can restrict applications to only allow access to the specific finely-grained resources required for them to carry out their tasks, and thus can significantly limit the damage that can be caused by malicious code. Unfortunately existing application-oriented access controls have policy complexity and usability problems that have limited their use. This thesis proposes a new access control model, known as functionality-based application confinement (FBAC). The FBAC model has a number of unique features designed to overcome problems with previous approaches. Policy abstractions, known as functionalities, are used to assign authority to applications based on the features they provide. Functionalities authorise elaborate sets of finely grained privileges based on high-level security goals, and adapt to the needs of specific applications through parameterisation. FBAC is hierarchical, which enables it to provide layers of abstraction and encapsulation in policy. It also simultaneously enforces the security goals of both users and administrators by providing discretionary and mandatory controls. An LSM-based (Linux security module) prototype implementation, known as FBAC-LSM, was developed as a proof-of-concept and was used to evaluate the new model and associated techniques. The policy requirements of over one hundred applications were analysed, and policy abstractions and application policies were developed. Analysis showed that the FBAC model is capable of representing the privilege needs of applications. The model is also well suited to automaiii tion techniques that can in many cases create complete application policies a priori, that is, without first running the applications. This is an improvement over previous approaches that typically rely on learning modes to generate policies. A usability study was conducted, which showed that compared to two widely-deployed alternatives (SELinux and AppArmor), FBAC-LSM had significantly higher perceived usability and resulted in significantly more protective policies. Qualitative analysis was performed and gave further insight into the issues surrounding the usability of application-oriented access controls, and confirmed the success of the FBAC model

Rootkit Guard (RG) - an architecture for rootkit resistant file-system implementation based on TPM

Recent rootkit-attack mitigation work neglected to address the integrity of the mitigation tool itself. Both detection and prevention arms of current rootkit-attack mitigation solutions can be given credit for the advancement of multiple methodologies for rootkit defense but if the defense system itself is compromised, how is the defense system to be trusted? Another deficiency not addressed is how platform integrity can be preserved without availability of current RIDS or RIPS solutions, which operate only upon the loading of the kernel i.e. without availability of a trusted boot environment. To address these deficiencies, we present our architecture for solving rootkit persistence – Rootkit Guard (RG). RG is a marriage between TrustedGRUB (providing trusted boot), IMA (Integrity Measurement Architecture) (serves as RIDS) and SELinux (serves as RIPS). TPM hardware is utilised to provide total integrity of our platform via storage of the aggregate of the clean snapshot of our platform OS kernel into TPM hardware registers (i.e. the PCR) – of which no software attacks have been demonstrated to date. RG solves rootkit persistence by leveraging on one vital but simple strategy: the mounting of rootkit defense via prevention of the execution of configuration binaries or build initialisation scripts. We adopted the technique of rootkit persistence prevention via thwarting the initialisation of a rootkit’s installation procedure; if the rootkit is successfully installed, proper deployment via thwarting of the rootkit’s configuration is prevented. We had subjected the RG to 8 real world Linux 2.6 rootkits and the RG was successful in solving rootkit persistence in all 8 evaluated rootkits. In terms of performance, the RG introduced a maximum of 11% overhead and an average of 4% overhead, hence permitting deployment in production environments

A Sustainable Approach to Security and Privacy in Health Information Systems

This paper identifies and discusses recent information privacy violations or weaknesses which have been found in national infrastructure systems in Australia, the United Kingdom (UK) and the United States of America (USA), two of which involve departments of health and social services. The feasibility of health information systems (HIS) based upon intrinsically more secure technological architectures than those in general use in today\u27s marketplace is investigated. We propose a viable and sustainable IT solution which addresses the privacy and security concerns at all levels in HIS with a focus on trustworthy access control mechanisms