From 105124763b09b774dce892d4d6f61f49cfde26cc Mon Sep 17 00:00:00 2001 From: Robert Watson Date: Sat, 19 Apr 2003 03:32:43 +0000 Subject: [PATCH] Flesh out the kernel architecture section of the MAC Framework bits of the Developer's Handbook some. Needs more work, but now goes into a bit more detail. Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories --- .../books/arch-handbook/mac/chapter.sgml | 145 ++++++++++++++---- .../developers-handbook/mac/chapter.sgml | 145 ++++++++++++++---- 2 files changed, 232 insertions(+), 58 deletions(-) diff --git a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml index 3c1a983b4a..c8d0a50dca 100644 --- a/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml +++ b/en_US.ISO8859-1/books/arch-handbook/mac/chapter.sgml @@ -135,41 +135,128 @@ the compile-time or run-time extension of the kernel access control model. New system policies may be implemented as kernel modules and linked to the kernel; if multiple policy - modules are present, their results will be composed. While the - framework is intended to support a variety of access control - models, its design was derived from the requirements of a set - of specific access control models required for the TrustedBSD - and CBOSS Projects. This includes support for fixed and - floating label Biba integrity policies, the MLS - confidentiality policy, the Type Enforcement rule-based access - control policy, and the ability to support layering of the NSA - FLASK framework above the TrustedBSD MAC framework. This - document describes the rough architecture of the framework, - with the understanding that this is a work-in-progress and may - change substantially as requirements evolve. + modules are present, their results will be composed. The + MAC Framework provides a variety of access control infratructure + services to assist policy writers, including support for + transient and persistent policy-agnostic object security + labels. This support is currently considered experimental. + + Mandatory Access Control (MAC), refers to a set of + access control policies that are mandatorily enforced on + users by the operating system. MAC policies may be contrasted + with Discretionary Access Control (DAC) protections, by which + non-administrative users may (at their discretion) protect + objects. In traditional UNIX systems, DAC protections include + file permissions and access control lists; MAC protections include + process controls preventing inter-user debugging and firewalls. + A variety of MAC policies have been formulated by operating system + designers and security researches, including the Multi-Level + Security (MLS) confidentiality policy, the Biba integrity policy, + Role-Based Access Control (RBAC), and Type Enforcement (TE). Each + model bases decisions on a variety of factors, including user + identity, role, and security clearance, as well as security labels + on objects representing concepts such as data sensitivity and + integrity. Kernel Architecture - The TrustedBSD MAC framework provides the opportunity for - policy modules to be augment system access control decisions. - Policies are permitted the opportunity to restrict the set of - rights available for processes at a variety of relevant points - in the kernel. In addition, they are provided the opportunity - to tag processes and various kernel objects with labels storing - access control information. Policy modules may register - interest in a subset of the total available events or objects, - and are not required to implement events or objects that are not - relevant to the policy. Multiple modules may be loaded at once, - and the results of the modules are composed as necessary to - build an over-all system policy. Policy modules may be - implemented such that they can be loaded on-demand at run-time, - or such that they may only be loaded early in the boot process. - This permits policies requiring pervasive labeling of all - objects to prevent improper use. + The TrustedBSD MAC Framework permits kernel modules to + extend the operating system security policy, as well as + providing infrastructure functionality required by many + access control modules. If multiple policies are + simultaneously loaded, the MAC Framework will usefully (for + some definition of useful) compose the results of the + policies. The MAC Framework contains a number of kernel + elements: + + + Framework management interfaces + Policy registration and management + Extensible security label for kernel + objects + Policy entry point composition + operators + Label management primitives + Entry point API invoked by kernel + services + Entry point API to policy modules + Entry points implementations (policy life cycle, + object life cycle/label management, access control + checks). + Policy-agnostic label-management system + calls + mac_syscall() multiplex + system call + Various security policies implemented as MAC + policy modules + + + Kernel services interact with the MAC Framework in two ways: + they invoke a series of APIs to notify the framework of relevant + events, and they a policy-agnostic label structure in + security-relevent objects. This label structure is maintained by + the MAC Framework via label management entry points, and permits + the Framework to offer a labeling service to policy modules + through relatively uninvasive changes to the kernel subsystem + maintaining the object. For example, label structures have been + added to processes, process credentials, sockets, pipes, vnodes, + mbufs, network interfaces, IP reassembly queues, and a variety + of other security-relevant structures. Kernel services also + invoke the MAC Framework when they perform important security + decisions, permitting policy modules to augment those decisions + based on their own criteria (possibly including data stored in + security labels). + + Security policies are either linked directly into the kernel, + or compiled into loadable kernel modules that may be loaded at + boot, or dynamically using the module loading system calls at + runtime. Policy modules interact with the system through a + set of declared entry points, providing access to a stream of + system events and permitting the policy to influence access + control decisions. Each policy contains a number of elements: + + + Optional configuration parameters for + policy. + Centralized implementation of the policy + logic and parameters. + Optional implementation of policy life cycle + events, such as initialization and destruction. + Optional support for initializing, maintaining, and + destroying labels on selected kernel objects. + Optional support for user process inspection and + modification of labels on selected objects. + Implementation of selected access control + entry points that are of interest to the policy. + Declaration of poicy identity, module entry + points, and policy properties. + + + When more than one policy module is loaded into the kernel + at a time, the results of the policy modules will be composed + by the framework using a composition operator. This operator + is currently hard-coded, and requires that all active policies + must approve a request for it to occur. As policies may + return a variety of error conditions (success, access denied, + object doesn't exist, ...), a precedence operator selects the + resulting error from the set of errors returned by policies. + While it is not guaranteed that the resulting composition will + be useful or secure, we've found that it is for many useful + selections of policies. + + As many interesting access control extensions rely on + security labels on objects, the MAC Framework provides a set + of policy-agnostic label management system calls covering + a variety of user-exposed objects. Common label types + include partition identifiers, sensitivity labels, integrity + labels, compartments, domains, roles, and types. Policy + modules participate in the internalization and externalization + of string-based labels provides by user applications, and can + expose multiple label elements to applications if desired. - + Userland Architecture diff --git a/en_US.ISO8859-1/books/developers-handbook/mac/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/mac/chapter.sgml index 3c1a983b4a..c8d0a50dca 100644 --- a/en_US.ISO8859-1/books/developers-handbook/mac/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/mac/chapter.sgml @@ -135,41 +135,128 @@ the compile-time or run-time extension of the kernel access control model. New system policies may be implemented as kernel modules and linked to the kernel; if multiple policy - modules are present, their results will be composed. While the - framework is intended to support a variety of access control - models, its design was derived from the requirements of a set - of specific access control models required for the TrustedBSD - and CBOSS Projects. This includes support for fixed and - floating label Biba integrity policies, the MLS - confidentiality policy, the Type Enforcement rule-based access - control policy, and the ability to support layering of the NSA - FLASK framework above the TrustedBSD MAC framework. This - document describes the rough architecture of the framework, - with the understanding that this is a work-in-progress and may - change substantially as requirements evolve. + modules are present, their results will be composed. The + MAC Framework provides a variety of access control infratructure + services to assist policy writers, including support for + transient and persistent policy-agnostic object security + labels. This support is currently considered experimental. + + Mandatory Access Control (MAC), refers to a set of + access control policies that are mandatorily enforced on + users by the operating system. MAC policies may be contrasted + with Discretionary Access Control (DAC) protections, by which + non-administrative users may (at their discretion) protect + objects. In traditional UNIX systems, DAC protections include + file permissions and access control lists; MAC protections include + process controls preventing inter-user debugging and firewalls. + A variety of MAC policies have been formulated by operating system + designers and security researches, including the Multi-Level + Security (MLS) confidentiality policy, the Biba integrity policy, + Role-Based Access Control (RBAC), and Type Enforcement (TE). Each + model bases decisions on a variety of factors, including user + identity, role, and security clearance, as well as security labels + on objects representing concepts such as data sensitivity and + integrity. Kernel Architecture - The TrustedBSD MAC framework provides the opportunity for - policy modules to be augment system access control decisions. - Policies are permitted the opportunity to restrict the set of - rights available for processes at a variety of relevant points - in the kernel. In addition, they are provided the opportunity - to tag processes and various kernel objects with labels storing - access control information. Policy modules may register - interest in a subset of the total available events or objects, - and are not required to implement events or objects that are not - relevant to the policy. Multiple modules may be loaded at once, - and the results of the modules are composed as necessary to - build an over-all system policy. Policy modules may be - implemented such that they can be loaded on-demand at run-time, - or such that they may only be loaded early in the boot process. - This permits policies requiring pervasive labeling of all - objects to prevent improper use. + The TrustedBSD MAC Framework permits kernel modules to + extend the operating system security policy, as well as + providing infrastructure functionality required by many + access control modules. If multiple policies are + simultaneously loaded, the MAC Framework will usefully (for + some definition of useful) compose the results of the + policies. The MAC Framework contains a number of kernel + elements: + + + Framework management interfaces + Policy registration and management + Extensible security label for kernel + objects + Policy entry point composition + operators + Label management primitives + Entry point API invoked by kernel + services + Entry point API to policy modules + Entry points implementations (policy life cycle, + object life cycle/label management, access control + checks). + Policy-agnostic label-management system + calls + mac_syscall() multiplex + system call + Various security policies implemented as MAC + policy modules + + + Kernel services interact with the MAC Framework in two ways: + they invoke a series of APIs to notify the framework of relevant + events, and they a policy-agnostic label structure in + security-relevent objects. This label structure is maintained by + the MAC Framework via label management entry points, and permits + the Framework to offer a labeling service to policy modules + through relatively uninvasive changes to the kernel subsystem + maintaining the object. For example, label structures have been + added to processes, process credentials, sockets, pipes, vnodes, + mbufs, network interfaces, IP reassembly queues, and a variety + of other security-relevant structures. Kernel services also + invoke the MAC Framework when they perform important security + decisions, permitting policy modules to augment those decisions + based on their own criteria (possibly including data stored in + security labels). + + Security policies are either linked directly into the kernel, + or compiled into loadable kernel modules that may be loaded at + boot, or dynamically using the module loading system calls at + runtime. Policy modules interact with the system through a + set of declared entry points, providing access to a stream of + system events and permitting the policy to influence access + control decisions. Each policy contains a number of elements: + + + Optional configuration parameters for + policy. + Centralized implementation of the policy + logic and parameters. + Optional implementation of policy life cycle + events, such as initialization and destruction. + Optional support for initializing, maintaining, and + destroying labels on selected kernel objects. + Optional support for user process inspection and + modification of labels on selected objects. + Implementation of selected access control + entry points that are of interest to the policy. + Declaration of poicy identity, module entry + points, and policy properties. + + + When more than one policy module is loaded into the kernel + at a time, the results of the policy modules will be composed + by the framework using a composition operator. This operator + is currently hard-coded, and requires that all active policies + must approve a request for it to occur. As policies may + return a variety of error conditions (success, access denied, + object doesn't exist, ...), a precedence operator selects the + resulting error from the set of errors returned by policies. + While it is not guaranteed that the resulting composition will + be useful or secure, we've found that it is for many useful + selections of policies. + + As many interesting access control extensions rely on + security labels on objects, the MAC Framework provides a set + of policy-agnostic label management system calls covering + a variety of user-exposed objects. Common label types + include partition identifiers, sensitivity labels, integrity + labels, compartments, domains, roles, and types. Policy + modules participate in the internalization and externalization + of string-based labels provides by user applications, and can + expose multiple label elements to applications if desired. - + Userland Architecture