CN114003344A - 面向Docker的强制访问控制安全策略自动生成方法及系统 - Google Patents

面向Docker的强制访问控制安全策略自动生成方法及系统 Download PDF

Info

Publication number
CN114003344A
CN114003344A CN202111288781.5A CN202111288781A CN114003344A CN 114003344 A CN114003344 A CN 114003344A CN 202111288781 A CN202111288781 A CN 202111288781A CN 114003344 A CN114003344 A CN 114003344A
Authority
CN
China
Prior art keywords
access control
security policy
mandatory access
security
new
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CN202111288781.5A
Other languages
English (en)
Inventor
黄泽恒
黄戎林
张锦星
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Changsha Aurora Allianz Information Technology Co ltd
Original Assignee
Changsha Aurora Allianz Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Changsha Aurora Allianz Information Technology Co ltd filed Critical Changsha Aurora Allianz Information Technology Co ltd
Priority to CN202111288781.5A priority Critical patent/CN114003344A/zh
Publication of CN114003344A publication Critical patent/CN114003344A/zh
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种面向Docker的强制访问控制安全策略自动生成方法及系统，本发明包括：感知宿主机上的容器运行，如果感知到目标容器中有新的应用/服务被安装，则针对新的应用/服务生成对应的强制访问控制安全配置文件；将新的应用/服务生成对应的强制访问控制安全配置文件与目标容器现有的安全策略进行合并，得到目标容器的新的强制访问控制安全配置文件；基于新的强制访问控制安全配置文件动态更新目标容器现有的安全策略。本发明能够实现在Docker场景下的强制访问控制安全策略的自动生成，支持安全策略的动态更新，有助于提升Docker的安全性。

Description

