2006 SELinux Symposium Abstracts

SELinux Year in Review (invited talk)

Stephen Smalley, National Security Agency

During the past year, SELinux has experienced a rapid evolution in its capabilities and maturity. This talk provides an overview of the major advances and changes in SELinux since the prior symposium, and describes what to expect for SELinux development in the coming year.

Moving FLASK to BSD Systems (invited talk)

Chris Vance, SPARTA, Inc.

By porting the SELinux FLASK components from Linux to FreeBSD, and finally to Darwin, we have shown that by separating policy decision-making logic from the policy enforcement logic, the security of three very different operating systems may be improved by the same core technology. Much like the Linux Security Modules support, FreeBSD and Darwin have available security frameworks that permit pluggable mandatory security policies. Since the majority of FLASK components build and run on BSD systems with very little modifications, only the framework-specific enforcement layer required implementation. We were able to immediately constrain system behavior and focus on improving both the policy rule sets and the BSD frameworks themselves. In this talk, we compare the Linux and BSD security frameworks and describe efforts to support FLASK on the FreeBSD and Darwin operating systems.

Design and Implementation of the SELinux Policy Management Server

Karl MacMillan, Joshua Brindle, Frank Mayer, Dave Caplan, and Jason Tang Tresys Technology

Policy management is an important capability for effectively using and deploying SELinux. There are several challenges to managing the SELinux policy in a production environment, which include properly integrating package management with policy management. It is also important to address the lack of granular security controls for policy updates. In the Policy Management Server we have designed an access control mechanism for policy updates that provides fine-grained access using SELinux's own security enhancements. In this paper we present an overview of the Policy Management Server, including its goals, design, and implementation status.

Towards Automated Authorization Policy Enforcement

Trent Jaeger, Penn State University

Vinod Ganapathy, Somesh Jha University of Wisconsin, Madison

A popular architecture for authorization policy enforcement uses a reference monitor, with calls to the reference monitor (also called hooks) placed at appropriate locations in the source code of the system that needs to be secured. This architecture has been adopted by several enforcement frameworks, including Linux security modules (LSM), where hooks are placed in the Linux kernel. In current practice, reference monitor hooks are placed manually. This approach is tedious, and as prior work has shown in the context of LSM, is prone to security holes. We present a technique for automatic placement of authorization hooks. Our technique uses static program analysis to recover semantic information embedded in the code of the system to be secured (such as the Linux kernel), and in the code of the reference monitor, to determine the set of hooks that must guard each function in the system. We present a prototype tool that uses this technique and report preliminary results on using this tool with the LSM implementation of SELinux, and in creating a security-enhanced version of the X11 server.

SELinux and MLS: Putting the Pieces Together

Chad Hanson, Trusted Computer Solutions

Multi-Level Security (MLS) has been implemented on many different operating systems. We will discuss the reasons and motivations behind the improvements to the MLS model in SELinux that were accepted into the 2.6.12 Linux Kernel. An introduction to SELinux MLS representation, policy creation, and integration is provided to help further the adoption and use of this technology.

Extending SELinux to meet LSPP data import/export requirements

Janak Desai, George Wilson, IBM Corporation
Chad Sellers, Tresys Technology

Common Criteria certification of SELinux at Evaluation Assurance Level 4 against the Labeled Security Protection Profile (LSPP) and Role-Based Access Control Protection Profile (RBACPP) is intended to advance its acceptance and deployment in the federal sector. SELinux already provides a flexible security policy infrastructure upon which systems that conform to hierarchical Multi-level Security (MLS), as required by LSPP, and role-based access control security policies may be built. However, some RBACPP and LSPP requirements in the user data protection category and their effects on usability make support for features such as polyinstantiated directories, multi-context aware cron, and data import/export restrictions based on device security attributes desirable. This paper presents extensions to SELinux to satisfy some of the LSPP data import/export and RBACPP requirements for Common Criteria certification at EAL4, while maintaining a functional and usable system.

MCS - adding MLS features to the targeted policy

Russel Coker, Red Hat

It has become apparent that many people want some of the benefits of MLS but in a way that is easier to use than the full MLS implementation.

MCS (Multi-Category Security) is a change to policy that applies to both strict and targeted policies (it is in strict and targeted in rawhide). It uses the categories of MLS but makes no use of the sensitivity level field (all processes have sensitivity level s0). The initial design of MCS is based around the targeted policy so it has the same initial aims (minimizing the cost of implementation for end-users). However MCS is used in the strict policy as well and provides the same confidentiality benefits for strict as for targeted.

MCS operates in addition to the type enforcement model and is designed to be used primarily for protecting data confidentiality while type enforcement will be used for protecting system integrity. It is an optional feature which is always enabled but will not have an impact on anyone who doesn't choose to use it.

Reference Policy for Security Enhanced Linux

Christopher J. PeBenito, Frank Mayer, Karl MacMillan Tresys Technology

The Reference Policy project is an effort to restructure the NSA example policy for SELinux, which has evolved through many years of community involvement and is the basis for nearly all sample SELinux Policy in use today. The Reference Policy is rigorously structured using modularity, layering, encapsulation, and abstraction, making it simpler to maintain, modify, and use. The goal of this restructuring is to allow greater adaptation and adoption of SELinux while maintaining the knowledge gained through the years of policy evolution, while increasing our ability to validate the security properties of a given SELinux policy.

Dynamic Policy Enforcement in a Network Environment

Brandon Pollet, Matthew Butler, John Hale, University of Tulsa

