Linux系统的访问方法、访问装置和电子设备与流程

linux系统的访问方法、访问装置和电子设备
技术领域
1.本技术实施例涉及linux系统操作领域，具体而言，涉及一种linux系统的访问方法、访问装置、计算机可读存储介质和电子设备。


背景技术：

2.强制访问控制(mandatory access control，简称为mac)是一种操作系统的访问控制模型，资源的所有者无法决定谁可以访问它，而是由有权设置资源访问权限的组织或个人来决定谁拥有访问权限。例如：在政府组织的系统中通常设置有mac，在这些组织中，对于给定资源的访问权限主要由以下因素决定：数据(机密，最高机密等)的敏感标签，个人被允许访问的敏感信息的级别以及个人是否真的有必要访问资源，这是最小特权原则。
3.对于操作系统中的任何事件，均可抽象简化为一个“主体
–
行为
–
客体”的逻辑模型。其中，“主体”产生“行为”，并通过该“行为”对“客体”进行操作，例如“进程
–
打开
–
文件”、“进程
–
申请
–
权限”等情况。而现有方案如selinux，apparmor中，均是基于mac强访问控制模型，以主体为中心所建立的访问控制系统。其中selinux的配置比较完善，对“主体”，“行为”和“客体”均进行了定义和限制，所以其功能覆盖非常全面，安全性非常高，但是也带来了配置使用异常困难的问题；而apparmor则是以主体为中心，仅对其产生的行为和相应的客体进行了定义和访问控制，一旦脱离该主体，相应的行为和客体定义就不再生效。这使得apparmor的配置使用较为简单，但是相应的也产生了不能限制没有预先定义的主体，可能会产生通过某些技术操作来更换主体进而绕过安全访问控制的问题。
4.因此，需要一种在保证系统安全性的前提下，简化linux操作系统的访问配置的方法。


技术实现要素：

