integrating SELinux into Ubuntu as well as the future plans for policy.

integrating SELinux into Ubuntu as well as the future plans for policy.

-

+

----

=== Policy Access Control and PolicyRep ===

=== Policy Access Control and PolicyRep ===

'''Presenter: Joshua Brindle, Tresys.'''

'''Presenter: Joshua Brindle, Tresys.'''

Line 37:

Line 38:

for other SELinux projects such as policy access control and setools.

for other SELinux projects such as policy access control and setools.

+

----

=== Integrity Measurement Policies ===

=== Integrity Measurement Policies ===

'''Presenters: David Safford and Mimi Zohar, IBM.'''

'''Presenters: David Safford and Mimi Zohar, IBM.'''

Line 53:

Line 55:

integrity measurement policies.

integrity measurement policies.

+

----

=== Alternatives to Comprehensive Least Privilege ===

=== Alternatives to Comprehensive Least Privilege ===

'''Presenter: Karl MacMillan, Tresys.'''

'''Presenter: Karl MacMillan, Tresys.'''

Line 71:

Line 74:

Linux distributions, like Ubuntu, will be examined.

Linux distributions, like Ubuntu, will be examined.

-

+

----

=== Meeting Government Security Requirements With SELinux (L) ===

=== Meeting Government Security Requirements With SELinux (L) ===

'''Presenter: Karl MacMillan, Tresys.'''

'''Presenter: Karl MacMillan, Tresys.'''

Line 84:

Line 87:

standards with Linux and SELinux, and discuss future plans.

standards with Linux and SELinux, and discuss future plans.

+

----

=== State of Labeled NFS Effort ===

=== State of Labeled NFS Effort ===

'''Presenter: Dave Quigley, NSA.'''

'''Presenter: Dave Quigley, NSA.'''

Line 104:

Line 108:

infrastructure can be used in other remote file systems.

infrastructure can be used in other remote file systems.

+

----

=== State of Labeled Networking on SELinux ===

=== State of Labeled Networking on SELinux ===

'''Presenter: Paul Moore, HP.'''

'''Presenter: Paul Moore, HP.'''

Line 119:

Line 124:

preview of upcoming and in-progress development topics.

preview of upcoming and in-progress development topics.

+

----

=== Flask/TE Support for X ===

=== Flask/TE Support for X ===

'''Presenter: Eamon Walsh, NSA.'''

'''Presenter: Eamon Walsh, NSA.'''

Line 127:

Line 133:

WiP report on the Flask support for X. Will cover the progress to date on integrating Flask controls into the X server, progress (or lack thereof?) on upstreaming this support into distros, new refpolicy support for the X object classes and permissions, and preliminary desktop work that has branched off from the X work (cut & paste selection manager). Will also introduce my next task which is introducing Flask controls on the direct rendering interface (DRI) kernel ioctls.

WiP report on the Flask support for X. Will cover the progress to date on integrating Flask controls into the X server, progress (or lack thereof?) on upstreaming this support into distros, new refpolicy support for the X object classes and permissions, and preliminary desktop work that has branched off from the X work (cut & paste selection manager). Will also introduce my next task which is introducing Flask controls on the direct rendering interface (DRI) kernel ioctls.

Abstract:
This talk will cover two related technologies that could have a deep
impact on the SELinux toolchain if incorporated. The first is policy
access control which provides fine grained control over modifications to
the policy. The suitability of the current prototype for various use
cases will be discussed along with future plans.

The second technology is policyrep. Policyrep is a replacement to the
current compiler that is more maintainable and allows language features
to be added with more ease. This talk will cover the the plans for
making policyrep the upstream compiler and the challenges this causes
for other SELinux projects such as policy access control and setools.

Abstract:
The Linux Integrity Module (LIM) Framework provides
a flexible structure similar to LSM, for the
collecting, appraising, and committing of integrity
measurements. One issue is how to define a policy
of what to measure. This talk will quickly overview
LIM, and present a measurement policy implementation
which takes advantage of SELinux labels and supporting
match functions to define fine grained, integrated
integrity measurement policies.

