linux selinux_安全Linux：第1部分。SELinux –其开发，架构和操作原理的历史

最新推荐文章于 2024-04-28 02:22:52 发布

cuyi7076

最新推荐文章于 2024-04-28 02:22:52 发布

阅读量343

点赞数

文章标签：网络大数据编程语言数据库 python

原文链接：https://www.ibm.com/developerworks/security/library/l-secure-linux-ru/index.html

版权

linux selinux

SELinux的历史

在美国国家安全局（NSA）内部启动了涉及开发安全增强型Linux®（SELinux）（该系统提供强制访问控制）的项目。安全计算公司（SCC）和MITER公司以及许多研究实验室直接参与了开发。它作为通用访问软件产品（根据GPL许可证分发了源代码）于2000年12月发布。NSA发行了特别的新闻稿来标记这种情况（请参阅参考资料）。到那时，作为几个半研究/半军事项目的一部分，已经花了10年的时间开发，分析和测试SELinux的基本体系结构（请参阅项目概述：DTMach，DTOS，Fluke，Flusk，Flask ）。

项目盛会：DTMach，DTOS，Fluke，Flusk，Flask

在1992年至1993年间，来自NSA和SCC的研究人员致力于创建分布式可信马赫（DTMach）操作系统，该系统结合了TMach和LOCK项目获得的成果。 DTMach结合了通用类型强制，灵活的访问控制机制和Mach微内核。然后，将DTMach项目作为分布式受信任操作系统（DTOS）项目的一部分进行开发。 DTOS项目完成后，NSA，SCC和犹他大学共同努力，将DTOS安全系统的体系结构集成到Fluke Research操作系统中。新项目称为Flux。同时，安全系统的原始体系结构得到了增强，从而可以为动态安全策略提供更好的支持。新的增强架构称为Flask。下一步涉及NSA为Linux OS实现此安全系统体系结构，并以Security-Enhanced Linux的名称向公众公开（请参阅参考资料）。

新的强制性访问控制系统基于检查操作系统对象和主体的安全标签的过程，并且包括许多最新的访问控制技术。这些技术之一是类型强制。最初在称为LOCK（请参阅LOCK ）的经过特殊设计的，受信任的“ A1”级系统中进行了测试，然后在研究操作系统Flask的安全子系统中进行了进一步开发。类型强制的使用特别支持使用SELinux基于角色的访问控制和多级或多类别安全性的实现。

类型强制

类型强制是一种访问控制技术，根据当前的安全上下文或域，授予允许主题（用户，软件过程和流）访问对象（文件，I / O端口等）的权限。

在SELinux中，安全上下文存储在扩展文件系统属性中，并使用Linux安全模块（LSM）进行管理。类型强制是实现强制性访问控制所必需的，它补充了基于角色的访问控制（RBAC），并且是多级安全性（MLS）和多类别安全性（MCS）的第一步。

锁

在SCC上进行的LOCK项目（逻辑协同处理内核）的目的是开发一种提供多级安全性的受信任计算机系统。这意味着系统必须根据“可信计算系统评估标准”（也称为“橙皮书”）满足“ A1”要求。

该项目成功完成，在军事指挥中心建立了几十个系统。类型强制是LOCK技术的主要体系结构特征，可确保访问控制机制的有效实施。

目前正在以下系统中开发与安全性和访问控制（包括类型强制）相关的基本LOCK技术：

Sidewinder Internet防火墙产品线
SELinux

请参阅“ 相关主题”中有关LOCK项目的更多详细信息。

发布时，SELinux作为2.2和2.4内核的更新发行。但是，当有人提出将SELinux是否包含在正式内核中的问题时，Linus Torvalds要求对项目进行修改，以便可以将Linux安全子系统实现为模块，以方便其后续维护或增强。结果，开发人员创建了Linux安全模块子系统，为内核功能提供了安全子系统的接口。该解决方案允许Linux发行版的用户和开发人员从多种强制性的访问控制系统中进行选择：AppArmor，TOMOYO Linux，SMACK和SELinux。

Linux安全模块

Linux安全模块（LSM）是Linux内核子系统，旨在将作为模块实现的各种安全模型集成到内核中。在2001年，NSA在Linux内核峰会上的代表建议在Linux内核版本2.5中包括强制性的控制访问系统Security-Enhanced Linux。但是，Linus Torvalds拒绝了该建议，因为SELinux并不是开发来提高Linux安全性的唯一安全系统。除此之外，并非所有开发人员都同意SELinux是最佳解决方案。创建了Linux安全模块系统，而不是将SELinux直接直接包含在内核中，从而允许将安全子系统用作模块，这意味着连接新模块相对简单。