5.本技术实施例提供了一种linux系统的访问方法、访问装置、计算机可读存储介质和电子设备，以至少解决相关技术中linux系统的访问配置复杂的问题。
6.根据本技术的一个实施例，提供了一种linux系统的访问方法，包括：在接收到访问指令的情况下，获取访问行为的客体与主体，其中，所述访问指令由所述访问行为发出，所述客体为所述访问行为所要访问的linux系统中的访问对象，所述主体通过所述访问行为对所述客体进行访问；在确定所述客体属于被保护客体的情况下，确定所述主体是否具有所述客体的访问权限，其中，所述被保护客体表示具有访问权限限制的客体；在所述主体具有所述客体的所述访问权限的情况下，确定所述访问行为是否被访问规则允许，其中，所述访问规则为所述主体能够对所述客体执行的访问行为；在所述访问行为被所述访问规则允许的情况下，执行所述访问行为，以访问所述linux系统中的所述客体。
7.在一个示例性实施例中，在接收到所述访问指令之前，还包括：基于每个所述被保护客体与对应的每个安全函数生成至被保护客体群组，其中，所述被保护客体与所述安全函数一一对应，所述安全函数用于将访问所述被保护客体的所述主体与所述访问行为进行
整理并输出。
8.在一个示例性实施例中，在获取访问行为的客体与主体之后，还包括：根据所述访问行为、所述客体与所述主体生成至日志文件；将所述日志文件存储至日志记录单元，其中，所述日志记录单元用于输出判断结果，所述判断结果至少包括所述客体是否属于所述被保护客体、所述主体是否具有所述客体的所述访问权限，以及所述访问行为是否被所述访问规则允许。
9.在一个示例性实施例中，执行所述访问行为，包括：通过面向用户层接口执行所述访问行为，其中，所述面向用户层接口用于与用户层进行交互，以使所述用户层至少对所述访问权限和访问规则进行管理与控制。
10.在一个示例性实施例中，接收访问指令，包括：接收功能与规则管理单元发送的所述访问指令，其中，所述功能与规则管理单元用于将所述访问指令发送至面向用户层接口，所述面向用户层接口用于与用户层进行交互，以使所述用户层至少对所述访问权限和访问规则进行管理与控制。
11.在一个示例性实施例中，在将所述日志文件存储至日志记录单元之后，还包括：通过日志解析与规则生成单元解析所述日志文件，得到所述访问行为、所述客体与所述主体对应的文本格式的所述访问规则，其中，所述日志解析与规则生成单元用于将所述访问规则解析为文本格式的所述访问规则。
12.在一个示例性实施例中，所述访问规则是由规则编译单元将文本格式的所述访问规则根据预先定义语法结构进行解析后得到的预定格式的规则，其中，所述规则编译单元用于将所述文本格式的所述访问规则解析为所述预定格式的所述访问规则，所述预定格式为能够被linux系统所识别的格式。
13.根据本技术的另一个实施例，提供了一种linux系统的访问装置，包括：获取模块，用于在接收到访问指令的情况下，获取访问行为的客体与主体，其中，所述访问指令由所述访问行为发出，所述客体为所述访问行为所要访问的linux系统中的访问对象，所述主体通过所述访问行为对所述客体进行访问；第一确定模块，用于在确定所述客体属于被保护客体的情况下，确定所述主体是否具有所述客体的访问权限，其中，所述被保护客体表示具有访问权限限制的客体；第二确定模块，用于在所述主体具有所述客体的所述访问权限的情况下，确定所述访问行为是否被访问规则允许，其中，所述访问规则为所述主体能够对所述客体执行的访问行为；执行模块，用于在所述访问行为被所述访问规则允许的情况下，执行所述访问行为，以访问所述linux系统中的所述客体。
14.根据本技术的又一个实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一种方法实施例中的步骤。
15.根据本技术的又一个实施例，还提供了一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一种方法实施例中的步骤。
16.通过本技术，首先获取访问行为的客体与主体，在确定客体属于被保护客体的情况下，确定上诉主体是否具有上述客体的访问权限，之后，确定访问行为是否被访问规则允许，在访问行为被允许的情况下，执行上述访问行为，以使上述主体访问上述客体。与现有
技术中，对主体、访问行为和客体均进行限制导致访问配置非常复杂的方法相比，本技术只对被保护的客体进行了访问限制，在保证系统安全性的基础上，简化了系统的访问配置过程，因此，可以解决linux系统的访问配置复杂的问题，达到在保证系统安全性的前提下简化linux系统的访问配置的效果。
附图说明
17.图1是本技术实施例的一种linux系统的访问方法的移动终端的硬件结构框图；
18.图2是本技术实施例的一种linux系统的访问方法中现有技术的规则示意图；
19.图3是本技术实施例的一种linux系统的访问方法的流程图；
20.图4是本技术实施例的一种linux系统的访问方法的规则示意图；
21.图5是本技术实施例的一种具体的linux系统的访问方法的流程示意图；
22.图6是本技术实施例的另一种具体的linux系统的访问方法的流程示意图；
23.图7是本技术实施例的一种linux系统的访问装置的结构框图。
24.其中，上述附图包括以下附图标记：
25.102、处理器；104、存储器；106、传输设备；108、输入输出设备。
具体实施方式
26.下文中将参考附图并结合实施例来详细说明本技术的实施例。
27.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
28.本技术实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本技术实施例的一种linux系统的访问方法的移动终端的硬件结构框图。如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)和用于存储数据的存储器104，其中，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。
29.存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本技术实施例中的linux系统的访问方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
30.传输设备106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输设备106包括一个网络适配器(network interface controller，简称为nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输设备106可以为射频(radio frequency，简称为rf)
模块，其用于通过无线方式与互联网进行通讯。
31.为了便于描述，以下对本技术实施例涉及的部分名词或术语进行说明：
32.mac：mandatory access control，强制访问控制，简称为mac，是一种访问控制模型，其中资源的所有者无法决定谁可以访问它，而是由有权设置资源访问权限的组织或个人来决定谁拥有访问权限。在政府组织中常有mac的实施，在这些组织中，对给定资源的访问主要由以下因素决定：应用于数据(机密，最高机密等)的敏感标签；根据个人被允许访问的敏感信息的级别；通过个人是否真的有必要访问资源，即最小特权原则。
33.dac：discretionary access control，自由访问控制，简称为dac，是一种基于目标资源所有者确定访问权限的访问控制模型。资源的拥有者可以决定谁拥有访问权限，以及他们到底拥有哪些资源的访问权限。
34.lsm：linux security modules，一种轻量级通用访问控制框架，简称为lsm，适合于多种访问控制模型在它上面以内核可加载模块的形式实现，用户可以根据自己的需求选择合适的安全模块加载到内核上实现。
35.selinux：security-enhanced linux，一种基于域-类型模型(domain-type)的强制访问控制(mac)安全系统，它由nsa编写并设计成内核模块包含到内核中，相应的某些安全相关的应用也被打了selinux的补丁，最后还有一个相应的安全策略用于管理和控制程序的访问操作。
36.apparmor：是一个高效和易于使用的linux系统安全应用程序。apparmor安全策略可以完全定义指定应用程序可以访问的系统资源与各自的特权，从而对操作系统和应用程序所受到的威胁进行从内到外的保护。
37.现有技术中，均是以主体为中心进行访问设计的，主体作为主键存在，图2是本技术实施例的一种linux系统的访问方法中现有技术的规则示意图，如图2所示，即定义主体能够通过行为1对客体3进行访问，主体能够通过行为2对客体1进行访问，主体能够通过行为3对客体4进行访问，主体能够通过行为4对客体2进行访问。当来自非规则指定主体的目标进行请求时，就会自动放行，即默认允许非规则指定的主体访问客体。在实际使用中，由于系统或者业务或者程序设计的复杂性，导致实际存在相当多并且功能复杂的访问行为的主体存在，而稍微存在的疏忽或意外出现的漏洞等情况就可能导致安全防护被越过。例如：abc三个程序，实际由a程序提供主要服务，因而设计导入了完整的a程序的规则，但是由于a程序执行时会调用b程序执行某个子功能并且被疏忽(因为对于a程序来说b程序只是一个简单的子功能的实现，并未定义b程序的访问规则，因此未被完全限制，但实际b可以支持一些更强大的可能会被利用的功能)，或由于程序本身存在漏洞，导致黑客启动了b执行恶意功能，此时就会由于规则库中不包含程序b的规则导致安全防护被越过。并且在实际环境中，内置的实现各种功能的小程序非常多，导致需要为每个程序(及其可能启动的关联程序)设置规则，使得访问配置变得异常复杂。
38.selinux具有最高的安全性，但是由于其对主体、行为、客体均进行了严格的限制，因此不仅仅是主体，连同客体的安全标记以及它们之间的行为都需要进行完整的配置定义。这也导致了该安全组件非常难以使用，只有在安全要求非常严格的环境中才会配置使用。其为了便于使用设计实现了“targeted模式”，只保护网络服务程序(因为其对外暴露，被攻击可能性大)，但也存在被越过的可能。类似的配置还有apparmor，其是标准的以主体
为中心的实现。其规则依附于以路径为标准的程序文件，当程序启动，apparmor就会依据预定的规则限制其行为。但是它也存在被越过的可能，同时因为apparmor以路径为标记的问题，导致程序移动或重命名后规则就会失效，因此apparmor具有使用便捷但安全性低的特点。
39.因此，为了在保证系统安全性的同时，简化系统访问规则的配置过程，在本实施例中提供了一种运行于上述移动终端linux系统的访问方法，图3是根据本技术实施例的一种linux系统的访问方法的流程图，如图3所示，该流程包括如下步骤：
40.步骤s302，在接收到访问指令的情况下，获取访问行为的客体与主体，其中，上述访问指令由上述访问行为发出，上述客体为上述访问行为所要访问的linux系统中的访问对象，上述主体通过上述访问行为对上述客体进行访问；
41.具体地，由于操作系统(如linux操作系统)中的事件均可抽象为“主体
–
行为
–
客体”的逻辑模型，其中，“主体”产生“行为”，并通过该“行为”对“客体”进行操作，例如“进程
–
打开
–
文件”、“进程
–
申请
–
权限”等情况。本技术以客体为中心进行访问配置，当主体要对客体执行访问行为时，首先发送访问指令，因此，获取访问行为的主体与客体，以用于后续步骤进一步判断客体是否属于被保护客体。
42.步骤s304，在确定上述客体属于被保护客体的情况下，确定上述主体是否具有上述客体的访问权限，其中，上述被保护客体表示具有访问权限限制的客体；
43.具体地，本技术通过定义被保护客体的方式进行访问配置，即生成被保护客体的名单或者列表，例如：密码文件、证书文件、秘钥文件、核心配置文件、安全防护程序进程等，均可被作为被保护客体。对于上述被保护客体只允许指定主体按照指定的访问行为对其进行访问，即预先设定被保护客体的访问权限。访问权限的设定支持黑名单模式(即规则内的目标被禁止)和白名单模式(即规则内的目标被允许)，但实际使用中白名单更安全。例如：存在核心文件a，当其被规则保护时即属于被保护客体时，仅允许其专用管理程序a(主体)访问，此时若黑客攻陷主机企图通过b程序访问被保护客体核心文件a，就会被所阻止，同时其他程序如cdef等也无法对核心文件a进行访问，从而保证了被保护客体的安全性。
44.步骤s306，在上述主体具有上述客体的访问权限的情况下，确定上述访问行为是否被访问规则允许，其中，上述访问规则为上述主体能够对上述客体执行的访问行为；
45.具体地，在上述主体具有上述被保护客体的访问权限的情况下，继续查询访问行为是否也被允许，例如：规则规定主体a具有被保护客体a的访问权限，且只能对被保护客体a执行“打开”这一访问行为，而当主体a对客体执行的访问行为为“删除”时，这一访问行为就不被访问规则所允许。
46.步骤s308，在上述访问行为被上述访问规则允许的情况下，执行上述访问行为，以访问上述linux系统中的上述客体。
47.具体地，在主体具有被保护客体的访问权限并且访问行为被允许的情况下，主体执行上述访问行为，以访问被保护客体。具体实现过程中，本技术的linux系统的访问方法分为多个部分，上述步骤s202～s208为上述访问方法中的规则检查和访问控制的部分，其主要负责在接收到访问指令时对传递的环境信息进行处理和校验，环境信息包括主体和访问行为，获取当前访问行为的执行者和执行目标，即“主体”和“客体”，然后将客体信息代入规则库中进行一级查询，确认该客体是否属于被保护客体。如果属于被保护客体，则将上述
主体信息和访问行为信息代入规则库进行二级查询，确认主体和访问行为是否被规则所允许，然后根据查询结果执行相应的操作，即允许执行上述访问行为或拦截上述访问行为。
48.通过上述步骤，首先获取访问行为的客体与主体，在确定客体属于被保护客体的情况下，确定上诉主体是否具有上述客体的访问权限，之后，确定访问行为是否被访问规则允许，在访问行为被允许的情况下，执行上述访问行为，以使上述主体访问上述客体。与现有技术中，对主体、访问行为和客体均进行限制导致访问配置非常复杂的方法相比，本技术只对被保护的客体进行了访问限制，在保证系统安全性的基础上，简化了系统的访问配置过程，因此，解决了linux系统的访问配置复杂的问题，达到了在保证系统安全性的前提下简化linux系统的访问配置的效果。
49.其中，上述步骤的执行主体可以为服务器、终端等，但不限于此。
50.在一些可选的实施方式中，在接收到上述访问指令之前，还包括：基于每个上述被保护客体与对应的每个安全函数生成至被保护客体群组，其中，上述被保护客体与上述安全函数一一对应，上述安全函数用于将访问上述被保护客体的上述主体与上述访问行为进行整理并输出。通过该方法，设定被保护客体的安全函数，将访问被保护客体的主体与访问行为的信息进行整理，这样可以根据整理后的主体与访问行为信息确定主体和访问行为是否被允许。
51.具体地，由安全函数首先对访问被保护客体的主体和访问行为进行整理并输出，提高了被保护客体的安全性。具体应用过程中，上述步骤被称为基于lsm的内核安全函数挂钩和处理部分，主要负责依照lsm框架所提供的设计和对外接口来对系统内的被保护客体进行关联与调用，被保护客体在实际应用中可以为系统中的敏感函数。该部分的主要实现方式为将需要关联的被保护客体打包生成一个“security_hook_list”结构体数组，数组中的每个数组项包含一个被保护客体及其对应的安全函数，一种具体的程序如下：static struct security_hook_list demo_hooks[]＝{lsm_hook_init(binder_set_context_mgr,demo_binder_set_context_mgr),lsm_hoo k_init(binder_transaction,demo_binder_transaction)},然后调用内核提供的“security_add_hooks函数”将该数组注册到linux系统的内核中。当系统内核中的被保护客体(敏感函数)被程序(主体)调用时，就会依据该数组中的对应关系调用并执行安全函数，安全函数会将上述主体与访问行为进行整合后传递给上述规则检查和访问控制部分来进行进一步的处理。
[0052]
为了记录上述访问行为、主体与客体信息，以便于系统的控制与管理，在一些可选的实施方式中，在获取访问行为的客体与主体之后，还包括：根据上述访问行为、上述客体与上述主体生成至日志文件；将上述日志文件存储至日志记录单元，其中，上述日志记录单元用于输出判断结果，上述判断结果至少包括上述客体是否属于上述被保护客体、上述主体是否具有上述客体的上述访问权限，以及上述访问行为是否被上述访问规则允许。
[0053]
具体地，将上述主体通过上述访问行为对上述客体进行访问的事件存储至文件中，生成日志文件，上述事件还包括上述事件发生过程中的中间结果，例如：上述客体是否属于上述被保护客体、上述主体是否具有上述客体的上述访问权限，以及上述访问行为是否被上述访问规则允许等；之后日志文件存储至日志记录单元，日志记录单元将上述主体通过上述访问行为对上述客体进行访问的事件以及上述事件发生过程中的中间结果进行输出。具体实现过程中，上述步骤被称为日志记录部分，日志记录部分主要负责记录和输出
主体、访问行为和客体的信息，并反馈查询和处理的结果。允许和禁止等操作都会被记录在日志之中，方便系统管理员查询。同时在规则编写不完善导致程序出现问题时，日志文件用于定位问题所在，并由用户进行程序管理和自动生成新规则等。
[0054]
在一些可选的实施方式中，执行上述访问行为，包括：通过面向用户层接口执行上述访问行为，其中，上述面向用户层接口用于与用户层进行交互，以使上述用户层至少对上述访问权限和访问规则进行管理与控制。该方法通过特定的面向用户层接口执行上述访问行为，这样可以通过对访问接口的限制，进一步保证系统的安全性。
[0055]
具体地，上述访问规则和访问权限需要通过特定接口进行设定，本技术设定面向用户层接口部分，用于同用户层进行交互，访问行为通过面向用户层接口对客体进行访问，管理员通过上述接口来管理被保护客体的访问权限、访问行为等规则策略。具体应用过程中，依照linux及其内部安全模块的设计思想，面向用户层接口可以为多个文件，位于“/sys/kernel/security/module_name/”下，实现规则的加载、卸载、重置等功能。为了进一步保证系统的安全，面向用户层接口的调用可以进行一定的限制，数据结构等也可以进行一定的限制，同时也可以根据需要修改面向用户层接口的实现功能与实现方式，例如：加入身份认证、数据结构加密等功能。在一些可选的实施方式中，上述基于lsm的内核安全函数挂钩和处理部分、规则检查和访问控制的部分、日志记录输出部分和面向用户层接口部分构成了上述linux系统的访问方法中的客体访问控制组件，上述客体访问控制组件是编译在linux系统的内核中，由内核lsm框架调用运行。
[0056]
为了保证上述访问方法执行的完整性，在一些可选的实施方式中，接收访问指令，包括：接收功能与规则管理单元发送的上述访问指令，其中，上述功能与规则管理单元用于将上述访问指令发送至面向用户层接口，上述面向用户层接口用于与用户层进行交互，以使上述用户层至少对上述访问权限和访问规则进行管理与控制。
[0057]
具体地，访问行为由接收功能与规则管理单元触发并通过上述面向用户层接口传输至上述规则检查和访问控制部分。在实际应用过程中，上述功能与规则管理单元是与管理员进行用户交互的主要部分，管理员输入指令后，该部分会根据管理员的指令，调用相应的程序，生成对应的请求(或数据体结构)，通过上述程序访问linux系统中的客体(包括被保护客体和不属于被保护客体的客体)，并调用上述客体访问控制组件中的面向用户层接口，从而实现相关功能状态查看、规则库的查询以及管理等功能。
[0058]
在一些可选的实施方式中，在将上述日志文件存储至日志记录单元之后，还包括：通过日志解析与规则生成单元解析上述日志文件，得到上述访问行为、上述客体与上述主体对应的文本格式的上述访问规则，其中，上述日志解析与规则生成单元用于将上述访问规则解析为文本格式的上述访问规则。该方法通过设置日志解析与规则生成单元解析日志文件中的信息，这样可以查询主体通过访问行为对客体访问的事件及结果，便于对系统的安全性进行控制与管理。
[0059]
具体地，日志解析与规则生成单元主要用于解析由上述客体访问控制组件的日志记录部分生成的日志文件，从中解析提取出“主体-行为-客体”关系，然后填写并生成相应的规则文本。这样可以在执行复杂功能程序后自动提取和生成规则文本，避免了管理员手工编写复杂功能规则的日志文件。规则生成完成后，即可导出为文本文件或是调用规则编译部分进行编译处理。
[0060]
为了便于对访问规则进行控制与管理，在一些可选的实施方式中，上述访问规则是由上述规则编译单元将文本格式的上述访问规则根据预先定义语法结构进行解析后得到的预定格式的规则，其中，上述规则编译单元用于将上述文本格式的上述访问规则解析为上述预定格式的上述访问规则，上述预定格式为能够被linux系统所识别的格式。
[0061]
具体地，规则编译单元主要负责读取用户编写的，或是由上述日志解析与规则生成单元生成的规则文本，根据预先定义好的语法结构去解析文本中包含的访问规则，将包括客体、行为和主体，以及相应的允许或者禁止的处理方式的文本规则语言编译为能够被存储于linux内核中的客体访问控制组件所识别和接受的格式。生成的访问规则可以直接通过上述面向用户层接口导入到客体访问控制组件中，也可以导出到文件中保存，具体操作取决于管理员输入的指令。在一些可选的实施方式中，上述日志解析与规则生成单元、功能与规则管理单元与规则编译单元组成上述linux系统的访问方法中的用户层访问控制规则管理组件，访问控制规则管理组件位于用户层并且提供给管理员，用于管理和控制上述客体访问控制组件的功能。
[0062]
为了使得本领域技术人员能够更加清楚地了解本技术的技术方案，以下将结合具体的实施例对本技术的数据的传输方法的实现过程进行详细说明。
[0063]
本实施例涉及一种具体的linux系统的访问方法，如图4至图6所示，包括如下步骤：
[0064]
步骤s1：图4是本技术实施例的一种linux系统的访问方法的规则示意图，如图4所示，以客体为主键，即从客体的角度定义主体1只能通过行为3对客体进行访问，主体2只能通过行为1对客体进行访问，主体3只能通过行为4对客体进行访问，主体4只能通过行为4对客体进行访问等，上述被定义的主体与对应的行为之外的主体与行为均不能对客体进行访问。具体的linux系统的访问流程如图5和图6所示，linux系统中的程序被执行，程序调用相关函数接口执行对应功能，访问指令被传递到linux系统的内核进行处理，基于lsm的内核函数挂钩处理，lsm框架接收到函数访问指令；
[0065]
步骤s2：lsm检查到被调用的函数(被保护客体)已经被客体访问控制组件所关联，因此调用相应的安全函数；
[0066]
步骤s3：安全函数接收到访问指令后，整理由lsm传递过来的相关环境信息(包括主体、访问行为、客体、数据参数等)，然后将这些信息打包后传输至规则检查与访问控制部分，以进行进一步的校验和处理；
[0067]
步骤s4：规则检查与访问控制部分在接收到访问指令后，就会获取由安全函数传递过来的信息并进行解析，从中获得“主体”，“行为”和“客体”的相关信息，然后将这些信息带入规则库中查询：先查询“客体”是否存在于规则库中(是否属于被保护客体)，如果不存在表明客体不属于被保护的客体，因此不需要对其访问权限进行限制，在这个过程中，不会主动的对“主体”及其“行为”进行检查和限制；
[0068]
步骤s5：如果规则库中存在相对应的“客体”即属于被保护客体，则进一步查询“主体”是否具有上述被保护客体的访问权限，并查询“访问行为”是否被访问规则所允许，根据当前的运行状态设置(黑或白名单)及访问规则决定相应的处理方式，并将处理结果返回给安全函数，过程和处理结果被记录到日志文件中，例如“主体”“行为”“客体”的信息和处理结果，以供管理员后续查询；
[0069]
步骤s6：安全函数对处理结果进行解析处理，转换成能够被lsm框架识别的形式，返回给lsm框架，lsm框架获取处理结果后，调用linux系统内核接口，由内核进行处理，linux系统内核接受lsm框架的接口调用，对访问行为做出回应，即允许访问被保护客体或阻止访问被保护客体；
[0070]
步骤s7：当管理员需要对运行状态进行查看管理时，则可以使用用户层访问控制规则管理组件的功能和规则管理功能，访问由客体访问控制组件提供的面向用户层接口来进行查看管理；
[0071]
步骤s8：当面向用户层接口接收到相关的管理请求，就会同客体访问控制组件进行交互，获取客体访问控制组件当前的运行状态、访问规则列表等信息并返回；
[0072]
步骤s9：如果管理员有生成新规则的需求，则可以通过功能与规则管理部分调用日志解析与规则生成部分来读取日志文件生成访问规则进行编译，或直接调用规则编译部分来编译用户自行编写的访问规则的文本；
[0073]
步骤s10：如果管理员调用的是日志解析与规则生成部分，则程序读取客体访问控制组件所生成的日志文件，并从中解析出目前发生过的所有的“主体
”‑“
行为
”‑“
客体”事件，并展示给管理员，管理员可以根据实际需要选择日志文件中的日志文本，转换编写为对应的访问规则文本；
[0074]
步骤s11：访问规则文本生成完毕后，就会调用规则编译部分进行编译，转换为可以被客体访问控制组件识别的格式，管理员可以通过面向用户层接口来将这些编译后的访问规则导入到客体访问控制组件中。
[0075]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本技术各个实施例上述的方法。
[0076]
在本实施例中还提供了一种linux系统的访问装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
[0077]
图7是根据本技术实施例的一种linux系统的访问装置的结构框图，如图7所示，该装置包括：
[0078]
获取模块22，用于在接收到访问指令的情况下，获取访问行为的客体与主体，其中，上述访问指令由上述访问行为发出，上述客体为上述访问行为所要访问的linux系统中的访问对象，上述主体通过上述访问行为对上述客体进行访问；
[0079]
具体地，由于操作系统(如linux操作系统)中的事件均可抽象为“主体
–
行为
–
客体”的逻辑模型，其中，“主体”产生“行为”，并通过该“行为”对“客体”进行操作，例如“进程
–
打开
–
文件”、“进程
–
申请
–
权限”等情况。本技术以客体为中心进行访问配置，当主体要对客体执行访问行为时，首先发送访问指令，因此，获取访问行为的主体与客体，以用于后续步骤进一步判断客体是否属于被保护客体。
[0080]
第一确定模块24，用于在确定上述客体属于被保护客体的情况下，确定上述主体是否具有上述客体的访问权限，其中，上述被保护客体表示具有访问权限限制的客体；
[0081]
具体地，本技术通过定义被保护客体的方式进行访问配置，即生成被保护客体的名单或者列表，例如：密码文件、证书文件、秘钥文件、核心配置文件、安全防护程序进程等，均可被作为被保护客体。对于上述被保护客体只允许指定主体按照指定的访问行为对其进行访问，即预先设定被保护客体的访问权限。访问权限的设定支持黑名单模式(即规则内的目标被禁止)和白名单模式(即规则内的目标被允许)，但实际使用中白名单更安全。例如：存在核心文件a，当其被规则保护时即属于被保护客体时，仅允许其专用管理程序a(主体)访问，此时若黑客攻陷主机企图通过b程序访问被保护客体核心文件a，就会被所阻止，同时其他程序如cdef等也无法对核心文件a进行访问，从而保证了被保护客体的安全性。
[0082]
第二确定模块26，用于在上述主体具有上述客体的上述访问权限的情况下，确定上述访问行为是否被访问规则允许，其中，上述访问规则为上述主体能够对上述客体执行的访问行为；
[0083]
具体地，在上述主体具有上述被保护客体的访问权限的情况下，继续查询访问行为是否也被允许，例如：规则规定主体a具有被保护客体a的访问权限，且只能对被保护客体a执行“打开”这一访问行为，而当主体a对客体执行的访问行为为“删除”时，这一访问行为就不被访问规则所允许。
[0084]
执行模块28，用于在上述访问行为被上述访问规则允许的情况下，执行上述访问行为，以访问上述linux系统中的上述客体。
[0085]
具体地，在主体具有被保护客体的访问权限并且访问行为被允许的情况下，主体执行上述访问行为，以访问被保护客体。具体实现过程中，本技术的linux系统的访问装置分为多个部分，上述步骤s202～s208为上述访问装置中的规则检查和访问控制的部分，其主要负责在接收到访问指令时对传递的环境信息进行处理和校验，环境信息包括主体和访问行为，获取当前访问行为的执行者和执行目标，即“主体”和“客体”，然后将客体信息代入规则库中进行一级查询，确认该客体是否属于被保护客体。如果属于被保护客体，则将上述主体信息和访问行为信息代入规则库进行二级查询，确认主体和访问行为是否被规则所允许，然后根据查询结果执行相应的操作，即允许执行上述访问行为或拦截上述访问行为。
[0086]
通过上述装置，获取访问行为的客体与主体，在确定客体属于被保护客体的情况下，确定上诉主体是否具有上述客体的访问权限，确定访问行为是否被访问规则允许，在访问行为被允许的情况下，执行上述访问行为，以使上述主体访问上述客体。与现有技术中，对主体、访问行为和客体均进行限制导致访问配置非常复杂的装置相比，本技术只对被保护的客体进行了访问限制，在保证系统安全性的基础上，简化了系统的访问配置过程，因此，解决了linux系统的访问配置复杂的问题，达到了在保证系统安全性的前提下简化linux系统的访问配置的效果。
[0087]
在一些可选的实施方式中，上述装置还包括第一生成模块，用于基于每个上述被保护客体与对应的每个安全函数生成被保护客体群组，其中，上述被保护客体与上述安全函数一一对应，上述安全函数用于将访问上述被保护客体的上述主体与上述访问行为进行整理并输出。通过该装置，设定被保护客体的安全函数，将访问被保护客体的主体与访问行为的信息进行整理，这样可以根据整理后的主体与访问行为信息确定主体和访问行为是否
被允许。
[0088]
具体地，由安全函数首先对访问被保护客体的主体和访问行为进行整理并输出，提高了被保护客体的安全性。具体应用过程中，上述步骤被称为基于lsm的内核安全函数挂钩和处理部分，主要负责依照lsm框架所提供的设计和对外接口来对系统内的被保护客体进行关联与调用，被保护客体在实际应用中可以为系统中的敏感函数。该部分的主要实现方式为将需要关联的被保护客体打包生成一个“security_hook_list”结构体数组，数组中的每个数组项包含一个被保护客体及其对应的安全函数，然后调用内核提供的“security_add_hooks函数”将该数组注册到linux系统的内核中。当系统内核中的被保护客体(敏感函数)被程序(主体)调用时，就会依据该数组中的对应关系调用并执行安全函数，安全函数会将上述主体与访问行为进行整合后传递给上述规则检查和访问控制部分来进行进一步的处理。
[0089]
为了记录上述访问行为、主体与客体信息，以便于系统的控制与管理，在一些可选的实施方式中，上述装置还包括第二生成模块和存储模块，其中：第二生成模块用于根据上述访问行为、上述客体与上述主体生成至日志文件；存储模块用于将上述日志文件存储至日志记录单元，其中，上述日志记录单元用于输出判断结果，上述判断结果至少包括上述客体是否属于上述被保护客体、上述主体是否具有上述客体的上述访问权限，以及上述访问行为是否被上述访问规则允许。
[0090]
具体地，将上述主体通过上述访问行为对上述客体进行访问的事件存储至文件中，生成日志文件，上述事件还包括上述事件发生过程中的中间结果，例如：上述客体是否属于上述被保护客体、上述主体是否具有上述客体的上述访问权限，以及上述访问行为是否被上述访问规则允许等；之后日志文件存储至日志记录单元，日志记录单元将上述主体通过上述访问行为对上述客体进行访问的事件以及上述事件发生过程中的中间结果进行输出。具体实现过程中，上述步骤被称为日志记录部分，日志记录部分主要负责记录和输出主体、访问行为和客体的信息，并反馈查询和处理的结果。允许和禁止等操作都会被记录在日志之中，方便系统管理员查询。同时在规则编写不完善导致程序出现问题时，日志文件用于定位问题所在，并由用户进行程序管理和自动生成新规则等。
[0091]
在一些可选的实施方式中，执行模块包括执行子模块，用于通过面向用户层接口执行上述访问行为，其中，上述面向用户层接口用于与用户层进行交互，以使上述用户层至少对上述访问权限和访问规则进行管理与控制。该装置通过特定的面向用户层接口执行上述访问行为，这样可以通过对访问接口的限制，进一步保证系统的安全性。
[0092]
具体地，上述访问规则和访问权限需要通过特定接口进行设定，本技术设定面向用户层接口部分，用于同用户层进行交互，访问行为通过面向用户层接口对客体进行访问，管理员通过上述接口来管理被保护客体的访问权限、访问行为等规则策略。具体应用过程中，依照linux及其内部安全模块的设计思想，面向用户层接口可以为多个文件，位于“/sys/kernel/security/module_name/”下，实现规则的加载、卸载、重置等功能。为了进一步保证系统的安全，面向用户层接口的调用可以进行一定的限制，数据结构等也可以进行一定的限制，同时也可以根据需要修改面向用户层接口的实现功能与实现方式，例如：加入身份认证、数据结构加密等功能。在一些可选的实施方式中，上述基于lsm的内核安全函数挂钩和处理部分、规则检查和访问控制的部分、日志记录输出部分和面向用户层接口部分构
成了上述linux系统的访问装置中的客体访问控制组件，上述客体访问控制组件是编译在linux系统的内核中，由内核lsm框架调用运行。
[0093]
为了保证上述访问装置执行的完整性，在一些可选的实施方式中，获取模块包括接收子模块，用于接收功能与规则管理单元发送的上述访问指令，其中，上述功能与规则管理单元用于将上述访问指令发送至面向用户层接口，上述面向用户层接口用于与用户层进行交互，以使上述用户层至少对上述访问权限和访问规则进行管理与控制。
[0094]
具体地，访问行为由接收功能与规则管理单元触发并通过上述面向用户层接口传输至上述规则检查和访问控制部分。在实际应用过程中，上述功能与规则管理单元是与管理员进行用户交互的主要部分，管理员输入指令后，该部分会根据管理员的指令，调用相应的程序，生成对应的请求(或数据体结构)，通过上述程序访问linux系统中的客体(包括被保护客体和不属于被保护客体的客体)，并调用上述客体访问控制组件中的面向用户层接口，从而实现相关功能状态查看、规则库的查询以及管理等功能。
[0095]
在一些可选的实施方式中，上述装置还包括解析模块，用于通过日志解析与规则生成单元解析上述日志文件，得到上述访问行为、上述客体与上述主体对应的文本格式的上述访问规则，其中，上述日志解析与规则生成单元用于将上述访问规则解析为文本格式的上述访问规则。该装置通过设置日志解析与规则生成单元解析日志文件中的信息，这样可以查询主体通过访问行为对客体访问的事件及结果，便于对系统的安全性进行控制与管理。
[0096]
具体地，日志解析与规则生成单元主要用于解析由上述客体访问控制组件的日志记录部分生成的日志文件，从中解析提取出“主体-行为-客体”关系，然后填写并生成相应的规则文本。这样可以在执行复杂功能程序后自动提取和生成规则文本，避免了管理员手工编写复杂功能规则的日志文件。规则生成完成后，即可导出为文本文件或是调用规则编译部分进行编译处理。
[0097]
为了便于对访问规则进行控制与管理，在一些可选的实施方式中，上述装置中的访问规则是由上述规则编译单元将文本格式的上述访问规则根据预先定义语法结构进行解析后得到的预定格式的规则，其中，上述规则编译单元用于将上述文本格式的上述访问规则解析为上述预定格式的上述访问规则，上述预定格式为能够被linux系统所识别的格式。
[0098]
具体地，规则编译单元主要负责读取用户编写的，或是由上述日志解析与规则生成单元生成的规则文本，根据预先定义好的语法结构去解析文本中包含的访问规则，将包括客体、行为和主体，以及相应的允许或者禁止的处理方式的文本规则语言编译为能够被存储于linux内核中的客体访问控制组件所识别和接受的格式。生成的访问规则可以直接通过上述面向用户层接口导入到客体访问控制组件中，也可以导出到文件中保存，具体操作取决于管理员输入的指令。在一些可选的实施方式中，上述日志解析与规则生成单元、功能与规则管理单元与规则编译单元组成上述linux系统的访问装置中的用户层访问控制规则管理组件，访问控制规则管理组件位于用户层并且提供给管理员，用于管理和控制上述客体访问控制组件的功能。
[0099]
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意
组合的形式分别位于不同的处理器中。
[0100]
本技术的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一种方法实施例中的步骤。
[0101]
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：u盘、只读存储器(read-only memory，简称为rom)、随机存取存储器(random access memory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
[0102]
本技术的实施例还提供了一种电子设备，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一种方法实施例中的步骤。
[0103]
在一个示例性实施例中，上述电子设备还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
[0104]
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
[0105]
显然，本领域的技术人员应该明白，上述的本技术的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本技术不限制于任何特定的硬件和软件结合。
[0106]
以上所述仅为本技术的优选实施例而已，并不用于限制本技术，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。

技术特征：
1.一种linux系统的访问方法，其特征在于，包括：在接收到访问指令的情况下，获取访问行为的客体与主体，其中，所述访问指令由所述访问行为发出，所述客体为所述访问行为所要访问的linux系统中的访问对象，所述主体通过所述访问行为对所述客体进行访问；在确定所述客体属于被保护客体的情况下，确定所述主体是否具有所述客体的访问权限，其中，所述被保护客体表示具有访问权限限制的客体；在所述主体具有所述客体的所述访问权限的情况下，确定所述访问行为是否被访问规则允许，其中，所述访问规则为所述主体能够对所述客体执行的访问行为；在所述访问行为被所述访问规则允许的情况下，执行所述访问行为，以访问所述linux系统中的所述客体。2.根据权利要求1所述的方法，其特征在于，在接收到所述访问指令之前，还包括：基于每个所述被保护客体与对应的每个安全函数生成被保护客体群组，其中，所述被保护客体与所述安全函数一一对应，所述安全函数用于将访问所述被保护客体的所述主体与所述访问行为进行整理并输出。3.根据权利要求1所述的方法，其特征在于，在获取访问行为的客体与主体之后，还包括：根据所述访问行为、所述客体与所述主体生成至日志文件；将所述日志文件存储至日志记录单元，其中，所述日志记录单元用于输出判断结果，所述判断结果至少包括所述客体是否属于所述被保护客体、所述主体是否具有所述客体的所述访问权限，以及所述访问行为是否被所述访问规则允许。4.根据权利要求1所述的方法，其特征在于，执行所述访问行为，包括：通过面向用户层接口执行所述访问行为，其中，所述面向用户层接口用于与用户层进行交互，以使所述用户层至少对所述访问权限和访问规则进行管理与控制。5.根据权利要求1所述的方法，其特征在于，接收访问指令，包括：接收功能与规则管理单元发送的所述访问指令，其中，所述功能与规则管理单元用于将所述访问指令发送至面向用户层接口，所述面向用户层接口用于与用户层进行交互，以使所述用户层至少对所述访问权限和访问规则进行管理与控制。6.根据权利要求3所述的方法，其特征在于，在将所述日志文件存储至日志记录单元之后，还包括：通过日志解析与规则生成单元解析所述日志文件，得到所述访问行为、所述客体与所述主体对应的文本格式的所述访问规则，其中，所述日志解析与规则生成单元用于将所述访问规则解析为文本格式的所述访问规则。7.根据权利要求6所述的方法，其特征在于，所述访问规则是由规则编译单元将文本格式的所述访问规则根据预先定义语法结构进行解析后得到的预定格式的规则，其中，所述规则编译单元用于将所述文本格式的所述访问规则解析为所述预定格式的所述访问规则，所述预定格式为能够被linux系统所识别的格式。8.一种linux系统的访问装置，其特征在于，包括：获取模块，用于在接收到访问指令的情况下，获取访问行为的客体与主体，其中，所述访问指令由所述访问行为发出，所述客体为所述访问行为所要访问的linux系统中的访问
对象，所述主体通过所述访问行为对所述客体进行访问；第一确定模块，用于在确定所述客体属于被保护客体的情况下，确定所述主体是否具有所述客体的访问权限，其中，所述被保护客体表示具有访问权限限制的客体；第二确定模块，用于在所述主体具有所述客体的所述访问权限的情况下，确定所述访问行为是否被访问规则允许，其中，所述访问规则为所述主体能够对所述客体执行的访问行为；执行模块，用于在所述访问行为被所述访问规则允许的情况下，执行所述访问行为，以访问所述linux系统中的所述客体。9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被处理器执行时实现所述权利要求1至7任一项中所述的方法的步骤。10.一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现所述权利要求1至7任一项中所述的方法的步骤。

技术总结
本申请实施例提供了一种Linux系统的访问方法、访问装置和电子设备，其中，该方法包括：在接收到访问指令的情况下，获取访问行为的客体与主体，其中，访问指令由访问行为发出，客体为访问行为所要访问的Linux系统中的访问对象，主体通过访问行为对客体进行访问；在确定客体属于被保护客体的情况下，确定主体是否具有客体的访问权限；在主体具有客体的访问权限的情况下，确定访问行为是否被访问规则允许；在访问行为被访问规则允许的情况下，执行访问行为，以访问Linux系统中的客体。通过本申请，解决了Linux系统的访问配置复杂的问题，进而达到了在保证系统安全性的前提下简化Linux系统的访问配置的效果。统的访问配置的效果。统的访问配置的效果。


技术研发人员：范益
受保护的技术使用者：苏州浪潮智能科技有限公司
技术研发日：2023.04.14
技术公布日：2023/7/12