PERFORCE change 81110 for review
Andrew Reisse
areisse at FreeBSD.org
Thu Jul 28 12:45:53 GMT 2005
http://perforce.freebsd.org/chv.cgi?CH=81110
Change 81110 by areisse at areisse_ibook on 2005/07/28 12:45:10
More updates; still unfinished.
Affected files ...
.. //depot/projects/trustedbsd/sedarwin7/docs/mach-security.txt#4 edit
Differences ...
==== //depot/projects/trustedbsd/sedarwin7/docs/mach-security.txt#4 (text+ko) ====
@@ -12,7 +12,7 @@
operations (sending or receiving) that the task can perform on that port. A port is only
a destination for a message; messages have no "sending" port. As ports
are relatively lightweight, applications often use a port to represent a single higher-level
-object, such as a window or hardware device. Unlike Unix IPC mechanisms, only one
+object, such as a window or hardware device. Unlike many Unix IPC mechanisms, only one
task at a time (possibly the kernel) may hold a "receive right" for a particular port.
Mach messages contain a variable number of elements, each of which may be
@@ -61,7 +61,7 @@
where the message is sent to the port passed as the first argument. When the window server
receives the message, the MiG stub can convert the port into an implementation-specific
-pointer through a translation type. This removes the need for application developers
+pointer through a translation type. MiG removes the need for application developers
to implement wire protocols in many cases.
A set of routines
@@ -92,6 +92,37 @@
therefore need their own controls in the kernel. Controls on Unix objects are provided
by the "original" FreeBSD MAC framework as it was ported to Darwin.
+*** Security Framework
+
+Our implementation is based on a security framework ported to Darwin from the FreeBSD
+MAC Framework. The basic structure is identical to that found on FreeBSD.
+The FreeBSD MAC framework consists of a kernel interface, a user interface,
+a set of policies, and a kernel-to-policy interface. The kernel interface is
+used by other parts of the kernel (e.g. filesystems) to label objects and
+request access control decisions. Labels in the framework are an abstract notion;
+each policy may store a label on any labelled object in whatever format it needs,
+since allocation, use, and deallocation hooks are provided by the framework.
+
+The kernel-to-policy interface is a mechanism for passing a security event to
+one or more security policies, and combining the result read from each policy into
+one that the system will use. When the kernel needs to label an object, the framework
+calls each policy to intialize its label (policies typically manage independant labels),
+then the labels are stored in a single structure to be maintained along with the kernel
+object. The implementation of an access control check is similar: Each policy is called,
+and the least permissive results returned take precedence.
+
+The kernel interface (called by filesystems and other kernel subsystems) uses
+the kernel-to-policy interface to request labels and access control decisions
+from each configured policy. All policies use the same interface, but many
+methods are not required, allowing for easier implementation of simpler
+policies.
+
+The user interface allows a user program to
+change labels, run programs in other domains, request policy decisions,
+or administer the policy. Complex policies may export arbitrary additional
+interfaces to userspace, such as assistance for labelling userspace objects
+or handling login sessions.
+
**** Security Needs
@@ -115,6 +146,7 @@
remaining services are accessed via messaging, and as such can be treated the same
as userspace services for security purposes.
+
//Since multiple kernel objects (port rights or memory) may be transferred via messages,
//a single (subject,object) form of access control check is insufficient.
@@ -127,16 +159,43 @@
label structure instead of a security identifier. A label structure is added
to each port (ipc_port_t) and to each task (task).
The convention of using a port to represent a single object means that labels on
-ports translate well into labels on objects for policy purposes.
+ports translate well into labels on objects for policy purposes. We do not label
+messages.
+
+The policy-agnostic label structure presents implementation challenges over systems
+that assume a particular (often small or at least fixed size) label format. Security
+policies are given control over the memory management of their labels; this means that
+copying a label is a potentially expensive operation compared to copying a security
+identifier. In addition, the security framework is not abstract enough for policies
+to permit the precomputation of security decisions for later use as many common
+policies (type enforcement, MLS, capability models, etc.).
** Subsystem Access Control
-There are two approaches to protecting servers: Permission checks in the
-handlers, or using proxy servers. A permission check embedded in a handler
+We considered three approaches to protecting servers: Permission checks in the
+servers, protecting the port rights alone, or using proxy servers. Each of these
+approaches provide different levels of possible granularity in policies, usually
+accompianied by more work in implementation.
+
+* Checks in Servers
+
+A permission check embedded in a server (message handler)
simply queries the security policy with the message sender's label (or a label on
the message itself), and any service-specific information needed by the policy,
such as server-side object labels, or the name or other identifier of the routine
-being invoked. A proxy server interposes itself between
+being invoked. This approach is provided in our system by the userspace policy query
+calls coupled with labels available in message trailers.
+
+* Protecting Port Rights
+
+Using an additional policy to restrict the transfers of port rights leverages the
+already present capability model, requiring less changes to servers and applications
+that the first approach. Our system supports this approach by enforcing access controls
+on messaging and the transfer of port rights.
+
+* Proxy server
+
+A proxy server interposes itself between
clients and servers, examining the messages and forwarding any messages that
are in compliance with the security policy. The proxy server can
be installed by the bootstrap namespace manager; when a process registers a
@@ -165,19 +224,37 @@
compatible, although they may share much.
-******
+**** Design and Implementation of Security Extensions
-Summary of security events
+*** Summary of security events
Object creation is straightforward: when a task or port is created, the kernel requests a new label
-from the policies, based on the caller and target task labels.
+from the policies, based on the caller and target task labels. All access controls
+currently present in the mach kernel concern messaging itself (and not higher-level
+services built on messaging), and supports both confidentiality and integrity policies.
+The first of these is simply the permission to send a
+message of any contents to a port. That check has at least two possible security goals:
+to prevent information flow (data contained in the message), and to prevent or limit
+access to a service built over messaging (e.g, the message is interpreted as a request
+to perform an operation). The second group of access checks concern the passing
+of port rights (capabilities) from one task to another. This group is further divided,
+in a similar manner as rename and relabel checks in the framework:
+checks for transferring rights anywhere, and checks for holding rights (of any origin).
+Service-specific access checks on messages are also supported by the kernel; currently,
+a policy may use the message ID (as well as subject and object labels) to make a
+security decision. This is an application level check and not actively enforced by the
+kernel; the kernel merely provides the answer given by the policies to the application.
+Our security-enhanced MiG can be used to add this kind of enforcement to applications.
+Kernel servers are unsecured in the current implementation, except for those calls dealing
+with relabelling of tasks and ports. Many of these services can be handled in the same way
+as the userspace servers, with our MiG extensions for generated security checks.
-Extensions to MiG
+*** Extensions to MiG
We have extended MiG in a number of ways to take advantage of a central implementation
-of messaging functionality that is shared by many applications on the system.
+of messaging functionality that is shared by many applications on the system, and the kernel.
The MiG server stub generator is an ideal place to implement embedded permission
checks, as they will be transparent to applications. We provide a new routine
flag "checkaccess", which will cause MiG to include a permission check in the
@@ -193,7 +270,7 @@
For example, the server can use of the sender's label to label new objects, or
perform access control based on the routine's arguments.
-+ MiG Example
+** MiG Example
The routine specification
@@ -230,29 +307,22 @@
occurs in an ordinary Mach system).
-Extensions to FreeBSD MAC Framework
+*** System-Framework Integration
-** Framework overview
-
-The FreeBSD MAC framework consists of a kernel interface, a user interface,
-a set of policies, and a kernel-to-policy interface. The kernel interface is
-used by other parts of the kernel (e.g. filesystems) to label objects and
-request access control decisions. The user interface allows a user program to
-change labels, run programs in other domains, request policy decisions,
-or administer the policy. Complex policies may export arbitrary additional
-interfaces to userspace, such as assistance for labelling userspace objects
-or handling login sessions.
-
-The kernel interface (called by filesystems and other kernel subsystems) uses
-the kernel-to-policy interface to request labels and access control decisions
-from each configured policy. All policies use the same interface, but many
-methods are not required, allowing for easier implementation of simpler
-policies.
+Adding the security framework to a kernel requires that, in addition to the
+policy infrastructure, that calls to the framework's kernel interface (it's
+"entry points") are added where appropriate in the existing system. The calls
+to framework entry points are placed in object creation and deallocation routines,
+to allow the policies to assign security labels to objects. Calls to entry points
+are also placed at appropriate points in kernel feature implementations, such as
+system calls or vnode operations, often alongside Unix security checks.
The additions for the Mach operating system
all follow this model: labelling operations are inserted into object creation
and deallocation routines, and access decision calls are inserted into
-object usage routines.
+object usage routines. More details of the integration follow.
+
+** Label handles
A "label handle" object type was introduced to
make using labels in userspace programs easier, and to provide a mechanism to
@@ -277,20 +347,8 @@
modified after creation (except for task labels where the handle has no other
references).
-Labelling events for tasks and ports are defined.
-Access control checks for message sending and port right transfers (both sending
-and receiving) are defined. All of these checks are based on the model of a
-subject performing an operation on one or more objects. The subject is always
-a task; objects are either tasks, ports, or higher-level services built on ports.
-Note that in userspace all mach kernel objects are accessed via ports.
+** Generic Entry Points
-If requested, the kernel will supply the message sender's task label in a
-mach message trailer (as a label handle). The message recipient can use
-the sender's label in making its own access decisions. For example, the
-bootstrap namespace server can ensure only a privleged process can examine
-the namespace created by a different loginwindow process.
-
-
To allow userspace processes (particularly mach servers) to use the security
policy in the kernel, a new group of entry points and kernel calls
for generic access checks and labelling computations were added.
@@ -310,8 +368,16 @@
of the kernel may use these entry points as well, because of the
greater amount of information available to the policies over POSIX capabilities.
+** Labelling Events
-Changes to Mach Kernel
+Labelling events for tasks and ports are defined.
+Access control checks for message sending and port right transfers (both sending
+and receiving) are defined. All of these checks are based on the model of a
+subject performing an operation on one or more objects. The subject is always
+a task; objects are either tasks, ports, or higher-level services built on ports.
+Note that in userspace all mach kernel objects are accessed via ports.
+
+** Changes to Mach Kernel
Kernel changes made to support the security framework were fairly noninvasive,
only affecting a few of the data structures and a small number of functions.
@@ -333,16 +399,12 @@
system changes the task port label whenever the task label is changed, but allows
the task port label to diverge if desired (and permitted by the policies).
+If requested, the kernel will supply the message sender's task label in a
+mach message trailer (as a label handle). The message recipient can use
+the sender's label in making its own access decisions. For example, the
+bootstrap namespace server can ensure only a privleged process can examine
+the namespace created by a different loginwindow process.
-
-Mach "security" services
-
-A new kernel server was added to handle security-specific requests, such
-as relabelling objects. As with the other user-accessible kernel servers in a
-Mach system, the security server is implemented as a MiG subsystem.
-The security server will also respond to requests for access control decisions,
-and allow the creation of label handles.
-
Security events for messaging
As all interaction with the
@@ -362,6 +424,7 @@
and into the receiving task, security policies have control over later information flows
resulting from port rights in a message.
+Sequence of operations
1. Message sent
2. Check for action of sending (check_port_send)
@@ -383,9 +446,8 @@
a message sequence number. We add the sender's security labels as a possible
trailer field. Unlike the other trailer fields, this is not merely data; a
task must make additional system calls to make use of the label handle,
-and free it when finished. This feature should not cause performance loss,
-as the label handles are only placed in the trailer when requested by the
-recipient. We also provide a trailer with pre-calculated policy decisions
+and free it when finished.
+We also provide a trailer with pre-calculated policy decisions
in a form similar to DTOS with its extended mach_msg trap. This trailer
provides a single access decision (boolean value) for the called routine,
computed by the loaded policies as (subject, port, subsystem, routine).
@@ -416,6 +478,15 @@
automated, still requires rebuilding the affected server from source (Clients do
not need to be rebuilt or otherwise modified).
+* Mach "security" services
+
+A new kernel server was added to handle security-specific requests, such
+as relabelling objects. As with the other user-accessible kernel servers in a
+Mach system, the security server is implemented as a MiG subsystem.
+The security server will also respond to requests for access control decisions,
+and allow the creation of label handles. Documentation on this service can be
+found in osfmk/mach/security.defs of the kernel source.
+
*** Userspace modifications
We have selected mach_init as one system service to augment with the extended
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list