Linux访问控制机制的优化设计

吴文高　刘强

摘 要： 从操作系统的访问控制机制角度出发，探讨Linux系统的安全性。以Linux的通用访问控制框架为基础，增加一层访问控制，实现一个具有可扩展性的访问控制体系结构，并定义和实现相应的功能模块，达到增强Linux系统安全访问的目的。

关键词： Linux； 操作系统； 安全访问； 访问控制机制

中图分类号：TP316.8 文献标志码：A 文章编号：1006-8228（2015）03-12-02

Abstract： At the angle of access control mechanism， the security of Linux operation system is discussed. On the basis of universal access control framework of Linux， a layer of access control is added， and the corresponding function modules are defined and realized. Then an extensible access control system is implemented， and the security of accessing Linux operation system is enhanced.

Key words： Linux； operation system； secure access； access control mechanism

0 引言

操作系统的安全功能主要是实现访问控制。访问控制是实现既定安全策略的系统安全技术，它对所有资源访问请求进行仲裁，即根据安全策略的要求，对每个资源访问请求做出是否许可的判断，能有效地阻止非法用户访问系统资源和合法用户非法使用资源。TCSEC（Trusted Computer System Evaluation Criteria，可信计算机系统评估准则）把访问控制作为评价系统安全的主要指标之一，具有不可替代的作用[1]。Linux是多用户、多任务的操作系统，本文从增强操作系统访问控制功能的角度，探讨Linux系统访问控制机制的安全性及其改进措施。

1 Linux访问控制机制分析

Linux系统在访问控制方面采用基于保护位的自主型访问控制，只能对user，group，other定义三种权限read，write，execute，并且root不受权限限制。在安全访问方面存在如下缺点。

⑴ 超级用户的权利太大。入侵者可以利用应用程序的漏洞，不通过身份认证就可以成为超级用户，这个假冒的超级户就可以轻松地修改系统的设置，安置后门，进而破坏系统。

⑵ 系统上的重要文件可以很容易地被修改。在操作系统上有很多重要的系统文件，如管理认证的系统程序（/bin/login）、存放系统用户口令的系统配置文件（/etc/shadow，/etc/passwd）等。只要是Linux系统的超级用户，就能够做一切事情，包括替换系统的认证程序，删除系统的重要日志文件等。

⑶ 权限粒度太大，被保护对象太少，对进程、设备等不加保护。

⑷ 由文件所有者自主设置权限，难以实现全局访问控制，系统不能基于单个用户决定设置访问权限。

为了增强Linux操作系统的安全访问特性，可以从多个方面采用不同的技术，如采用防火墙、入侵检测等技术增强网络安全，采用系统漏洞扫描对系统进行安全分析与检测，采用强制访问控制、审计、客体重用等技术提高操作系统安全的安全级别等。总的来说，无论采用哪种技术及其综合，都涉及到在体系结构设计上以通用访问控制框架作为基础，要考虑Linux操作系统在安全访问控制方面的可扩展性、可适应性和灵活性；在系统实现上，要考虑基于Linux安全框架的模块机制实现系统功能模块[2]。

2 扩展的访问控制体系结构

Linux的访问控制机制是以通用访问控制框架为基础而设计的，分为三层：策略实施模块AEF（Access Control Enforcenment Facility）、策略判断模块ADF（Access Control Decision Facility）、访问控制信息模块ACI（Access Control Information）。

为了增强Linux操作系统的访问控制机制，在Linux原有的三层访问控制机制的基础之上，增加一层访问控制，实现一个具有可扩展性的访问控制体系结构。其设计思想是：在内核级动态地截获访问请求，然后，根据安全管理员制订的访问控制策略，判断请求的操作是否被授权，从而实施增强的访问控制，控制系统中用户特别是超级用户的访问权限，增强对系统资源主要是文件和进程的保护。

AEF实施各个访问控制模型定义的安全策略，通过系统调用截获访问请求，然后扩展系统调用完成具体决策的实施。ADF是主决策模块，它定义AEF和访问控制模型之间的接口。该接口对于各种访问控制模型来说，犹如一个软总线，所有已实现了的访问控制模块通过它挂入策略判断系统；该接口为AEF提供了统一的策略判断调用界面，屏蔽了具体的访问控制模型。可以说，ADF是各种模型和AEF之间的桥梁。因为ADF只是一个接口，所以必须通过调用具体访问控制模型的决策函数才能完成策略判断。各个模块在实施策略判断时，需要参考各自的访问控制规则，它们保存ACI中。在本体系结构中，ACI只是一个文件，为了保证信息的安全性，它存放在特殊目录中，并通过某种方式加以保护。

