|
USENIX 2003 Annual Technical Conference, FREENIX Track — Paper
[USENIX Annual Conference '03 Tech Program Index]
| Pp. 285-296 of the Proceedings | |
Submitted to USENIX ATC Conference 2003, FREENIX Track
The TrustedBSD MAC Framework: Extensible Kernel Access Control
for FreeBSD 5.0
Robert Watson
Network Associates Laboratories
Rockville, MD
rwatson@nailabs.com
https://www.nailabs.com/
-
Wayne Morrison
Network Associates Laboratories
Rockville, MD
tewok@tislabs.com
-
Chris Vance
Network Associates Laboratories
Rockville, MD
cvance@nailabs.com
https://www.nailabs.com/
-
Brian Feldman
FreeBSD Project
Rockville, MD
green@FreeBSD.org
Abstract:
We explore the requirements, design, and
implementation of the TrustedBSD MAC Framework.
The TrustedBSD MAC Framework, integrated into FreeBSD 5.0,
provides a flexible framework for kernel access control
extension, permitting extensions to be introduced
more easily, and avoiding the need for direct modification of
distributed kernel sources.
We also consider the performance impact of the Framework on the
FreeBSD 5.0 kernel in several test environments.
Access control extensions have proved a fertile field for operating
system security research over the past twenty years: a variety of
methods have been employed to extend the system access control policy at
great cost to the developers, maintainers, and users of the extended
systems.
Most of approaches to security extension fall short two
vital areas: lack of support by the operating system vendor for
various providers of security extensions on the system, and the
highly redundant implementation of support infrastructure for
security extension providers.
The TrustedBSD MAC Framework included in FreeBSD
5.0 provides a general facility for extending the kernel
access control policy [8][17].
By providing common security infrastructure services, such as
kernel object labeling, and the ability to instrument kernel
access control decisions, the Framework is capable of supporting a
variety of policies implemented by different vendors.
This paper explores the design, implementation and performance of the
MAC Framework, as well as its impact on policy design and the FreeBSD
kernel architecture.
FreeBSD serves two primary markets: it is both a consumer operating system
and a technology source for third party operating systems or high-end
embedded products.
FreeBSD is directly employed as a production server and workstation
operating system on mainstream i386, Alpha, and SPARC64 hardware.
In the high-end embedded market, it is used as the basis for network and
storage appliance devices such as firewalls, network-attached storage,
and VPN devices; it is also used as a technology source for
third party operating system, including Apple's Mac OS X Darwin kernel,
as well as by other operating system vendors.
In these three roles, FreeBSD is deployed in a wide variety of environments,
ranging from electronic cheque processing and point of sale devices to web
cluster deployment, firewall, and routing appliances.
Each of these environments has different security requirements, often
requiring flexibility beyond that provided for by the traditional UNIX
security protections.
Especially in embedded network environments, the requirements can range
from simple operating system hardening to the introduction of mandatory
and fine-grained security policies.
3 Access Control Extension Mechanisms
Security research and development literature is rife with approaches
to achieving operating system access control extension with (and without)
the help of the operating system vendor. Traditional trusted variants
of commercial UNIX operating systems have been written by the vendor in
response to the needs of specific consumers (such as US
DoD) [12][5][9][10].
Typical practice has been to maintain a distinction between the base
OS product and the trusted variant in terms of maintenance, product
identification, and price.
In addition, there are third party vendors who
develop and market trusted operating system extensions, often in
close coordination with the OS vendor[2].
Finally, there is a
broad range of access control research across many operating systems and
performed in many
forms [7] [13] [15]--most
frequently, this work is performed on open source operating systems
due to ready access to operating system source code.
In order to successfully maintain a security extension product for
an operating system, access to the operating system code is typically
required, be it an open source system, or licensed from the closed
source vendor.
Product maintenance raises a number of challenges, not
least the challenge of tracking the operating system vendor's primary
product life cycle, which is frequently incompatible with the
development cycle required for high assurance products.
Many practical
impediments also present themselves: security extensions have their
fingers deep in the heart of the operating system, touching almost
all elements of the kernel source code.
Local security extensions
invariably conflict with vendor-provided security patches, as well as
vendor-provided feature improvements over the OS development cycle.
In addition, security extensions frequently conflict with one another
if deployed in parallel, leading not only to potentially inconsistent
policy behavior, but also possible bypass of protections provided
by one of the policies.
Direct source code modification of the
vendor operating system presents many challenges to security extension
authors.
In the past, research has been performed on
how to most easily extend operating system security policies, including
into system-call interposition technologies such as LOMAC [6],
Generic Software Wrappers [7],
and systrace [], extensible security mechanisms such as the
General Framework for Access Control [1] and
FLASK [15].
Many of these extension technologies, especially these using
system call wrapping techniques, fall down in the face of modern
UNIX operating system kernels which support true kernel and user
process parallelism in SMP environments, and fine-grained threading
of user processes.
Preventing races inherent to system call wrapping
is difficult, and most system call wrapper security technologies are
susceptible to at least one of a class of related vulnerabilities.
Any successful extension technology for contemporary operating systems
must be designed with the notion that SMP and threading are realities,
and must be well-integrated into the kernel locking mechanisms.
Mandatory Access Control (MAC) describes a broad class of access
control policies; in this context ``mandatory'' refers to the
mandatory imposition of the policy on non-administrative users.
Popular mandatory policies including Multi-Level Security (MLS), which
enforces mandatory protections based on administrator-defined
confidentiality labels, Biba integrity, which enforces system and
user data integrity properties, and Type Enforcement, which permits
the administrator to define subject domains, object types, and use a
policy language to control accesses to objects and other system
properties.
Trusted operating systems typically provide two or more mandatory
system policies: almost all provide MLS for user data protection, but
many also make use of the Biba policy to protect the integrity of
the Trusted Code Base (TCB).
The TrustedBSD Project, in seeking to provide access to trusted operating
system features, provides several MAC policies for use with FreeBSD;
the challenges associated with this work include introducing the
services securely, and without substantially impacting the performance
and reliability of FreeBSD installations not taking advantage of these
new features.
The TrustedBSD MAC Framework permits access control policy modules to be
loaded into the FreeBSD kernel, providing a tightly integrated security
extension vehicle.
In order to address the problems identified in
Section 3 there are several high-level
goals for the design:
- Permit dynamic extension of the kernel access control policy.
- Isolate the logic of access control policies from the implementation
of kernel services, permitting the implementations of services to be
more mobile in the face of extensions, and reducing OS life cycle issues
for policy developers.
- Permit multiple policies to be loaded simultaneously with some
useful notion of composition.
- Reduce the redundant infrastructure implementation efforts of policy
writers by providing support for common policy infrastructure requirements.
- Integrate tightly with the kernel locking and threading
mechanisms to provide correctness and high performance in modern kernel
designs.
The MAC Framework is made up of a number of kernel and user-space
elements.
In the kernel, existing kernel services are modified to add data
structure extensions and entry points to the MAC Framework,
centralized management of label storage,
registration and management of security modules, a series of system
calls and sysctls to permit applications to interact with labels and
manage the framework, and a series of access policy modules that may
be compiled into the kernel or loaded via loadable kernel modules.
In user-space, several new C library interfaces provide access to
centralized label configuration via mac.conf, and changes to
the libutil user class and security context management code.
Command line tools permit user manipulation of file and process labels, and
modifications to standard administrative tools manage system
labels.
Figure 1:
High Level Kernel Design
[scale=0.33]20030321-framework-big-picture.eps
|
The MAC Framework addresses a number of needs in access control and
extension implementation:
- Policies are encapsulated in kernel modules, which may be linked into
the kernel, loaded as part of the boot process, or loaded at run-time
in response to environmental requirements.
- Policies are permitted to augment kernel access control decision;
sufficient locks to access important elements of check arguments,
such as object references, are guaranteed to be held.
- The MAC Framework provides a policy-agnostic labeling service permitting
policies to maintain additional meta-data on a variety of system objects.
Well-defined locking semantics are provided for object
labels, and existing locks on kernel objects typically also protect
any labels in the object, permitting atomic checks of both labels and
existing object properties without additional locking overhead.
- Policies may back labels into persistent extended attributes provided
by UFS and UFS2, permitting labels on file system objects to be maintained
while they are not in the in-memory working set.
- When multiple policies are loaded, their access control decisions are
usefully composed, where the definition of ``useful'' is that results
are well-defined, may be reasoned about, and are desirable in the context
of a number of relevant policies.
- Policies may make use of a policy-agnostic label management API to
export access to label data to user processes, as well as permit the
management of those labels.
The MAC Framework enforces policy over a variety of kernel subsystems
and objects, including system configuration interfaces, processes,
the file system, IPC primitives, and the network stack.
In general, two classes of modifications were made to existing kernel
service providers.
First, services are modified to invoke MAC
Framework entry points during object management, over the course
of object life cycles, and when important access control events
occur.
Second, a number of kernel data structures representing security-relevant
objects were modified to include a label structure intended to hold
extensible security information.
Figure 2:
MAC Framework: Integration into Kernel Components
[scale=0.31]20030321-kernelscope.eps
|
MAC Framework entry point invocations are conditionally compiled into
kernel subsystems based on the configuration parameter options MAC.
Several classes of entry points exist, including label management,
event notification, decision functions, and access control checks.
All entry points accept contextual information; typically this includes
a subject process credential and a series of as objects, object label
pointers, and call-specific arguments such as signal numbers or blocking
disposition.
Some entry points, such as access control checks, return error values;
other notification entry points are assumed always to succeed.
Frequently, a set of related entry point invocations will be made
around complex operations: for example, access control checks are
required to create a new object in the file system namespace.
Likewise, when label modifications occur, a two-phase commit is
performed by the Framework to confirm that all policies will
permit the relabel, and then to notify all policies to perform the
actual operation.
Entry points are currently found in the cross-file system VFS code,
device file system, mount/umount code, protocol-independent socket calls,
pipe IPC code, BPF packet sniffing code, IP fragment reassembly,
IP socket send and receive code, network interface transmission and
delivery, credential and process management code (including
debugging, scheduling, signaling, and monitoring interfaces), kernel
environmental variable management, kernel module management,
per-architecture system calls, swap space management, and a variety
of administrative interfaces such as time management, NFS service,
sysctl(), and system accounting.
These entry points permit policies to augment security decisions
in a variety of forms.
While some system hardening models employ existing subject and
object information (UNIX credential data, file permissions, ...)
a number of important mandatory policies require
additional subject and object labeling.
For example, the MLS confidentiality
policy makes decisions based on subject and object sensitivity
labels: subjects are assigned clearances, and objects are assigned
classifications.
When policies require additional labels, the MAC Framework supports them
through a policy-agnostic labeling primitive, which permits policies to
tag kernel objects with information required for policy decision-making.
Figure 3:
MAC Framework: Policy-Agnostic Label Storage
[scale=0.5]20030321-labels.eps
|
The label structure stored in kernel data structures is
maintained by the MAC Framework: based on the life cycle of the
data structure, the Framework provides per-object entry points
for memory initialization, object allocation, and object destruction.
The label structure consists an array of slots, each providing a
union of a void * pointer and a long; slots are allocated
to policies requiring label storage for use in a policy-specific
manner.
Policy writers might choose to store an integer value, allocate
per-label memory, or make use of referenced structures relying
on the initialization and destruction calls to maintain reference
counts.
Initialization calls will often be used for memory allocation, and
in some cases a blocking disposition will be passed as an argument
to the call indicating whether blocking allocation is permitted;
in these cases the initialization call is permitted to return a
memory allocation failure, which will abort the allocation of the
object.
Label storage is currently provided in the following kernel
objects: BPF descriptors, process credentials,
devfs directory entries, network interfaces, IP fragment reassembly
queues (IPQ), sockets, pipes, mbufs, file system mount points, processes,
and vnodes.
A blocking disposition is provided for mbuf, socket, and IPQ
initialization; if a failure occurs during label allocation, the mbuf
and socket allocator code will return a memory exhaustion failure
to the consumer.
Unlike most other kernel objects, memory to hold the mbuf label
is not stored within the mbuf structure itself: instead, it is stored
in an m_tag hung off the mbuf header m_tag chain.
Tags to hold MAC data will be allocated only when policies requiring
MAC labels on mbufs are present in the system.
This permits improved network performance of the MAC Framework in
scenarios where flexible access control is required, but where
mbuf labeling is not.
Additional support for persistent label storage is provided by any file
system supporting extended attributes, including UFS1 and UFS2; while
policies can determine whether and how the attributes are bound
to policy-specific labels, the Framework constructs transactions to
read, write, and cache vnode labels on supporting file systems.
This flexibility supports a wide variety of behaviors required
for many interesting and useful access control policies.
Hardened or trusted systems are frequently shipped with a number of
active (and hence composed) security policies.
For example, many traditional ``trusted'' UNIX systems include the
standard UNIX access control model, local discretionary extensions to
that model (such as ACLs), the Multi-Level Security (MLS) confidentiality
model protecting user data, and the Biba integrity model protecting the
integrity of the Trusted Code Base
(TCB) [3] [4].
Likewise, locally maintained security extensions are frequently
deployed in combination with existing system security policies,
forming cohesive (and ideally stronger) protection.
As the MAC Framework is intended to assist vendors in combining security
components to be deployed in a variety of environments, the MAC Framework
supports the simultaneous loading of several modules.
While it may not be possible to coherently (or even safely) compose
all access control policies, the MAC Framework provides a simple
composition model that has proven useful in existing shipped systems:
rights intersection.
This composition largely maintains and assumes independence between the
active policies, composing their behaviors only for two classes of
operations:
- Access control checks. A precedence operator
composes the results of an access control decision; the practical
impact of this approach is that if any policy denies access to an
object or operation, then the MAC Framework will return an access
denial to the kernel service.
However, the precedence operator also has the effect of sorting
``Object not found'' errors before ``Access denied'' errors,
providing some useful precedence behavior when information flow
policies are present.
- User label requests. Policies are permitted to deny
access to relabel objects even if the label change request pertains
only to label elements maintained by other policies.
This has utility in a number of situations, including in the following
example: the Biba integrity policy may forbid the changing of an
MLS sensitivity label on a high integrity object by a low integrity
subject, since the changing of a label might constitute an information
flow operation from the perspective of the Biba policy.
The same composition model is employed to combine results from the native
UNIX access control model and any models added using the MAC Framework.
Currently, the task of determining whether two policies may be safely
composed is left to the system designer or administrator, a reasonable
requirement for many of the deployed environments of interest.
Policies are typically encapsulated in a kernel module, although they
may also be directly linked to the kernel. Policy modules consist of
several elements (some optional):
- Configuration. Optional configuration parameters for the
policy.
- Policy logic. Optional abstracted and centralized implementation
of the policy's access control logic.
- Labeling. Optional support for initializing, maintaining, and
destroying labels on selected objects.
- Label APIs. Optional support for user process inspection and
modification of labels on selected objects.
- Access control. Implementation of selected access control
events that are of interest to the policy.
- Policy events. Optional implementation of policy initialization
and destruction events.
- Declaration. Declaration of policy module identity, policy
module properties, and registration of relevant policy operations.
The MAC Framework provides support for a number of classes of
security-aware applications, including policy-agnostic or
policy-aware labeling tools, and the login/user context management
context routines.
This is possible due to the policy-agnostic label management library
and system calls, which allow applications to deal with MAC labels and
elements in an abstract manner.
The following functions are available to applications linked against
the C library:
Retrieve the label of current or arbitrary process; set the current
process label. mac_get_pid(), mac_get_proc(),
mac_set_proc().
Get and set file or pipe label by file descriptor. mac_get_fd(), mac_set_fd().
Get and set file label by path; optionally follow symbolic links.
mac_get_file(), mac_set_file(), mac_get_link(),
mac_set_link().
Execute a command and atomically modify the process label.
mac_execve().
Policy-specific system call multiplexor mac_syscall().
Test for the presence of the MAC Framework or a specific policy
mac_is_present().
Convert labels to and from human-readable text mac_from_text(),
mac_to_text().
Allocate storage for a label appropriate to hold the specified label
elements, or for a specific object based on system default label
elements mac_prepare(), mac_prepare_file_label(),
mac_prepare_ifnet_label(), mac_prepare_process_label().
Release storage associated with a label mac_free().
To support atomic change of label with execution events, mac_execve()
provides an extension to the existing execve() system call accepting
a requested target label. This is required to support the
execve_secure() functionality used by the SEBSD port of
FLASK/TE to FreeBSD from SELinux [11].
In addition, a general security policy entry point, mac_security()
is provided so that policies may extend the set of system services
without allocating new system call numbers.
Many labeled access control policies assign user process labels on the
basis of the identity of the user and properties of the user account.
Frequently this is performed in a role-based manner, where a set of
available roles is assigned to a user, and then the user may select
their active role from among the available roles. This assumes the
ability to assign an initial label during the login process or
when acting on behalf of the user, and then the ability to support
constrained modification of the label based on the initial login
configuration. The MAC Framework user process labeling APIs are
sufficiently flexible to support this behavior.
For an initial pass at supporting automatic labeling at login, we
extended the existing BSD login class database. The master.passwd(5)
assigns one class to each user; a class may be shared by many users,
and includes information such as the resource restrictions for the
user, login and accounting properties, etc. We introduced two new
fields:
| Identifier |
Description |
| label |
The text form of the |
| |
label to be assigned to |
| |
user processes as part |
| |
of the context management |
| |
process. |
| ttylabel |
The label to assign to |
| |
the user's tty |
The existing setusercontext(3) interface is extended to support
a new flag LOGIN_SETMAC, indicating that the MAC label should
be set as part of the login process.
This flag is also implied by
the LOGIN_SETALL flag used widely across programs setting
user contexts.
Process labeling tools, described in the next section,
may then be used to update the process label subject to policy constraints.
By instrumenting this one function and its relevant consumers, we were
able to easily modify most key system daemons and applications to
recognize the new process properties, including sendmail(8), cron(8),
login(1), su(8), ftpd(8), inetd(8) and others, making the changes
relatively low impact.
In the future, we may divorce the label selection database from the class
database for the purpose of improved management, but this would not
require changes to the user context API.
As most of the extensions policies of interest are mandatory policies,
many applications that have specific adaptation to the system discretionary
policy do not require changes for MAC.
This occurs because objects created by processes will have labels
automatically determined based on the process label or other process
properties, rather than as application-provided arguments.
The TrustedBSD MAC implementation ships with several tools to permit
users to inspect and maintain labels on objects, including:
| Program |
Description |
| getpmac |
Inspect process MAC labels |
| setpmac |
Set process MAC labels |
| getfmac |
Inspect file MAC labels |
| setfmac |
Set file MAC labels |
| setfsmac |
Set file MAC labels based |
| |
on a specification file |
In addition, the following utilities were also modified to inspect and
set MAC labels:
| Program |
Description |
| ifconfig |
Inspect and set interface |
| |
labels |
| ps |
Inspect process labels |
| ls |
Inspect file labels |
Further extensions could easily be made to applications such as the KDE
file system browser, Konqueror, to display and manage labels on file
system objects.
FreeBSD 5.0 ships with a number of sample policies--many appropriate
for deployment in production systems. These demonstrate some of the
scope of the capabilities of the MAC Framework, ranging from very
simple un-labeled inter-process visibility protections to fully labeled
policy environments such as Type Enforcement.
- mac_biba. Fixed-label hierarchal Biba integrity policy
with compartments: assigns integrity labels to all system subjects
and objects, then enforces an information flow policy based on limiting
read-down and write-up operations.
- mac_bsdextended. File system firewall, maintains an
access control rule list expressed in terms of UNIX credentials,
file owners, and operation masks.
- mac_ifoff. Interface silencing policy, prohibiting
unauthorized output on network interfaces--appropriate for use in
environments where silent monitoring is required.
- mac_lomac. Floating label hierarchal Biba integrity policy
based on the ``Low watermark'' scheme [7]: assigns
integrity labels
to all system subjects and objects, preventing write-up and forcing
a subject downgrade on read-down.
- mac_mls. Fixed-label hierarchal Multi-Level Security
confidentiality policy with compartments: assigns sensitivity labels to
all system subjects and objects, then enforces an information flow
policy based on limiting write-down and read-up operations.
- mac_none. Stub policy providing prototypes for all policy
entry points--a starting point for new policies. Also useful for
raw performance measurements without the cost of labeling and access
control events.
- mac_partition. Simple labeled system partitioning policy,
in which processes are assigned to system partitions and visibility
of processes is limited based on the label of a process.
- mac_portacl. Add access control lists to control explicit
IPv4 and IPv6 socket binding by protocol, port, and uid or gid.
- mac_seeotheruids. Simple system partitioning policy, in
which process visibility is limited based on the UNIX credential of
a process.
- mac_test. Policy to exercise the MAC Framework as well
as test its invariants. Checks to make sure the MAC Framework is
correctly managing the labels on objects, and instrumenting appropriate
access control checks.
- sebsd. Port of the SELinux FLASK and TE implementations
to FreeBSD, providing access to the FLASK security abstractions,
Type Enforcement implementation, and adaptations of a mature system
policy.
A broad scope of policies may be implemented using the MAC Framework;
the Framework is structured so that policy authors may select what
performance, security, and functionality trade-offs they wish to
make in policy design, augmenting the system policy in ways
that reflect local requirements.
This flexibility makes the MAC
Framework a useful tool in a broad variety of environments, reflecting
the variety of deployment scenarios in which FreeBSD is used.
Three important performance goals were kept in mind during the design
and implementation process for the TrustedBSD MAC Framework:
- Minimize performance impact of the MAC Framework on systems
where it is disabled.
- Minimize the overhead of the MAC Framework on systems where
it is enabled and possibly in use.
- Permit policy authors to make performance/security/complexity
trade-offs local to their policy based on the requirements for the
policy.
In this section, we explore some of the issues associated with
performance measurement of the MAC Framework.
The Framework is currently integrated into the FreeBSD 5.0-CURRENT
development branch--as a result, current performance measurements
are used to guide the development process and explore the eventual
impact, rather than representing final performance results.
Substantial effort has not yet been invested in fine-grained
performance tuning, although initial measurements suggest
performance well within the bounds of acceptability.
For each test, we consider several kernel configurations:
- GENERIC: Base-line kernel without MAC support.
- MAC: Kernel compiled with MAC support, but no active
security policies.
- MAC_NONE: One active ``stub'' policy, implementing all
entry points but without additional locking or logic.
- MAC_BSDEXTENDED: One active ``file system firewall''
policy, implementing file system access control entry points
and making use of a locked policy.
- MAC_BIBA: One active mandatory integrity policy,
implementing comprehensive labeling and access control entry points
for all system objects.
The GENERIC kernel permits us to explore baseline performance as
a control for other configurations; MAC tests the overhead to simply
include extensible security support in the system with no policies.
The three sample policies allow us to consider the overhead of
entering a policy module for each entry point (MAC_NONE), the
cost of unlabeled file system protections using a locked
policy (MAC_BSDEXTENDED), and the cost of a fully labeled
system integrity policy touching most aspects of system
operation (MAC_BIBA).
These tests were run on a FreeBSD 5.0-CURRENT system from the
trustedbsd_mac development branch from late March, 2003;
tests were run on a single-processor 800MHz Intel PIII system with 128mb
of memory and ATA 7200rpm 20gb hard disk.
For file system related benchmarking, all writable file systems were
recreated using the same geometry between tests since file system aging
effects are not of interest for these tests; reboots occur between each
test to flush storage-related caches and reset slab allocator and
mbuf allocator state.
All file systems use UFS2 for high performance meta-data storage.
In the buildkernel test, we perform a macro-benchmark focused
on system throughput relying on effective CPU utilization, I/O
performance, and file system meta-data performance.
In this test, a FreeBSD kernel source tree is configured and
built without modules (to reduce the I/O throughput dependency);
time is measured in wall clock duration from start to finish.
Lower execution times are preferred, indicating higher system
throughput in completing the task.
Figure 4:
Time to make buildkernel with various kernel
configurations (lower is better).
[width=5.4in]data/buildkernel.ps
|
The results of this test demonstrate a small but measurable
performance change (0.1%) with MAC support.
A slight relative increase in cost for the BSD/extended policy
may be the result of acquiring a policy lock in order to process
an access control decision; however, there is no statistically
significant difference in performance between the various MAC policies
and the base cost of the MAC Framework; UFS2 provides for high
performance label access for the Biba policy.
The MAC Framework introduces security label structures into a variety
of system data structures; of these, struct mbuf may be the
most performance-sensitive.
The mbuf structure provides for optimized network management,
and has been the subject of substantial prior performance work,
providing optimized packet construction and parsing, copy-on-write
semantics, zero-copy semantics, and fragmentation management.
From the perspective of MAC policy modules, only header mbufs
are of interest, as they represent the header for a network packet
or datagram.
In our first pass implementation, we inserted a struct label
directly into the m_pkthdr data structure; as the
implementation evolved, the m_tag meta-data service became
available on FreeBSD; this service permits chaining of arbitrary
meta-data onto mbuf headers without modification of the
base structure.
In the m_pkthdr approach, all kernels pay a memory overhead
for labeling support, although kernels without options MAC
do not pay the label life cycle costs.
With the m_tag approach, only kernels with options MAC
pay the memory overhead, although we presupposed that there would
be a higher cost for using tags for label storage due to greater
administrative overhead in maintaining lists and allocating storage.
To optimize the m_tag approach, we implemented lazy tag
allocation: tags are only allocated to hold label data when a
policy expresses interest in labeling mbuf headers.
We consider two tests from the netperf suite: UDP_RR
and UDP_STREAM, which respectively test the per-transaction
cost of a Request/Receive RPC, and raw network throughput.
The request/response test measures the throughput of the system
relative to synchronous one-byte packets between a client and
a server, and is intended to measure the performance impact of
a change in terms of number of packets transfered.
The stream test uses a larger packet size and does not
synchronously wait for a response before continuing, generally
measuring the performance impact of a change in terms of data
transferred.
Figure 5:
UDP request/response throughput over loopback with various mbuf
label allocation approaches (higher is better).
[width=5.4in]data/netperf_udp_rr.ps
|
Figure 6:
UDP stream throughput over loopback with various mbuf
label allocation approaches (higher is better).
[width=5.4in]data/netperf_udp_stream_megabits.ps
|
In Figure 5, the performance cost
per-packet is illustrated: the introduction of MAC support produces
a measurable change; depending on the strategy for labeling
mbufs, that change varies substantially.
With inclusion of the label directly in the mbuf header, an 11.5%
performance overhead is accepted for enabling MAC support.
Adding the stub policy increases that cost to 12.2%; adding a
complex labeled policy performing per-label memory allocation,
such as Biba, increases that drop to 14.9% of the GENERIC packet
throughput.
With lazy m_tag labeling, the performance trade-off is changed:
the cost of introducing MAC is 4.8% (substantially less
than using mbuf headers); with a stub policy
implementing mbuf label entry points but not allocating labels,
that cost increases to 8.5% (also less than mbuf headers).
However, performance with a Biba performance is reduced by 17.1%,
showing an increased cost for heavily labeled policies such as
Biba.
The second set of trade-offs best fits the needs of the
TrustedBSD Project: minimize overhead for MAC-disabled systems,
and permit a performance/complexity cost decision by policy
authors.
In Figure 6, a similar pattern
emerges, where-in the introduction of MAC support results in
a 6.1% throughput penalty.
Use of a stub policy increases that cost to 7.7%; Biba
labeling increases the cost to 10.3%.
However, with lazy m_tag labeling, the base cost of MAC
support is reduced to 3.7%; the stub policy increases this
cost to 4.4%, and with Biba to 9.7%.
The proportionally lower performance cost with this test
derives from the reduced relative overhead resulting from
reduced packet counts relative to data transfered.
Again, lazy m_tag allocation better meets our requirements
by permitting better non-MAC performance with a more clear
performance trade-off for complexity.
Unlike the packet count testing, performance for the Biba policy
actually increases with lazy m_tags relative to mbuf headers,
a result that we attribute to differences
in the caching and allocation policies for the UMA Slab Allocator
versus the mbuf allocator in handling memory clearing for new
allocations.
Substantial prior and current work exists relating to kernel access
kernel and extensibility research.
In the area of prior deployed systems, ``Trusted'' variants of
most commercial UNIX platforms exist, including Trusted Solaris,
and Trusted IRIX [14].
In addition, there are a number of third party security extension
products that exist for these systems, including Argus's PitBull
product, which provides a product alternative with many of the
same features [2].
These products largely rely on Multi-Level Security (MLS) [3]
and Biba integrity [4] to provide mandatory data
confidentiality and TCB integrity; earlier TrustedBSD work has focused on
implementing support in FreeBSD for these models using similar
integration
approaches [17][18][19].
TrustedBSD MAC policy modules exist expressing both MLS and Biba
in functionally similar forms.
In the area of access control extensibility, early work included
the Generalized Framework for Access Control (GFAC), which proposes
a separation of policy and enforcement [1]; this model is
implemented in Linux in RSBAC [13].
The FLASK framework provides for similar types of separation of
policy and enforcement, although with higher level labeling
abstraction in the form of a security ID (SID) and a focus on
Linux Security Modules (LSM) provides a set of kernel extension
hooks to facilitate integration of systems such as SELinux without
committing the Linux operating system to a particular model [16].
LSM provides a void pointer for label storage in each supported
kernel object, and has access control notions similar to the
TrustedBSD MAC Framework.
However, the semantics of the hooks
are weaker, and the LSM framework does not provide for policy
composition and persistent labeling, relying on policy modules
to implement these services.
Type Enforcement for policy representation [15][11].
A prototype port of the SELinux FLASK and TE implementations has
been made to layer on top of the TrustedBSD MAC Framework via the
SEBSD policy module.
Future work on the MAC Framework will likely fall into a number of
areas:
- Improve the completeness and expressiveness of the MAC Framework;
increase the number of kernel objects and methods that
are protected by the Framework to permit broader protections.
- Mature the experimental policy modules.
- Continue to adapt and merge the SEBSD policy module to run
properly with FreeBSD: in particular, determine how best to satisfy
the differing requirements of SEBSD and most other policies regarding
process label transitions.
- Continue porting the MAC Framework and its policies to
Darwin and Mac OS X.
The TrustedBSD MAC Framework provides a generalized mechanism by which
the FreeBSD kernel security model can be augmented at run-time.
Along with the framework, we have also implemented a number of
security extension modules that rely solely on the framework to
interface with existing kernel abstractions.
This separation of security extensions from the actual kernel
implementation of services improves the capacity for third party
providers to develop and ship system security extensions by lowering
the cost to develop and maintain the extensions.
Through a simple composition model, it is possible to perform a
limited set of ``useful'' compositions of security extensions.
Preliminary performance measurement illustrates a measurable but
small performance cost for the framework and many policy modules.
the Framework permits policy authors to select complexity and performance
trade-offs based on local requirements, supporting both simple
hardening policies and complex information flow policies.
This research was supported under DARPA/SPAWAR contract
N66001-01-C-8035 (``CBOSS'').
The authors would like also to thank the anonymous reviewers of this
paper, as well as other contributors to the TrustedBSD Project,
including Chris Faulhaber, Ilmar Habibulin, Adam Migus, and
Thomas Moestl.
The authors would also like to thank Angelos Keromytis and Erez
Zadok for their shepherding of this paper.
The TrustedBSD MAC Framework is available under a two-clause BSD license,
making it appropriate for open and closed-source, research, educational
or commercial use without restriction. It is included in FreeBSD 5.0,
as an experimental feature, and will mature over the FreeBSD 5.x
life time. More information may be found at:
https://www.FreeBSD.org/
https://www.TrustedBSD.org/
- 1
-
M. D. Abrams, K. W. Eggers, L. J. L. Padula, and I. M. Olson.
A generalized framework for access control: An informal description.
In Proc. 13th NIST-NCSC National Computer Security
Conference, pages 135-143, 1990.
- 2
-
Argus products overview: Pitbull.
https://www.argussystems.com/product/ overview/pitbull/.
- 3
-
D. E. Bell and L. J. LaPadula.
Secure computer systems: Mathematical foundations and model.
Technical Report M74-244, The MITRE Corp., Bedford MA, May 1973.
- 4
-
K. Biba.
Integrity constraints for secure computer systems, 1977.
- 5
-
N. C. C. I. Board.
Common criteria version 2.1 (ISO IS 15408), 2000.
- 6
-
Fraser.
LOMAC: Low water-mark integrity protection for COTS environments.
In RSP: 21th IEEE Computer Society Symposium on Research in
Security and Privacy, 2000.
- 7
-
T. Fraser, L. Badger, and M. Feldman.
Hardening COTS software with generic software wrappers.
In IEEE Symposium on Security and Privacy, pages 2-16, 1999.
- 8
-
FreeBSD Project.
FreeBSD home page.
https://www.FreeBSD.org/.
- 9
-
N. S. A. Information Systems Security Organization.
Controlled access protection profile version 1.d, October 1999.
- 10
-
N. S. A. Information Systems Security Organization.
Labeled security protection profile version 1.b, October 1999.
- 11
-
P. Loscocco and S. Smalley.
Integrating flexible support for security policies into the Linux
operating system.
Technical report, U.S. National Security Agency (NSA), Oct. 2000.
- 12
-
U. S. D. of Defense.
Trusted Computer System Evaluation Criteria.
Department of Defense, December 1985.
- 13
-
Rule set based access control (RSBAC) for linux.
https://www.rsbac.org/.
- 14
-
SGI.
B1 sample source code.
https://oss.sgi.com/projects/ob1/.
- 15
-
R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau.
The Flask security architecture: System support for diverse
security policies.
In 8th USENIX Security Symposium, pages 123-139, Washington,
D.C., USA, Aug. 1999. USENIX.
- 16
-
G. S. Support.
Linux security modules:.
- 17
-
TrustedBSD Project.
TrustedBSD home page.
https://www.TrustedBSD.org/.
- 18
-
R. Watson.
Introducing supporting infrastructure for trusted operating system
support in FreeBSD.
In BSD Conference, Monterey, CA, USA, October 2000.
- 19
-
R. Watson.
TrustedBSD: Adding Trusted Operating System Features to FreeBSD.
In Proceedings of the USENIX Annual Technical Conference, June
2001.
The TrustedBSD MAC Framework: Extensible Kernel Access Control
for FreeBSD 5.0
This document was generated using the
LaTeX2HTML translator Version 99.2beta8 (1.46)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -debug -show_section_numbers -split 0 -no_navigation trustedbsd-usenix2003freenix.tex
The translation was initiated by Robert Watson on 2003-04-08
Robert Watson
2003-04-08
This paper was originally published in the
Proceedings of the
USENIX Annual Technical Conference (FREENIX Track),
June 9 – 14, 2003,
San Antonio, TX, USA
Last changed: 3 Jun 2003 aw
|
|
|