Abstract:
The SELinux policies that have been widely deployed - the original
example policy and the reference policy - have been comprehensive least
privilege policies. While effective, this approach has drawbacks,
particularly in terms of policy size and complexity. The recent surge in
interest in SELinux on embedded platforms (e.g., SELinux support in
Montavista Mobilinux) has made these drawbacks more critical. This talk
will discuss alternative approaches to full least privilege policies
with real-world examples from Tresys' work with embedded vendors and
application developers. The advantages and disadvantages of these
approaches and how they might be more widely applied in traditional
Linux distributions, like Ubuntu, will be examined.

Abstract:
The CLIP project (Certifiable Linux Integration Platform) provides a
platform for secure application development pre-configured to meet
stringent government security standards (e.g., DCID 6/3). This talk will
give an overview of the goals of CLIP, the challenges in meeting these
standards with Linux and SELinux, and discuss future plans.

Abstract:
As the use of SELinux expands in Enterprise environments customers are
requesting the ability to use SELinux with their NFS based network storage.
The labeled-nfs project seeks to extend the NFSv4 protocol to provide a
generic mechanism for conveying process and file MAC security attribute
information for use by security mechanisms employed on the client and
server.

This talk explores the design and implementation for the labeled-nfs
effort. We discuss why certain design decisions were made and what impact
they have on the implementation of NFS in the Linux kernel and NFS userland
infrastructure. Finally we discuss how parts of the labeled-nfs
infrastructure can be used in other remote file systems.

Abstract:
Over the past year the labeled networking functionality in SELinux has
undergone heavy development which has resulted in both new
functionality as well as improvements to existing functionality. This
talk will discuss these changes and their impact on policy developers
and security administrators. This includes a discussion on how to
migrate from the legacy network controls and strategies for deprecating
those older controls in the kernel. If time permits there will be a
preview of upcoming and in-progress development topics.

Abstract:
WiP report on the Flask support for X. Will cover the progress to date on integrating Flask controls into the X server, progress (or lack thereof?) on upstreaming this support into distros, new refpolicy support for the X object classes and permissions, and preliminary desktop work that has branched off from the X work (cut & paste selection manager). Will also introduce my next task which is introducing Flask controls on the direct rendering interface (DRI) kernel ioctls.

Abstract:
The current mcstransd requires a system administrator to configure each translation manually and assumes that
translations are unique. While this approach works in many cases, it fails when there are a large number of
potential translations (e.g. combinations of countries) or multiple names for one category (e.g. 2 or 3 character
country codes). After a brief historical perspective, I will describe how we expanded mcstransd to address these
issues and discuss what works and what problems remain.

Abstract:
The current Linux Security Modules scheme encompasses
both access control and privilege. This creates unnecessary
and sometimes undesired dependencies between the two
schemes. The sanctions project looks to address this
issue by breaking the privilege components out of the
LSM and into its own framework. In this presentation
the goals, design, and progress of the sanctions project
are presented.

Abstract:
I will present the work that I have begun in experimenting with type
inheritance, the approach I took in creating an experimental compiler to
generate the input for checkpolicy, and what I plan to do in the future.
Topics will include: the dream of one kernel language, but multiple
higher level policy languages; why m4 must die; the problem with type
mangling and m4 arguments; and some really simple changes that would be
beneficial to the real policy language.

Abstract:
People in Japan are working SELinux for embedded devices.
Their works include improving performance, reducing size,
integrating SELinux support to BusyBox,
development of policy writing tool,
and application to some devices such as Android.
In the talk, these works are introduced,
then issues are discussed.

Abstract:
The complex configuration of SELinux is often criticized in literature. A number
of tools have been developed to shed light on the enforced policy, access
denials and policy development. However, the majority of these tools still use
SELinux-terms for interaction with the user. Furthermore, many tools are only
marginally raising the level of abstraction so that security configuration is
still a matter of dealing with low-level type enforcement policies.
This work is part of research for a Ph.D. thesis. It aims at making policy
configuration easier by translating application level security requirements to
type enforcement rules. Hence, the goal is to close the semantic gap between
application level security requirements and low level enforcement. For the
realization of these goals methodologies from model-driven development
(especially meta-modelling and code generation) will be used. The ultimate goal
is to abstract from the policy at the OS-level and lift it up to the
application level. This allows security policy developers to create it in terms
of the application instead of OS objects.