面向Docker的强制访问控制安全策略自动生成方法及系统
技术领域
本发明涉及计算机操作系统领域的访问控制技术，具体涉及一种面向Docker的强制访问控制安全策略自动生成方法及系统。
背景技术
云计算因其计算能力、高可靠性和高可扩展性而得到广泛应用。虚拟化作为云计算的基础，通过软件管理和计算机硬件资源的重新分配，大大提高了计算机资源的利用率。作为一种新兴的虚拟化解决方案，Docker直接在主机内核上运行，这使得它比传统的虚拟化方法更轻、更高效。但是，由于Docker中的资源隔离不如虚拟机那么彻底，它也给Docker带来了安全问题，阻碍了实际应用中容器技术的发展。
为了解决Docker容器的安全问题，Docker中一直试图采取各种预防性安全措施。目前主要的防护方法是将强制访问控制框架(如SELinux和AppArmor等)应用到Docker容器中来增强Docker安全性。采用这种防护方法的关键是针对不同的Docker容器编写合适的安全策略。目前，强制访问控制安全策略主要依赖安全专家手工编辑生成，已有的辅助工具，如AppArmor工具集，也仅仅简化了行为日志采集的环节。此外，由于强制访问控制安全策略涉及到系统范围的主客体及其运行行为，复杂度很高，造成安全策略的生成需要大量的人工编程和安全专家决策的介入。在Docker环境中，由于Docker内部可能运行多个应用，而强制访问控制机制又把Docker视为一个主体(进程)，不能对Docker内部的应用进行细粒度分析和访问控制，进一步增加了Docker容器的安全策略生成难度。
具体来说，对于Docker容器，强制访问控制策略的生成存在以下问题：首先，要生成安全策略，需要分析容器中的每个服务，但宿主机看不到服务的执行详细信息。其次，由于Docker的资源独立性，Docker容器的文件系统与宿主机的文件系统并不完全一致，用于限制在宿主机上的相应服务的安全策略不能直接在Docker容器上使用。第三，现有的关于为Docker容器生成强制访问控制安全策略的研究通常需要使用SystemTap或auditd来收集容器行为数据，需要大量的额外的工作，而且难以收集完整的容器行为数据。
综上所述，目前Docker容器的安全策略生成困难、对Docker容器的动态变化适应性较差，迫切需要自动化的方法来解决该难题。
发明内容
本发明要解决的技术问题：针对现有技术的上述问题，本发明提供一种面向Docker的强制访问控制安全策略自动生成方法及系统，本发明能够实现在Docker场景下的强制访问控制安全策略的自动生成，支持安全策略的动态更新，有助于提升Docker的安全性。
为了解决上述技术问题，本发明采用的技术方案为：
一种面向Docker的强制访问控制安全策略自动生成方法，包括：
1)感知宿主机上的容器运行，如果感知到目标容器中有新的应用/服务被安装，则跳转至下一步；
2)针对新的应用/服务生成对应的强制访问控制安全配置文件；
3)将新的应用/服务生成对应的强制访问控制安全配置文件与目标容器现有的安全策略进行合并，得到目标容器的新的强制访问控制安全配置文件；
4)基于新的强制访问控制安全配置文件动态更新目标容器现有的安全策略。
可选地，步骤1)中感知宿主机上的容器运行是指在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息。
可选地，所述在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息包括：
1.1)根据目标容器的Dockerfile文件的第一条命令获取目标容器的基础镜像；
1.2)根据目标容器的基础镜像判断目标容器的类型；
1.3)根据目标容器的类型确定在宿主机上执行的包查询命令；
1.4)通过执行确定的包查询命令获取目标容器安装的应用/服务信息；
1.5)过滤掉安全策略生成无关的应用/服务信息。
可选地，步骤2)中新的应用/服务生成对应的强制访问控制安全配置文件是指预先将新的应用/服务在单机场景下经过安全性测试的强制访问控制安全配置文件。
可选地，所述经过安全性测试的强制访问控制安全配置文件包括保留网络访问、capability和对主应用程序的执行权限，再额外增加拒绝访问/sys和/proc目录的策略。
可选地，步骤3)包括：
3.1)创建一个用于存放合并后得到的新安全策略的集合Policiesnew和用于存放所有已经在新安全策略集合中对象的集合objectset，初始化时这两个集合都为空；
3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中，并将原安全策略中所有已经处理过的对象添加到集合objectset中；
3.3)遍历新的应用/服务生成对应的强制访问控制安全配置文件中的安全策略，如果遍历得到的当前安全策略的对象并未在集合objectset中，则合并后得到的新安全策略集合Policiesnew中并未有该对象相应的安全策略，跳转步骤3.4)；否则说明集合Policiesnew中已经有对该对象进行访问控制的安全策略，跳转步骤3.5)；
3.4)依据该安全策略更新集合objectset和集合Policiesnew；
3.5)判断并合并对该对象的访问权限，依据合并后的权限更新集合Policiesnew作为目标容器的新的强制访问控制安全配置文件。
可选地，步骤3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中时，如果安全策略是文件类型的，那么就添加策略中路径客体部分；而如果安全策略是权能或者网络类型的，那么就添加整条策略。
可选地，所述强制访问控制安全策略是指AppArmor强制访问控制安全机制或SeLinux强制访问控制安全机制的安全策略。
此外，本发明还提供一种面向Docker的强制访问控制安全策略自动生成系统，包括相互连接的微处理器和存储器，该微处理器被编程或配置以执行所述面向Docker的强制访问控制安全策略自动生成方法的步骤。
此外，本发明还提供一种计算机可读存储介质，该计算机可读存储介质中存储有被编程或配置以执行所述面向Docker的强制访问控制安全策略自动生成方法的计算机程序。
和现有技术相比，本发明具有下述优点：
1、本发明实现了Docker容器的强制访问控制安全策略自动生成。本发明可以感知宿主机上的容器运行，如果感知到目标容器的应用/服务，则针对该应用/服务生成对应的强制访问控制安全配置文件(安全策略)，因此本发明提供了Docker场景下的强制访问控制安全策略自动生成能力，解决了需要安全专家大量工作编辑安全策略的问题，提升了强制访问控制机制用于Docker容器防护的安全性和便利性。
2、本发明支持根据Docker容器的动态改变，实现强制访问控制安全策略的自动动态更新。本发明可以感知宿主机上的容器运行，如果感知到目标容器中有新的应用/服务被安装，则针对新的应用/服务生成对应的强制访问控制安全配置文件；将新的应用/服务生成对应的强制访问控制安全配置文件与目标容器现有的安全策略进行合并，得到目标容器的新的强制访问控制安全配置文件；基于新的强制访问控制安全配置文件动态更新目标容器现有的安全策略，因此本发明提供了针对Docker容器的动态改变，实现新的强制访问控制安全策略自动生成与动态更新的能力，有助于提升Docker的安全性。
3、本发明并不受操作系统版本的限制，可用于对不同版本的Linux内核的操作系统实现自动生成策略，对AppArmor、SeLinux等强制访问控制安全机制的使用带来了很大的便利。
综述所述，本发明解决了Docker容器的强制访问控制安全策略自动生成难题，本发明中提出的面向Docker的强制访问控制安全策略自动生成方法、针对容器动态改变的安全策略自动动态更新方法等都具有创新性，相比传统安全策略管理方式优势明显，可以显著提升强制访问控制机制用于Docker容器防护的安全性和便利性。
附图说明
图1为本发明实施例方法的基本流程示意图。
图2为本发明实施方法的详细实施流程图。
图3为本发明实施方法的基本原理架构示意图。
图4是本发明实施中感知模块流程示意图。
图5是本发明实施中合并模块的工作流程图。
具体实施方式
下文将以AppArmor强制访问控制为例，对本发明面向Docker的强制访问控制安全策略自动生成方法及系统进行进一步的详细说明。需要说明的是，本发明面向Docker的强制访问控制安全策略自动生成方法及系统并不依赖于特定的强制访问控制，强制访问控制不仅可以为AppArmor强制访问控制，还可以为SeLinux强制访问控制安全机制或者其他强制访问控制安全机制，对应地，强制访问控制安全策略可以为AppArmor强制访问控制安全机制、或SeLinux强制访问控制安全机制的安全策略、或者其他强制访问控制安全机制的安全策略。
如图1所示，本实施例面向Docker的强制访问控制安全策略自动生成方法包括：
1)感知宿主机上的容器运行，如果感知到目标容器中有新的应用/服务被安装，则跳转至下一步；
2)针对新的应用/服务生成对应的强制访问控制安全配置文件；
3)将新的应用/服务生成对应的强制访问控制安全配置文件与目标容器现有的安全策略进行合并，得到目标容器的新的强制访问控制安全配置文件；
4)基于新的强制访问控制安全配置文件动态更新目标容器现有的安全策略。
如图2所示，本实施例中强制访问控制安全策略是指AppArmor强制访问控制安全机制。以AppArmor为例，实现面向Docker的强制访问控制安全策略自动生成方法包括：1)在宿主机上部署感知模块获取容器内部的操作细节；2)对于宿主机上的每一个服务，基于单机场景下合适该服务的AppArmor安全配置文件，通过推理模块自适应修改该安全配置文件，得到该服务在容器场景下的AppArmor安全策略；3)通过合并模块，将宿主机上每一个服务在容器场景下的AppArmor安全策略进行合并，得到该容器的AppArmor安全配置文件；4)通过动态更新机制，随着容器中已安装的应用程序的变化，自适应地修改安全策略。
本实施例中，步骤1)中感知宿主机上的容器运行是指在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息。
本实施例中，在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息包括：
1.1)根据目标容器的Dockerfile文件(容器的脚本文件)的第一条命令获取目标容器的基础镜像；
1.2)根据目标容器的基础镜像判断目标容器的类型；
1.3)根据目标容器的类型确定在宿主机上执行的包查询命令；
1.4)通过执行确定的包查询命令获取目标容器安装的应用/服务信息；
1.5)过滤掉安全策略生成无关的应用/服务信息。
本实施例中，步骤2)中新的应用/服务生成对应的强制访问控制安全配置文件是指预先将新的应用/服务在单机场景下经过安全性测试的强制访问控制安全配置文件。
本实施例中，经过安全性测试的强制访问控制安全配置文件包括保留网络访问、Capabilities和对主应用程序的执行权限，再额外增加拒绝访问/sys和/proc目录的策略。其中，Capabilities特性用于在Linux内核中划分特权集，以便进程可以只分配“执行特定功能”的特权。在引入Capabilities特性前，如果进程需要使用网络，则必须使用root来运行，通常是sudo或者添加suid，那么普通用户在使用ping(ICMP命令，用于测试网络延时)时，ping就可以运行任何特权。引入Capabilities特性后，可以通过给ping应用添加CAP_NET_RAW特权集，使其具有使用网络的特权集，而不具备其他特权集。
本实施例中，步骤3)包括：
3.1)创建一个用于存放合并后得到的新安全策略的集合Policiesnew和用于存放所有已经在新安全策略集合中对象的集合objectset，初始化时这两个集合都为空；
3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中，并将原安全策略中所有已经处理过的对象添加到集合objectset中；
3.3)遍历新的应用/服务生成对应的强制访问控制安全配置文件中的安全策略，如果遍历得到的当前安全策略的对象并未在集合objectset中，则合并后得到的新安全策略集合Policiesnew中并未有该对象相应的安全策略，跳转步骤3.4)；否则说明集合Policiesnew中已经有对该对象进行访问控制的安全策略，跳转步骤3.5)；
3.4)依据该安全策略更新集合objectset和集合Policiesnew；
3.5)判断并合并对该对象的访问权限，依据合并后的权限更新集合Policiesnew作为目标容器的新的强制访问控制安全配置文件。
本实施例中，步骤3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中时，如果安全策略是文件类型的，那么就添加策略中路径客体部分；而如果安全策略是权能或者网络类型的，那么就添加整条策略。
如图3所示，本实施例方法的执行模块主要包括感知模块、生成模块、更新模块三部分，其中感知模块通过容器的包管理机制获取容器的执行细节；生成模块结合Docker的特性通过推理得到应用于指定容器的安全策略；更新模块根据容器安装新服务或应用程序的需求实现安全策略的动态更新和部署。该方法以AppArmor为例，提供了Docker场景下的强制访问控制安全策略自动生成能力，并且支持安全策略的动态更新，有助于提升Docker的安全性。
如图4所示，感知模块主要包括两个应用场景：1)初次为指定容器生成安全策略时，获取容器当前内部安装的应用程序；2)已经为该容器部署了安全策略后，由于容器会动态变化，获取由于使用需求新安装的服务或者应用程序。由于Docker场景下的AppArmor安全策略是需要为每个Docker容器都构造一个单独的AppArmor安全配置文件，使得每个容器都可以处于单独的安全上下文中，从而限制容器之间的资源共享。因此为容器生成AppArmor安全策略时，需要收集容器的行为数据，而容器的行为数据与其所属的镜像和其内部必需的应用程序密切相关。因此本实施例中首先通过容器的包管理工具获取容器内部安装的应用程序。而获取Docker容器中的应用程序信息与每个容器中的包管理技术相关，不同包管理技术对应着不同的获取应用程序信息的命令，因此感知模块的步骤为：1.1)根据Dockerfile文件的第一条命令获取当前基础镜像；1.2)根据基础镜像判断当前容器的类型；本实施例中，根据基础镜像的类型将Docker容器分为基于Alpine的容器、基于Debian&Ubuntu的容器和基于RedHat&CentOS&Fedora的容器。1.3)根据容器类型决定在宿主机上执行何种包查询命令；本实施例中，如果容器的镜像是基于Alpine这种轻量级的Linux发行版，它自身提供了包管理工具apk，可以通过包管理工具apk命令来进行查询。如果要容器的镜像基于Debian&Ubuntu，应当使用dpkg命令进行查询。如果是容器的镜像是基于CentOS&RedHat&Fedora，则应当使用yum命令进行查询。1.4)通过执行包查询命令获取当前Docker容器安装的应用程序信息；
1.5)过滤掉安全策略生成无关的软件包信息。本实施中，获取完容器内部的应用程序信息后，由于容器的执行除了应用程序还会安装许多与AppArmor安全策略无关的依赖包和工具等，应该将其过滤掉。如dpkg包管理器中，section可以说明当前软件包的类型，常见的section有libs、editors、utils、httpd等，如libs则说明当前软件包是如libcap2、libaudit1和libbz2-1.0等lib库，这些软件包与AppArmor安全策略的生成过程无关，因此本实施例中将过滤掉这些安全策略生成无关的软件包信息。
如图5所示，本实施例中合并模块通过循环合并不同服务在容器场景下的安全策略，得到该容器的AppArmor安全配置文件。合并模块的步骤包括：3.1)创建一个用于存放合并后得到的新安全策略的集合Policiesnew和用于存放所有已经在新安全策略集合中对象的集合objectset，初始化时这两个集合都为空。3.2)然后将Docker容器原来所有的安全策略添加到集合Policiesnew中，并将原安全策略中所有已经处理过的对象添加到集合objectset中。其中如果安全策略是文件类型的，那么就添加策略中路径客体部分；而如果安全策略是权能或者网络类型的，那么就添加整条策略。3.3)遍历新安装服务或者应用程序需要的安全策略，如果该安全策略的对象并未在objectset中，则合并后得到的新安全策略集合Policiesnew中并未有该对象相应的安全策略，跳转步骤3.4)；否则说明集合Policiesnew中已经有对该对象进行访问控制的安全策略，跳转步骤3.5)；3.4)依据该安全策略更新集合objectset和集合Policiesnew；3.5)判断并合并对该对象的访问权限，依据合并后的权限更新集合Policiesnew。
为了防止策略数目太多，合并模块将考虑引入glob模式，即：使用通配符修改目录路径以包含一组文件或子目录。通过系统功能可以得知文件的重要程度，从而使用通配符。例如，tmp类通常存放Linux临时文件，重要程度低，如果有大量/tmp目录下文件的安全策略，我们会将其通过glob模式整理为/tmp/**。而/etc目录下通常存放的是系统管理和配置文件，重要程度高，合并模块将不使用glob模式对该类策略进行处理。
本实施例中，在使用AppArmor提升Docker安全性的过程中，安全策略以AppArmor安全配置文件的形式被保存在宿主机，容器启动时再将安全配置文件执行到容器中。由于强制访问控制的特性，安全配置文件是预先静态设置的，并不支持动态更新。但是因为容器自身是动态变化的，可以在容器运行过程中安装新的服务和应用。例如安装Nginx容器，那么在初次配置AppArmor策略时仅考虑到Nginx相关的系统资源和可用权限。如果在容器的后续使用过程中，需要新安装tcpdump、whois等应用程序，那么之前配置的AppArmor安全策略并不会对新安装应用程序的使用提供安全性保护，所以应当设计安全策略动态更新机制来动态支持Docker的安全。因此，本实施例中动态更新机制包括通过步骤1)的感知模块通过定时触发获得容器执行过程中新安装的服务或者应用程序，如果获取容器此时安装了新的服务或应用程序，就通过步骤3)的合并模块动态更新Docker的安全策略。例如，该容器为Nginx容器，已经通过步骤2)生成了该容器的安全策略A。此时容器中需要进行GPU计算，而在原本的安全策略A中并未包含GPU计算需要用到的系统资源的访问权限。因此我们将通过步骤2)获取GPU计算需要的安全策略B，通过合并模块生成用于保护可进行GPU计算的Nginx容器的安全策略C。
综上所述，本实施例方法中以AppArmor为例，实现了面向Docker的强制访问控制安全策略自动生成方法中策略生成过程主要由三个模块组成：1)感知模块。由于宿主机仅用于为容器提供运行时环境，因此不可能感知在容器内运行的应用程序的详细信息。因此，面向Docker的强制访问控制安全策略生成框架在宿主机上部署感知模块，通过容器的包管理机制获取容器中的应用程序。在当前场景中，需要获取的执行细节包括初次为容器生成AppArmor安全策略时容器中运行的应用程序和使用过程中新安装的应用程序信息；2)生成模块。当感知模块获取到了容器内部运行的应用程序后，本模块通过分析Docker的特性，对该应用程序在单机场景下生成的安全配置文件进行适应性修改，从而得到用于该Docker容器的安全策略；3)策略动态更新模块。Docker的内部经常动态变化，即在使用过程中因为使用需求会在容器中新安装服务或应用程序，因此本模块会根据Docker内部实时变化而实现策略的动态更新和部署。得到容器场景下的AppArmor安全策略文件将自动部署到系统中。之后，AppArmor通过指定该安全配置文件应用于容器来限制容器对宿主机的内核或其他资源的访问控制，从而提升Docker容器的安全性，保护操作系统。解决使用AppArmor等强制访问控制机制提升Docker容器安全性时存在的安全策略配置过程复杂、不完备的问题。而另一方面，不同于为宿主机上运行的应用程序生成的安全策略，只需要使得前期部署的策略尽可能完备(即对应用程序执行过程中所有将访问的资源都进行了访问控制)，后期几乎不需要调整策略。容器可以不断安装新的服务和应用程序，因此容器的使用是没有边界的，前期部署的安全策略无法支持不断变化的容器场景。本实施例方法设计了一个动态更新机制动态更新容器的安全策略，是的安全策略实现动态调整以适应容器的动态变化。通过初步的实验验证，在Ubuntu16.04系统上，通过本实施例可为Docker容器自动生成安全、可靠的AppArmor安全策略。因此，本实施例方法要解决的技术问题是如何在Docker场景下通过自动化策略生成的过程，从而有效地减轻手动配置AppArmor的安全策略时的复杂性和主观性，以及由于不当策略引起的安全威胁。使用本实施例方法，操作系统可以将系统资源的被访问和管理至于安全性更高的访问控制机制中，并使得访问控制策略的生成和部署过程自动化、客观化。
此外，本实施例还提供一种面向Docker的强制访问控制安全策略自动生成系统，包括相互连接的微处理器和存储器，该微处理器被编程或配置以执行前述面向Docker的强制访问控制安全策略自动生成方法的步骤。
此外，本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有被编程或配置以执行前述面向Docker的强制访问控制安全策略自动生成方法的计算机程序。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种面向Docker的强制访问控制安全策略自动生成方法，其特征在于，包括：
1)感知宿主机上的容器运行，如果感知到目标容器中有新的应用/服务被安装，则跳转至下一步；
2)针对新的应用/服务生成对应的强制访问控制安全配置文件；
3)将新的应用/服务生成对应的强制访问控制安全配置文件与目标容器现有的安全策略进行合并，得到目标容器的新的强制访问控制安全配置文件；
4)基于新的强制访问控制安全配置文件动态更新目标容器现有的安全策略。
2.根据权利要求1所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，步骤1)中感知宿主机上的容器运行是指在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息。
3.根据权利要求2所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，所述在目标容器宿主机中获取初次为目标容器生成安全策略时目标容器中运行的应用/服务和使用过程中新安装的应用/服务信息包括：
1.1)根据目标容器的Dockerfile文件的第一条命令获取目标容器的基础镜像；
1.2)根据目标容器的基础镜像判断目标容器的类型；
1.3)根据目标容器的类型确定在宿主机上执行的包查询命令；
1.4)通过执行确定的包查询命令获取目标容器安装的应用/服务信息；
1.5)过滤掉安全策略生成无关的应用/服务信息。
4.根据权利要求1所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，步骤2)中新的应用/服务生成对应的强制访问控制安全配置文件是指预先将新的应用/服务在单机场景下经过安全性测试的强制访问控制安全配置文件。
5.根据权利要求4所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，所述经过安全性测试的强制访问控制安全配置文件包括保留网络访问、capability和对主应用程序的执行权限，再额外增加拒绝访问/sys和/proc目录的策略。
6.根据权利要求1～5所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，步骤3)包括：
3.1)创建一个用于存放合并后得到的新安全策略的集合Policiesnew和用于存放所有已经在新安全策略集合中对象的集合objectset，初始化时这两个集合都为空；
3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中，并将原安全策略中所有已经处理过的对象添加到集合objectset中；
3.3)遍历新的应用/服务生成对应的强制访问控制安全配置文件中的安全策略，如果遍历得到的当前安全策略的对象并未在集合objectset中，则合并后得到的新安全策略集合Policiesnew中并未有该对象相应的安全策略，跳转步骤3.4)；否则说明集合Policiesnew中已经有对该对象进行访问控制的安全策略，跳转步骤3.5)；
3.4)依据该安全策略更新集合objectset和集合Policiesnew；
3.5)判断并合并对该对象的访问权限，依据合并后的权限更新集合Policiesnew作为目标容器的新的强制访问控制安全配置文件。
7.根据权利要求6所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，步骤3.2)将目标容器原来所有的安全策略添加到集合Policiesnew中时，如果安全策略是文件类型的，那么就添加策略中路径客体部分；而如果安全策略是权能或者网络类型的，那么就添加整条策略。
8.根据权利要求6所述的面向Docker的强制访问控制安全策略自动生成方法，其特征在于，所述强制访问控制安全策略是指AppArmor强制访问控制安全机制或SeLinux强制访问控制安全机制的安全策略。
9.一种面向Docker的强制访问控制安全策略自动生成系统，包括相互连接的微处理器和存储器，其特征在于，该微处理器被编程或配置以执行权利要求1～8中任意一项所述面向Docker的强制访问控制安全策略自动生成方法的步骤。
10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质中存储有被编程或配置以执行权利要求1～8中任意一项所述面向Docker的强制访问控制安全策略自动生成方法的计算机程序。
CN202111288781.5A 2021-11-02 2021-11-02 面向Docker的强制访问控制安全策略自动生成方法及系统 Withdrawn CN114003344A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111288781.5A CN114003344A (zh) 2021-11-02 2021-11-02 面向Docker的强制访问控制安全策略自动生成方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111288781.5A CN114003344A (zh) 2021-11-02 2021-11-02 面向Docker的强制访问控制安全策略自动生成方法及系统

Publications (1)

Publication Number Publication Date
CN114003344A true CN114003344A (zh) 2022-02-01

Family

ID=79926482

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111288781.5A Withdrawn CN114003344A (zh) 2021-11-02 2021-11-02 面向Docker的强制访问控制安全策略自动生成方法及系统

Country Status (1)

Country Link
CN (1) CN114003344A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615064A (zh) * 2022-03-15 2022-06-10 北京旋极安辰计算科技有限公司 一种对于Docker容器创建和销毁的管控方法
CN114780168A (zh) * 2022-03-30 2022-07-22 全球能源互联网研究院有限公司南京分公司 智能终端容器安全策略动态变更的方法、装置及电子设备

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615064A (zh) * 2022-03-15 2022-06-10 北京旋极安辰计算科技有限公司 一种对于Docker容器创建和销毁的管控方法
CN114780168A (zh) * 2022-03-30 2022-07-22 全球能源互联网研究院有限公司南京分公司 智能终端容器安全策略动态变更的方法、装置及电子设备
CN114780168B (zh) * 2022-03-30 2023-04-28 全球能源互联网研究院有限公司南京分公司 智能终端容器安全策略动态变更的方法、装置及电子设备

Similar Documents

Publication Publication Date Title
CN114003344A (zh) 面向Docker的强制访问控制安全策略自动生成方法及系统
RU2454705C1 (ru) Система и способ защиты компьютерного устройства от вредоносных объектов, использующих сложные схемы заражения
US9811663B2 (en) Generic unpacking of applications for malware detection
US10534915B2 (en) System for virtual patching security vulnerabilities in software containers
US8327438B2 (en) System for executing program using virtual machine monitor and method of controlling the system
US8943547B2 (en) System and method for automatically configuring application control rules
US8875165B2 (en) Computing device having a DLL injection function, and DLL injection method
US8978142B2 (en) System and method for detection of malware using behavior model scripts of security rating rules
CN108471420B (zh) 基于网络模式识别和匹配的容器安全防御方法与装置
US11175909B2 (en) Software discovery using exclusion
EP3451221B1 (en) Binary suppression and modification for software upgrades
US10528729B2 (en) Methods and systems for defending against cyber-attacks
CN113138836A (zh) 一种基于Docker容器的防逃逸蜜罐系统及其方法
KR100706176B1 (ko) 커널 취약요소를 방어하기 위한 커널 패치 방법 및 시스템
CN112883381A (zh) 基于专家系统的AppArmor安全策略自动生成方法及系统
CN112287357B (zh) 一种针对嵌入式裸机系统的控制流验证方法与系统
EP2819346B1 (en) System and method for automatically configuring application control rules
CN115688092A (zh) 终端弱管控方法、装置、电子设备及存储介质
KR101650287B1 (ko) 볼륨 guid 기반 파일 접근 제어 시스템 및 그 방법
US20190317676A1 (en) Executable memory protection
CN116484364B (zh) 一种基于Linux内核的隐藏端口检测方法及装置
WO2009083734A1 (en) Typed application deployment
Lee et al. The study of response model & mechanism against windows kernel compromises
Trapp et al. Program partitioning based on static call graph analysis for privilege separation
US20060037005A1 (en) Method and apparatus for increasing computer security

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WW01 Invention patent application withdrawn after publication

Application publication date: 20220201

WW01 Invention patent application withdrawn after publication