扩展的访问控制体系结构通过内核安全模块实现与操作系统的无缝集成，保证Linux系统安全性、高效率、用户透明性，主要具有如下特点。

⑴ 可扩展性：该体系结构是开放的，可以根据应用需要添加其他的访问控制模型，只要这些模型遵循ADF定义的接口规则，该规则定义了请求的类型，客体类型。ADF定义的请求类型和客体类型是所有模型实现访问控制功能的基础，必须基于这些定义实现访问控制功能，才能集成到该框架中，以协同工作。

⑵ 灵活性：在该体系结构中可以实现多种访问控制模型，用户可以根据不同的管理需求选择一种或多种模型，具有配置灵活性。

⑶ 功能强大：这依赖于各个访问控制模型的功能。如基于用户的访问控制、基于角色的访问控制、强制访问控制、附加的访问控制模型，可以克服现有系统在访问控制方面的不足。

3 功能模块的设计

遵循模块化的设计思想实现扩展的访问控制体系结构，将相关的功能单元在同一模块中实现。功能模块的划分及其模块之间的关系。

⑴ 文件系统访问控制（File System Access Control，FSAC）增强模块：在操作系统的安全功能之上提供一个安全保护层。通过修改文件系统相关的系统调用，在核心层截取文件访问请求，然后利用访问控制模型中的ACL（Access Control List），实施增强的访问控制，以加强文件安全性、实现权限集中管理、限制root权限。

对于系统中的关键文件，如日志文件、口令文件、权限配置文件、安全模块程序等，由于它们的作用至关重要，需要采取额外的措施加以更严格的保证，此部分功能由该模块中的关键文件保护子层实现。文件系统保护是基础服务，核心态下的其他功能模块依赖于该模块提供的保护功能[3]。

⑵ 进程保护模块。传统的Linux没有提供进程保护机制。进程的属主和root可以用命令或系统调用杀死正在运行的进程[4]。实际上，一些关键进程如数据库守护进程、应用程序进程等应该一直运行，不能被杀死。因此采用进程防杀死技术和隐藏技术，以保护关键进程。

⑶ 自身保护模块。内核模块是实现访问控制功能增强的载体，因此内核模块的安全性直接影响访问控制功能能否成功实施、甚至影响系统的安全。鉴于访问控制增强模块的重要性和内核模块机制潜在的安全隐患，必须慎重考虑模块的安全性问题，保证加载到核心的内核模块安全，使其不被发现、不被恶意卸载、不被插入恶意模块。为此，采用模块隐藏和内核密封技术，以满足系统模块的安全性要求，增强系统自身的保护能力[5]。隐藏内核模块，使其不可见，从而降低模块的安全风险；内核密封，防止内核模块的加载/卸载，阻断恶意攻击。另外，安全程序将放入特殊目录，通过程序文件的保护，防止删除安全程序。

⑷ 配置管理工具。该模块运行在用户态，为安全管理员提供制定访问控制策略的界面，提供管理系统的接口。使用策略配置工具，可以添加、删除、更新、显示某个客体的访问控制列表项，访问控制列表项定义了哪个主体可以以何种权限访问某个客体。使用管理工具，可以将系统密封或者解封，查看系统运行状态，配置系统运行参数等操作。

4 结束语

本文针对Linux访问时存在的安全缺陷，以通用访问控制框架为基础，设计并实现了Linux访问控制增强系统，拓展了Linux系统在访问控制方面的可扩展性，可适应性和灵活性。如实现的ACL模型，既可以根据访问控制规则限制root权限，也可以基于单个用户制定访问控制策略。当然，也可以进一步实现其他更高级的访问控制模型。实现的保护对象是文件和进程，对系统中的其他对象如设备、网络、进程间通信也可以加以保护。比如，实现内核级防火墙对网络实施访问控制，从而提高网络安全性。这些方面有待于后续进一步研究和实现。

参考文献：

[1] 刘东辉，王树明.Linux微内核模型[J].微计算机信息，2007.8（23）：

12-14

[2] 陈莉君.深入分析Linux内核源代码[M].人民邮电出版社，2002.

[3] 陈岭，陈根才.在Linux文件系统中增加ACL功能[J].计算机应用，

2000.11（24）：56-57

[4] 王加森.基于Linux的安全操作系统[J].西南交通大学学报，2005.3

（21）：22-23

[5] 蒋韬，李信满.信息安全模性研究[J].小型微型计算机系统，2004.8

（21）：16-17