LSM子系统的开发工作持续了大约三年时间，并且从2.6版开始就包含在Linux内核中。当前正式支持的安全模块是SELinux，Apparmor，Smack和TOMOYO Linux。

在文章中提供了LSM架构的详细说明“Linux安全模块：通用安全支持Linux内核”（见相关信息），在2002年的USENIX安全会议上提出。

SELinux与基于标签控制的强制性访问控制系统有关。这意味着，受SELinux保护的操作系统中的每个对象或主体都必须具有其自己的特殊标签，称为安全上下文。这些标签最初以数字形式存储在ext2文件系统节点的未使用字段中。每个数字标签都在SELinux中映射到了人类可读的基于文本的安全上下文标签。这种方法不可扩展，并且基于特定ext2文件系统的功能，而这被认为是整个解决方案的明显缺点。

在开发的下一阶段，SELinux被实现为模块，可以加载到Linux内核版本2.4中。该模块将标签存储在单独的文件中，这意味着该SELinux实现对所使用的文件系统没有任何限制。但是，消除一个体系结构缺陷导致出现另一个缺陷。对包含安全上下文标签的文件的频繁访问导致生产力急剧下降。

终于在Linux内核2.6版中解决了该问题，并完全支持Linux安全模块以及ext3文件系统中的扩展属性。为了能够存储系统对象和主题的安全上下文标签，SELinux切换为使用扩展属性。不幸的是，这种创新再次导致涉及文件系统使用的限制。 SELinux仅可用于支持扩展属性的文件系统中。但是，随着时间的流逝，这个问题逐渐消失，现在几乎所有常用的文件系统都对扩展属性提供了完全支持，这意味着它们可以与SELinux一起使用。

不久之后，SELinux被集成到Linux内核中，并开始作为2003年8月8日发布的内核2.6.0-test3的子系统首次进行分发以进行测试。在此过程中，还发布了一个内核补丁。用于强制访问控制系统的内核2.2和2.4，而在内核2.4中引入对Linux安全模块的支持导致针对LSM的SELinux版本的发布。

SELinux很快成为受保护的Linux系统中的事实上的标准，并且是Red Hat Enterprise Linux最受欢迎的公司发行版之一（从Red Hat Enterprise Linux 4开始）。此后，SELinux开始在广泛部署的Debian和Fedora OS中使用，并得到了Ubuntu发行版的支持，该发行版越来越流行（来自LTS版本8.04 Hardy Heron）。后来，Novell（当时正在开发AppArmor，并计划将其包含在Linux内核中）开始在其OpenSUSE和SUSE Linux Enterprise发行版中支持SELinux。

最终，所有流行发行版的开发人员都支持增强安全性的Linux。在当前的Linux内核版本2.6中，SELinux使用Linux安全模块进行操作。除此之外，许多SELinux元素已经合并到实际的内核中。

美国国家安全局监督了这种强制性访问控制系统开发的漫长道路。 Red Hat还支持将SELinux集成到Linux内核中的基本工作。在NSA网站上列出了对SELinux的开发做出最大贡献的开发人员的详细列表（请参阅参考资料）。

SELinux体系结构

如上所述，SELinux系统从研究操作系统Flask继承了安全子系统的体系结构。 Flask的主要功能是使用“最低特权”概念向用户或应用程序仅授予执行请求的操作所需的那些访问权限。这个概念是使用类型强制实施的（请参见Type Enforcement ），这要归功于SELinux中的强制访问是域类型模型的一部分。在此模型中，每个流程主题都在定义的安全上下文（域）中启动（也就是说，它具有一定的访问级别），而所有操作系统的资源对象（文件，目录，套接字和其他）都具有某种类型（保密级别）。

由于类型强制，SELinux的访问控制选项大大超过了UNIX®类型系统中使用的基本自由访问控制模型所提供的选项。例如，SELinux可以用来严格限制网络服务器可以访问的网络端口号。它还可以允许创建单个文件并在其中保存数据，但不能删除等。对操作系统对象的这种分级使用明确分配给特定资源的访问权限集，有助于限制系统和用户进程。如果SELinux控制的任何服务遭到破坏，入侵者将无法超越沙箱，沙箱受到规则集的限制，即使具有超级用户权限也是如此。

定义用于允许某些域访问某些类型的权限的规则列表也是一种安全策略。设置系统后，安全策略将被应用一次，并且由一组文本文件组成，这些文件在系统启动期间会加载到Linux内核的内存中。

这些规则是人类可读的形式，即使普通用户也可以理解。例如，在下面显示的http服务器域规则中，授予了读取某些包含网络配置的文件的权限：

allow httpd_t net_conf_t:file { read getattr lock ioctl };