The challenge of maintaining a secure and usable system in a hostile environment makes self-defending systems an attractive addition to network security. Using the conditional policy extensions in the Security Enhanced Linux (SELinux) policy language, it is now possible to dynamically adjust a SELinux system's security policy based on its environment. The Dynamic Policy Enforcement Agent (DPEA) utilizes the CLIPS expert system and the conditional policy construct to activate and deactivate portions of the SELinux policy based on peer DPEA alerts, SELinux audit logs, and system logs, as well as to alert other hosts on the network of attacks.

SELinux Protected Paths Revisited

Trent Jaeger, Penn State University

We revisit the notion of Internet-scale protected paths based on SELinux control of labeled IPSec security associations. Last year, we discussed the mechanism for integrating IPSec with SELinux security labels, but we did not consider the system goals for using such labels. Toward this end, we revisit early SELinux proposals for what is called a protected path. A protected path is a path that has the same security guarantees as if the two ends are directly connected and mutually authenticated. If a protected path can be constructed over the Internet in a reliable manner, then distributed applications can be as secure as two applications running on the same, isolated environment. A variety of challenges remain in building a protected path system, but interestingly, efforts are underway in most areas, with the notable exception of secure windowing systems. This talk will outline an approach to protected paths in the context of a distributed computing example, what work is underway toward achieving protected paths, and what is required of that work to compose protected paths with SELinux.

Experiences Implementing a Higher-Level Policy Language for SELinux

Chad Sellers, James Athey, Spencer Shimko, Frank Mayer, Karl MacMillan, and Art Wilson Tresys Technology

Expressing security architectures that meet required security goals for a system in SELinux policy language is quite difficult, particularly for those without a strong understanding of SELinux security mechanisms and object class per-missions, and their implications. However, SELinux policy language is an excellent base upon which to build a higher-level policy language that more directly expresses specific security architectures. We have developed one such language, CDS Framework, for implementing security policies focused on information flow applications as typically found in cross-domain solutions. This paper presents the components of this language and describes some of the issues that we faced in implementing the language and its tools.

SENG: An Enhanced Policy Language for SELinux

Paul Kuliniewicz, Purdue University

Most of the statements in the current SELinux policy language operate directly on features of the underlying access control model. Because the policy for a typical Linux system contains a large number of distinct types, a realistic policy will be large and unwieldy. Current practice is to manage this complexity through preprocessor macros, using them to encapsulate portions of the policy and allow for their reuse. However, such macros inhibit the use of tools to analyze the policy, as these macros must first undergo expansion. As a result, the policy being analyzed is not in the same form as the one originally written, complicating the task of using the analysis results to improve the policy.

This paper introduces SENG, an experimental alternative language for writing SELinux policies. SENG builds upon the existing policy language by adding abstractions with well-defined semantics, with the goal of eliminating the need for macros to write a maintainable policy. To facilitate testing and adoption, a compiler has been implemented to transform SENG policies into the existing policy language, allowing SENG to be used without requiring changes to the existing policy framework.

Guided Policy Generation for Application Authors

Brian T. Sniffen, David R. Harris, John D. Ramsdell, The MITRE Corporation

MITRE has developed Polgen, a tool for human-guided semi-automated policy generation. We initially designed Polgen for use by security administrators confronting unfamiliar programs and obliged to integrate them into existing policy. However, SE Linux adoption will come about when application authors can also at least bootstrap the policy generation process. Polgen works by processing traces of the dynamic behavior of a target program. By observing information flow patterns such as Pipeline, Interpreter, or Proxy in that behavior, Polgen creates new types when appropriate and generates policy based on the patterns it has detected. Because the dynamic behavior is insufficient to fully inform security policy, Polgen presents a wizard-style interface for human interaction. We call the interaction ``guided automatic policy generation.'' This paper highlights the needs for type generation support, Polgen's pattern recognition capability, and our future plans for human-guided automation. The primary challenges are the introduction of new types, and the use of the M4 macro language as the primary vehicle for abstraction.

Lopol: A Deductive Database Approach to Policy Analysis and Rewriting

Aleks Kissinger Dr. John Hale, University of Tulsa - Center for Information Security

This paper presents a method for deductive database-driven analysis of security policies on mandatory access control systems such as SELinux.

First, it discusses how directives in a policy can be normalized and encoded as logical relations. Next, the paper describes how to use these relations in conjunction with inference rules to perform a number of simple analyses. The techniques used to detect security characteristics within a policy can then be applied to automated policy rewriting, where those characteristics (i.e. security goals) are actually projected upon to the policy to generate a new one. The paper closes by discussing the use of a logical ruleset as a high-level language, allowing administrators to quickly tailor a large default policy (such as "strict", "targeted", or "refpolicy") to the specific needs of a system.

Attack-based Domain Transition Analysis

Susan Hinrichs, University of Illinois - Urbana-Champaign
Prasad Naldurg, Microsoft Research

SE Linux type enforcement policies are widely understood to be large and difficult for humans to understand. Several groups have created tool sets to aid SE Linux policy writers and maintainers in the task of working with SE Linux policies. We propose an attack-based model to look at the transitive domain transitions allowed in the policy. We have augmented Apol, a graph-based policy analysis tool, to implement global transitive domain translation analysis and more focused reduced transitive domain transition graphs between sets of suspect domains and sensitive domains.

Lessons Learned Developing Cross-Domain Solutions on SELinux

Karl MacMillan, Spencer Shimko, Chad Sellers, Frank Mayer, and Art Wilson Tresys Technology

Building computer systems that allow the controlled transfer of data between security domains, commonly called cross-domain solutions (CDS) or guards, presents many common and some unique security challenges. In this paper, we explore lessons learned from building several CDS systems on SELinux. We explore the desired security proper-ties of a CDS, define the role of the operating system in enforcing these security properties, and describe our experience using SELinux to fulfill the operating system role.