Implementing SELinux as a Linux Security Module

1. Introduction

In March 2001, the National Security Agency (NSA) gave a presentation about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit. SELinux is an implementation of flexible and fine-grained nondiscretionary access controls in the Linux kernel, originally implemented as its own particular kernel patch. The design and implementation of the original SELinux prototype is described in [LoscoccoFreenix2001] and [LoscoccoNSATR2001], both of which can be found at the NSA SELinux web site (http://www.nsa.gov/selinux).

In response to the NSA presentation, Linus Torvalds made a set of remarks that described a security

framework he would be willing to consider for inclusion in the mainstream Linux kernel. He described a general framework that would provide a set of security hooks to control operations on kernel objects and a set of opaque security fields in kernel data structures for maintaining security attributes. This framework could then be used by loadable kernel modules to implement any desired model of security. The Linux Security Modules (LSM) project was started by Immunix to develop such a framework. LSM was a joint development effort by several security projects, including Immunix, SELinux, SGI and Janus, and several individuals, including Greg Kroah-Hartman and James Morris, to develop a Linux kernel patch that implements this framework. The LSM framework is included as part of the Linux 2.6 series. The SELinux implementation was adapted to use the LSM framework rather than its own particular kernel patch. This technical report documents the LSM-based SELinux security module. The report begins by providing an overview of LSM and a review of the SELinux basic concepts. It then provides an overview of how the LSM-based SELinux security module differs from the original SELinux kernel patch. Several aspects of the SELinux security module are then described, including its internal architecture, its initialization code, its support for stacking with other security modules, and its approach for implementing the SELinux API. The remainder of the report is then spent documenting the SELinux hook function implementations, organized into sections for each grouping of LSM hooks. Typically, these hooks are grouped based on the relevant kernel object or kernel subsystem.

2. Acknowledgements

We thank James Morris for his contributions to the SELinux security module and for his independent development of CIPSO/FIPS188 packet labeling for SELinux. We thank the other contributors to the LSM kernel patch for their work, particularly Chris Wright, Greg Kroah-Hartman, James Morris, Serge Hallyn, and Lachlan McIlroy. We also thank the users of SELinux for their feedback on the LSM-based SELinux releases.

3. LSM Overview

This section provides an overview of the Linux Security Modules (LSM) framework. This section contains an edited excerpt from the Documentation/DocBook/lsm.tmpl file in the kernel tree, updated to reflect recent changes made for the Linux 2.6 integration. LSM provides a general kernel framework to support security modules. In particular, the LSM framework is primarily focused on supporting access control modules. By itself, the framework does not provide any additional security; it merely provides the infrastructure to support security modules. The LSM framework also moves most of the capabilities logic into an optional capabilities security module, with the system defaulting to a dummy security module that implements the traditional superuser logic. The LSM framework adds security fields to kernel data structures and inserts calls to hook functions at critical points in the kernel code to manage the security fields and to perform access control. It also adds functions for registering and unregistering security modules. Extended attribute handlers for a new security namespace were added to filesystems to support new file security attributes, and a /proc/pid/attr subdirectory was introduced to provide userspace access to new process security attributes. The LSM security fields are simply void* pointers. For process and program execution security information, security fields were added to struct task_struct and struct linux_binprm. For filesystem security information, a security field was added to struct super_block. For pipe, file, and socket security information, security fields were added to struct inode and struct file. Unix domain sockets may also use a security field added to the struct sock. For System V IPC security information, security fields were added to struct kern_ipc_perm and struct msg_msg. Each LSM hook is a function pointer in a global table, security_ops. This table is a security_operations structure as defined by include/linux/security.h. Detailed documentation for each hook is included in this header file. The hooks are grouped into logical sets based on the kernel object (e.g. task, inode, file, sock, etc) as well as some miscellaneous hooks for system operations. A static inline function is defined for each hook, so that most of the hook calls can easily be compiled away if desired, in which case only the default capabilities logic is included. The global security_ops table is initialized to a set of hook functions provided by a dummy security module that provides traditional superuser logic. A register_security function (in security/security.c) is provided to allow a security module to set security_ops to refer to its own hook functions, and an unregister_security function is provided to revert security_ops to the dummy module hooks. This mechanism is used to set the primary security module, which is responsible for making the final decision for each hook. LSM also provides a simple mechanism for stacking additional security modules with the primary security module. It defines register_security and unregister_security hooks in the security_o

剩余内容已隐藏，支付完成后下载完整资料

实现SELinux作为Linux安全模块

1、 介绍

2001年3月，国家安全局（NSA）在2.5 Linux内核峰会上介绍了安全增强型Linux（SELinux）。 SELinux是Linux内核中灵活且细粒度非分配访问控制的实现，最初实现为其自己的特定内核补丁。原始SELinux原型的设计和实现在[LoscoccoFreenix2001]和[LoscoccoNSATR2001]中有所描述，两者都可以在NSA SELinux网站（http://www.nsa.gov/selinux）上找到。针对国家安全局的演讲，Linus Torvalds发表了一系列描述安全的言论框架他会愿意考虑纳入主流的Linux内核。他描述了一个通用框架，它将提供一组安全钩子来控制内核对象的操作以及内核数据结构中的一组不透明的安全字段，用于维护安全属性。该框架可以由可加载内核模块使用，以实现任何所需的安全模型。 Linux安全模块（LSM）项目由Immunix启动，以开发这样一个框架。 LSM是几个安全项目的共同开发工作，其中包括Immunix，SELinux，SGI和Janus以及包括Greg Kroah-Hartman和James Morris在内的多个人员开发实现此框架的Linux内核补丁。 LSM框架作为Linux 2.6系列的一部分。 SELinux实现被改编为使用LSM框架而不是其自己的特定内核补丁。本技术报告记录了基于LSM的SELinux安全模块。该报告首先提供了LSM的概述和对SELinux基本概念的综述。然后，它提供了基于LSM的SELinux安全模块与原始SELinux内核补丁的不同之处。然后描述SELinux安全模块的几个方面，包括其内部架构，初始化代码，与其他安全模块堆叠的支持及其实现SELinux API的方法。然后，报告的其余部分用于记录SELinux钩子函数实现，并将其组织为每组LSM钩子的部分。通常，这些钩子根据相关的内核对象或内核子系统进行分组。

2、 致谢

我们感谢James Morris对SELinux安全模块的贡献，以及他对SELinux的CIPSO / FIPS188包标签的独立开发。我们感谢LSM内核补丁的其他贡献者的工作，特别是Chris Wright，Greg Kroah-Hartman，James Morris，Serge Hallyn和Lachlan McIlroy。我们还感谢SELinux的用户对基于LSM的SELinux版本的反馈。

3.、 LSM概述

本节提供了Linux安全模块（LSM）框架的概述。本节包含内核树中的Documentation / DocBook / lsm.tmpl文件的编辑摘录，以更新以反映最近对Linux 2.6集成所做的更改。 LSM提供了一个通用的内核框架来支持安全模块。特别地，LSM框架主要侧重于支持访问控制模块。框架本身不提供任何额外的安全性;它只提供支持安全模块的基础设施。 LSM框架还将大部分功能逻辑转移到可选的功能安全模块中，系统默认为实现传统超级用户逻辑的虚拟安全模块。 LSM框架为内核数据结构添加安全性字段，并在内核代码的关键点插入挂钩函数的调用，以管理安全字段和执行访问控制。它还增加了注册和注销安全模块的功能。将新的安全命名空间的扩展属性处理程序添加到文件系统以支持新的文件安全属性，并引入了/ proc / pid / attr子目录，以提供对新进程安全属性的用户空间访问。 LSM安全字段只是void *指针。对于进程和程序执行安全信息，安全域被添加到struct task_struct和struct linux_binprm中。对于文件系统安全信息，将一个安全字段添加到struct super_block。对于管道，文件和套接字安全信息，安全域被添加到struct inode和struct文件中。 Unix域套接字也可以使用添加到struct sock的安全字段。对于System V IPC安全信息，安全域被添加到struct kern_ipc_perm和struct msg_msg。每个LSM钩子是一个全局表中的函数指针security_ops。此表是由include / linux / security.h定义的security_operations结构。此头文件中包含每个挂钩的详细文档。基于内核对象（例如，任务，inode，文件，袜子等）将钩子分组成逻辑集合以及用于系统操作的一些杂项钩子。为每个钩子定义一个静态内联函数，以便如果需要，大多数钩子调用可以轻松地被编译，在这种情况下，只包括默认的功能逻辑。全局的security_ops表被初始化为由提供传统超级用户逻辑的虚拟安全模块提供的一组钩子功能。提供了一个register_security函数（在security / security.c中），以允许安全模块设置security_ops来引用其自己的hook函数，并提供一个unregister_security函数来将security_ops还原到虚拟模块钩子。该机制用于设置主安全模块，负责为每个挂钩做出最终决定。 LSM还提供了一种用于将其他安全模块与主安全模块进行堆叠的简单机制。它在security_operations结构中定义了register_security和unregister_security钩子，并提供了mod_reg_security和mod_unreg_security函数，在执行一些理智检查后调用这些钩子。安全模块可以调用这些功能，以便与其他模块堆叠。然而，如何处理这种堆叠的实际细节推迟到模块，该模块可以以任何方式实现这些挂钩（如果不希望支持堆叠，则始终返回错误）。以这种方式，LSM将组合的问题延伸到模块。虽然LSM钩子是基于内核对象组织的，但所有的钩子都可以被看作是分为两大类：用于管理用于执行访问控制的安全字段和钩子的钩子。第一类钩子的示例包括为具有安全性字段的每个内核数据结构定义的alloc_security和free_security钩子。这些钩子用于分配和释放内核对象的安全结构。第一类钩子还包括在分配后在安全域中设置信息的钩子，例如d_instantiate钩子。该钩子用于设置inode的安全信息，例如当所有必需的对象信息可用时，通过调用getxattr获取属性值。第二类钩子的例子是inode_permission钩子。此钩子在访问inode时会检查权限。尽管LSM最初包含了一个新的安全系统调用，但此调用随后被删除。大多数功能现在可以使用扩展属性支持和/ proc / pid / attr接口来实现，如上所述。

4、 SELinux基本概念

本节提供了SELinux基本概念的概述。有关SELinux的更多背景信息可以在[LoscoccoFreenix2001]中找到。 SELinux基于Flask安全架构，用于灵活的非分配访问控制。该架构以前在Fluke研究操作系统中实现，如[SpencerUsenixSec1999]中所述。 Flask安全架构提供了政策执行代码和策略决策代码之间的清晰分隔。策略决策代码封装在称为安全服务器的操作系统的单独组件中。 Flask安全架构包括访问向量缓存（AVC）组件，其提供从安全服务器获得的访问决策计算的缓存，以最小化SELinux访问控制的性能开销。策略执行代码被集成到操作系统的子系统（例如，进程管理代码，文件系统代码，套接字和联网代码以及IPC代码）中。策略执行代码从安全服务器和AVC获取安全策略决策，并应用这些决定为安全标签分配流程和对象，并根据这些安全标签控制操作。由于不同的安全策略需要不同种类的安全属性，Flask安全体系结构为安全标签提供两种独立于策略的数据类型：安全上下文和安全标识符（SID）。安全上下文是安全标签的字符串表示，而SID是由安全服务器映射到安全上下文的内部句柄。内核SID不会导出到用户空间;内核只将安全上下文返回给用户空间。但是，用户空间策略执行器可能具有由包含在libselinux中的用户空间AVC维护的自己的SID映射。这两个SID和安全上下文由策略执行代码不透明地处理，只能由安全服务器来解释。策略执行代码将SID绑定到活动进程和对象，在需要为新主题或对象计算SID时咨询安全服务器。文件系统代码中的策略执行代码还使用扩展属性将文件安全上下文存储在每个文件系统中。策略执行代码咨询AVC以检查操作的权限，传递一对SID和安全类; AVC根据需要从安全服务器获取访问决定。这对SID被称为源SID和目标SID。通常，源SID是进程的SID，目标SID是另一个进程或对象的SID，但也可以在两个对象之间定义权限，以控制对象之间的关系。安全类标识对象的种类。每个安全类都有一组相关权限，用于控制对该对象的访问。这些权限集由称为访问向量的位图表示。

5、 从原始SELinux内核修补程序的更改

本节总结了原始SELinux内核补丁和基于LSM的SELinux安全模块之间的变化。在高水平上，基于LSM的SELinux安全模块为原始的SELinux内核补丁提供了等效的安全功能。然而，特定控制措施已经发生了一些变化，部分原因是由LSM施加的设计限制，部分原因在于进一步审查了原来的SELinux控件。底层实施也发生了重大变化，同样部分是由于LSM的差异驱动，部分原因是对原始SELinux实施的审查。以下小节总结了按类别分组的更改。

5.1、 一般变更

本小节介绍了原始SELinux内核补丁和基于LSM的SELinux安全模块之间的一般更改。这些更改包括添加新的间接级别，动态分配安全性字段，与功能模块进行堆叠，重新设计SELinux API，并利用现有的Linux功能来检查权限。

5.1.1、 增加新的间接水平

原始的SELinux内核补丁通过使用Flask安全体系结构和接口，提供了策略执行代码和策略决策代码之间的干净分离。策略执行代码在适当的位置直接插入到内核代码中，策略决策代码封装在安全服务器中，并在两个组件之间建立了明确的界面。类似地，用于安全信息的策略无关数据类型直接插入到内核数据结构中，只有安全服务器可以解释这些数据类型。这种分离级别允许在安全服务器中实现许多不同种类的非分配性访问控制策略，而不会对策略实施代码进行任何更改。 LSM内核补丁将内核对象上的钩子函数调用到适当的点的内核代码中，并将内核对象的内核数据结构中插入void *安全性字段。在基于LSM的SELinux安全模块中，策略执行代码在钩子函数中实现，并且使用内核数据结构中的安全字段存储与策略无关的数据类型。在内部，SELinux代码继续使用Flask架构和接口，并且安全服务器保持为模块的单独组件。因此，LSM为SELinux代码和数据引入了一个额外的间接级别。第6节进一步讨论了SELinux安全模块的内部体系结构。

5.1.2、 动态分配安全域

在原来的SELinux内核补丁中，将安全数据的字段直接插入到相应的内核对象中，并分配并释放内核对象。由于LSM在每个内核对象中只插入一个void *安全字段，所以基于LSM的SELinux安全模块必须管理每个内核对象的动态分配的安全性结构，除非它只需要存储单个安全数据字。 SELinux安全模块为内核数据结构的安全域使用动态分配的安全性结构。

5.1.3、 重新设计SELinux API

在原始的SELinux内核补丁中，扩展的系统调用（如execve_secure和stat_secure）通过扩展内部内核函数来选择传递和处理SID参数来实现。最初，在基于LSM的SELinux安全模块中，这些扩展系统调用是使用安全系统调用实现的，并通过当前任务的安全结构中的字段将SID参数传递给和从钩子函数传递。然而，当安全系统调用从LSM中删除时，SELinux API被完全重新设计，以便获得对主线内核的接受。这在第9节进一步讨论。

5.1.4、 利用Linux权限函数

原始的SELinux内核补丁直接插入自己的权限检查整个内核代码，而不是试图利用现有的Linux权限功能，如权限和ipcperms，由于这些功能支持的粗粒度权限，以及需要在许多地方执行权限检查哪里没有Linux检查已经存在。在原始SELinux内核补丁程序中，这种做法的一个显着的例外是将SELinux权限检查插入现有的可执行内核函数，以便SELinux可以对大量现有的调用进行并行检查。相比之下，LSM将钩子调用插入到所有现有的Linux权限函数中，以利用这些功能。在某些情况下，LSM还会在特定操作中插入额外的钩子调用，以提供更细粒度的控制，但在其他情况下，它仅仅依赖于一个存在于

5.2、 程序执行更改

本小节描述了原始的SELinux内核补丁和与程序执行相关的基于LSM的SELinux安全模块之间的一般更改。这些更改包括使用新文件execute_no_trans权限替换进程执行权限，并通过上下文更改execve更改对状态继承的控制。以下对这些变更进行说明。

5.2.1、 文件execute_no_trans权限

在原始的SELinux内核补丁中，文件执行权限控制着启动程序执行的能力，而进程执行权限则控制从可执行映像执行代码的能力。区分是必要的，因为任务的SID可以通过程序执行来改变，所以启动器的SID可能与转换过程的SID不同。但是，当任务的SID正在更改时，进程执行权限与进程入口许可是冗余的，因此只有当任务SID保持不变时，它才有用。此外，由于此权限位于任务SID和程序文件SID之间，因此它正确属于文件类，而不是进程类。因此，在基于LSM的SELinux安全模块中，进程执行权限被替换为新的文件execute_no_trans权限。与原始进程执行权限不同，仅当任务的SID保持不变时，才会检查文件execute_no_trans的权限。进程入口许可也被移动到文件类中以保持一致。文件执行和进程转换权限保持不变。这些检查在第12.1.3节进一步描述。

5.2.2、 国家的继承几个变化

lt;

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[137486]，资料为PDF文档或Word文档，PDF文档可免费转换为Word