We propose a two-step approach for defining a security policy model. In the
first step a domain specific language for the security-relevant aspects of the
application is created. Secondly, objects of the DSL are connected with
low-level security rules, e.g. the application level rule "allow a physician to
read patient records" maps to the low-level permissions of allowing the current
user to enter the application's domain (if its role is "physician_r"), being
able to read the directory the patient record is placed in and eventually read
the patient record file itself.

We claim that this way of policy creation makes it much easier and less prone to
configuration errors. The creator of the policy does not have to think about
files, sockets and libraries. Instead, he is focussing on what he is already
familiar with - the application domain.

In this talk we want to present our two-step approach and exemplify it with a
healthcare use case.

Abstract:
The OpenSolaris Flexable Mandatory Access Control (FMAC) community-based project
applies Flask and Type Enforcement to OpenSolaris. The combination of the
existing Solaris Trusted extensions functionality with FMAC, represents a unique
combination of Mandatory Access Control (MAC) technologies including the use the
Solaris zone virtualization.

A progress report will be presented to share the early work accomplished on the
project including commonality and/or differences between FMAC and the Flask/TE
implementation in Linux. Early design ideas about how FMAC will interact with
Solaris Trusted Extensions and Solaris Zones will also be presented.

Abstract:
The further adoption of Flask and Type Enforcement (TE) may be accelerated by
greater community participation. The discussion will position the OpenSolaris
Flexable Manditory Access Control (FMAC) project as a new addition to the
general Flask/TE community and pose questions about how we can work together to
achieve a higher degree of ubiquity.

Abstract:
Mainly a discussion on writing policy to confine X. What are we trying
to prevent? How do we get the policy to use higher level concepts? I
don't want to deal with XDrawables, I want to deal with cut/paste.

Abstract:
How do I use labeled data to prevent leakage of information?
Change cups to understand type enforcement for labeled printing.
Don't allow printing of PatientRecord_t on printers labeled
reseptionist_printer_t? Allow users of email clients to specify
CompanyConfidential_t and have mailservers understand
companyConfidential_t can not go to PublicEmail_t addresses. Finally
have webservers begin to understand the connection to the point where
it can verify the remote connection is a "VerifiedState" In order to
look at certain types of data. VerifiedState might mean the client
machine is running in enforcingmode, the user is running
doctor_mozilla_t, the connection came over a labeled network, machine
ran some form of TPM check when booted.

We are developing higher level languages for SELinux policy development. Our purpose is to decrease the size of SELinux policy configuration, and increase the ability to analyze an SELinux policy with respect to a high level security goal. The primary concern of the reference policy appears to be to give just enough permissions to each
application, service to enable them to do their job on a standard SELinux system. This makes the current policy
tools a vehicle for providing least privilege enforcement by the SELinux kernel.

We have developed two languages, one at an
intermediate level, and one at a higher level. The intermediate language is called Shrimp. It is slightly higher
level than the existing SELinux reference policy language. It provides type inference and enforcement of module
boundaries for reference policy interfaces. The high level language is called Lobster. It is an object oriented
language that also employs type inference, polymorphism, and function abstractions to provide a much more abstract
view of the security policy. Our goal is to replace the reference policy with a Shrimp or Lobster version of the
reference policy, and then to compile Lobster specifications of application policies into Shrimp. The reference
policy plus the application policy combine to form the system security policy.

Lobster provides a notion of refinement, whereby a highly abstract policy can be refined into progressively more
detailed policies, culminating in a policy at roughly the same level of detail as the current SELinux policy
language. Thus abstract flow policies can be refined down to complete specifications in a way that preserves the
abstract policy.