SELinux从Flask安全子系统继承了操作标签的结构和原理，该标签定义了操作系统对象和主题的安全上下文，以及“域类型”模型。为了确保全面保护，必须为系统中的每个对象和每个主题定义安全上下文。标签采用以下形式：

<user>:<role>:<type>

例如，分布式安全上下文的标签采用以下格式： system_u：object_r：httpd_exec_t 。在SELinux中，用户system_u通常是系统守护程序的默认名称。角色object_r被分配给系统对象，例如普通文件或设备。 httpd_exec_t类型应用于位于/ usr / sbin / httpd地址的正在执行的httpd文件。 user ， role和type元素将在下一篇文章中更详细地讨论。

图1.使用SELinux的强制访问控制系统概述

SELinux包含五个基本组件：

用于文件系统操作的辅助模块
与Linux安全模块事件挂钩进行交互的模块
组织访问控制的基本机制
Policy Enforcement Server，一个系统安全策略数据库
访问向量缓存（AVC），一种用于提高生产率的辅助机制

SELinux的操作安排如下：

操作系统主体（进程）尝试对特定对象（文件，进程，套接字）执行特定操作，这是Linux标准自主安全系统（DAC）允许的。这将启动对对象的请求流。
每个对对象执行操作的请求都被Linux安全模块拦截，并与主题和对象的安全上下文一起转移到SELinux抽象和挂钩逻辑子系统，该子系统负责与LSM进行交互。
从SELinux抽象和挂钩逻辑子系统收到的信息将转发到基本的Policy Enforcement Server模块，该模块直接负责做出有关允许主体访问对象的决定。
为了接收有关是否允许操作的决定，策略执行服务器联系特殊的访问向量缓存子系统，该子系统最常缓存正在使用的规则。
如果AVC不包含相关策略的缓存决策，则对必要安全策略的请求将再次转发到安全策略数据库。
找到安全策略后，会将其传输到接收该决策的策略服务器。
如果请求的操作符合找到的策略，则允许该操作。否则，它被禁止并且所有决策信息都被写入SELinux日志文件。

除了决定允许或禁止某些操作外，Policy Enforcement Server模块还负责执行辅助任务，例如安全标签管理（分配，删除）。

与出色的系统一样，SELinux操作的简单性必须确保可靠的操作，对资源的低需求以及整个强制性访问控制系统的高生产率。

结论

“安全Linux”系列的这篇文章首先讨论了安全性增强的Linux，这是GNU / Linux操作系统中使用的最著名，功能最强大的强制性访问控制系统。

SELinux作为可靠的安全保护系统而享有盛誉。创建和开发SELinux的美国国家安全局的地位对此做出了巨大贡献。但是，除了NSA的权威性贡献外，SELinux还基于IT系统安全领域多年的科学发展。这些发展具有深入的理论基础，并已证明它们在特种军事系统的实践中非常有效。

但是，在企业网络或家用PC中使用SELinux仍然不是那么简单。 SELinux与基于标签的强制访问控制系统有关，这特别意味着必须为每个操作系统对象和主题分配一个标签-安全上下文。最后，平均而言，针对整个系统的良好SELinux安全策略包含超过100,000条规则！结果，以当前形式创建，完善和维护它会花费太多时间和精力。实际上，仅在极少数情况下才有理由从头开始为这样的现有或计划中的计算机系统创建这样的安全策略，例如，如果存储和处理的数据的性质需要出色的可靠性和服务器保护的话。该系统的批评者认为，SELinux由于其复杂性而从IT安全角度来看是如此难以理解。例如，如果入侵者能够绕过系统的防御，则可能会以管理员不正确设置SELinux为由。

在尝试为任何特定程序设计访问规则时，管理员可能还会遇到无视SELinux限制的操作。例如，Linux中的某些应用程序会部分地从超级用户权限切换为普通用户权限，反之亦然。也就是说，他们尝试应用最小特权原则–实际上，仅在绝对必要时才使用超级用户的权限。但是，将这种行为描述为SELinux安全模型的一部分并不容易。

但是，进步仍在继续，所有这些问题都受到开发人员的不断审查。已经创建了一些完整的规则集，可以在服务器和家用PC上的典型情况下使用：系统管理员只需选择一种现成的安全策略并在激活SELinux的情况下重新启动计算机。

通过创建和开发安全策略以及与开发人员进行交互并修改现有程序，SELinux本身也在不断得到改进。

“安全Linux”系列中的其他文章详细介绍了SELinux在实践中的使用方式，其中包括创建和完善规则，控制SELinux的行为方式以及解决可能的问题。

翻译自: https://www.ibm.com/developerworks/security/library/l-secure-linux-ru/index.html