CN106293875A - 一种Docker容器的创建方法和创建系统 - Google Patents

Abstract

本发明提供一种Docker容器的创建方法和创建系统。该Docker容器的创建方法包括：为Docker容器中的镜像定义强制访问控制策略，以使开启Docker容器中的进程时使用强制访问控制策略；在Docker容器创建时，将强制访问控制策略嵌入镜像中的元数据中。该Docker容器的创建方法能使进程中运行镜像时能使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

Description

一种Docker容器的创建方法和创建系统

技术领域

本发明涉及通信技术领域，具体地，涉及一种Docker容器的创建方法和创建系统。

背景技术

目前，Linux操作系统中，所有容器运行的是相同的强制访问控制类型(即SELinux类型，如svirt_lxc_net_t)，该类别允许所有网络端口都能处于监听状态，也允许所有网络端口都能对外发起连接。对于容器而言，例如，在一个容器中运行某个服务程序，一旦该服务程序被成功入侵，该服务程序进程将会连接任何网络端口并成为制造垃圾信息的机器人，也可能会通过网络攻击其他宿主机和容器，这便为容器留下了不可否认的安全问题。

Docker容器的安全问题本质上就是容器技术的安全性问题，安全性问题90％以上可以归结为隔离性问题，Docker容器的隔离性主要运用Namespace技术。Namespace技术是Linux操作系统提供的一种内核级别环境隔离的方法。但是，虽然Docker容器可通过Namespace的方式分隔出看似是独立的空间，然而Linux操作系统内核却不能通过Namespace的方式分隔，所以即使Docker容器具有多个独立的空间(Container)，但由于所有的Linux操作系统调用其实都是通过主机的内核处理，所以最终还是会为Docker容器留下安全隐患。

发明内容

本发明针对现有技术中存在的上述技术问题，提供一种Docker容器的创建方法和创建系统。该Docker容器的创建方法能使进程中运行镜像时能使用该强制访问控制策略，从而避免了 主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

本发明提供一种Docker容器的创建方法，包括：

为所述Docker容器中的镜像定义强制访问控制策略，以使开启所述Docker容器中的进程时使用所述强制访问控制策略；

在所述Docker容器创建时，将所述强制访问控制策略嵌入所述镜像中的元数据中。

优选地，所述为所述Docker容器中的镜像定义强制访问控制策略包括：

根据所述镜像的功能为所述强制访问控制策略定义名称；

定义所述镜像的强制访问控制类型；

定义所述镜像的强制访问控制类型的类型权限上界；

为所述镜像的强制访问控制类型定义名称；

定义所述镜像的强制访问控制规则。

优选地，所述镜像的强制访问控制类型的类型权限上界包括svirt_lxc_net_t。

优选地，所述开启所述Docker容器中的进程时使用所述强制访问控制策略包括：

当开启所述Docker容器中的进程时，所述进程按照所述强制访问控制规则执行可执行文件，包括：

当所述进程的类型和所述可执行文件的类型均属于系统策略中定义的类型集合时，所述进程不能执行所述可执行文件；

当所述进程的类型属于所述系统策略中定义的类型集合，且所述可执行文件的类型属于所述强制访问控制策略中定义的类型集合时，判断所述进程的类型权限是否低于所述强制访问控制类型的类型权限上界，如果是，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；否则，所述进程不能执行所述可执行文件，且所述进程的类型不能切换为所述默认类型；

当所述进程的类型属于所述强制访问控制策略中定义的类型集合，且所述可执行文件的类型属于所述系统策略中定义的类型集合时，判断所述可执行文件的类型权限是否低于所述强制访问控制类型的类型权限上界；如果是，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；否则，所述进程不能执行所述可执行文件，且所述进程的类型不能切换为所述默认类型；

当所述进程的类型和所述可执行文件的类型均属于所述强制访问控制策略中定义的类型集合时，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；

其中，所述系统策略中定义的类型集合为系统定义的除所述Docker容器以外的所述系统中的其他进程和文件的类型集合；所述强制访问控制策略中定义的类型集合为给所述Docker容器中的镜像定义的类型集合。

本发明还提供一种Docker容器的创建系统，包括：

定义模块，用于为所述Docker容器中的镜像定义强制访问控制策略，以使开启所述Docker容器中的进程时使用所述强制访问控制策略；

嵌入模块，用于在所述Docker容器创建时，将所述强制访问控制策略嵌入所述镜像中的元数据中。

优选地，所述定义模块包括：

第一定义单元，用于根据所述镜像的功能为所述强制访问控制策略定义名称；

第二定义单元，用于定义所述镜像的强制访问控制类型；

第三定义单元，用于定义所述镜像的强制访问控制类型的类型权限上界；

第四定义单元，用于为所述镜像的强制访问控制类型定义名称；

第五定义单元，用于定义所述镜像的强制访问控制规则。

优选地，所述镜像的强制访问控制类型的类型权限上界包括 svirt_lxc_net_t。

优选地，所述定义模块用于在开启所述Docker容器中的进程时，使所述进程按照所述强制访问控制规则执行可执行文件；

所述定义模块还用于在所述进程的类型和所述可执行文件的类型均属于系统策略中定义的类型集合时，使所述进程不能执行所述可执行文件；

所述定义模块还用于在所述进程的类型属于所述系统策略中定义的类型集合，且所述可执行文件的类型属于所述强制访问控制策略中定义的类型集合时，判断所述进程的类型权限是否低于所述强制访问控制类型的类型权限上界，并根据判断结果确定所述进程是否能执行所述可执行文件和所述进程的类型是否能切换为默认类型；

所述定义模块还用于在所述进程的类型属于所述强制访问控制策略中定义的类型集合，且所述可执行文件的类型属于所述系统策略中定义的类型集合时，判断所述可执行文件的类型权限是否低于所述强制访问控制类型的类型权限上界，并根据判断结果确定所述进程是否能执行所述可执行文件和所述进程的类型是否能切换为默认类型；

所述定义模块还用于在所述进程的类型和所述可执行文件的类型均属于所述强制访问控制策略中定义的类型集合时，使所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；

其中，所述系统策略中定义的类型集合为系统定义的除所述Docker容器以外的所述系统中的其他进程和文件的类型集合；所述强制访问控制策略中定义的类型集合为给所述Docker容器中的镜像定义的类型集合。

本发明的有益效果：本发明所提供的Docker容器的创建方法，通过为Docker容器中的镜像提供定制的强制访问控制策略，能使进程中运行镜像时能使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker 容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

本发明所提供的Docker容器的创建系统，通过设置定义模块和嵌入模块，能为Docker容器中的镜像提供定制的强制访问控制策略，以使进程中运行镜像时能使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

附图说明

图1为本发明实施例1中Docker容器的创建方法的流程图；

图2为本发明实施例2中Docker容器中的进程执行可执行文件时遵循的强制访问控制规则；

图3为本发明实施例3中Docker容器的创建系统的原理框图。

其中的附图标记说明：

1.定义模块；11.第一定义单元；12.第二定义单元；13.第三定义单元；14.第四定义单元；15.第五定义单元；2.嵌入模块。

具体实施方式

为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明所提供的一种Docker容器的创建方法和创建系统作进一步详细描述。

实施例1：

本实施例提供一种Docker容器的创建方法，如图1所示，包括：

步骤S1：为Docker容器中的镜像定义强制访问控制策略， 以使开启Docker容器中的进程时使用强制访问控制策略。

步骤S2：在Docker容器创建时，将强制访问控制策略嵌入镜像中的元数据中。

该Docker容器的创建方法通过为Docker容器中的镜像提供定制的强制访问控制策略，能使进程中运行镜像时能使用该强制访问控制策略，从而避免主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

实施例2：

本实施例提供一种Docker容器的创建方法，包括：

步骤S1：为Docker容器中的镜像定义强制访问控制策略，以使开启Docker容器中的进程时使用强制访问控制策略。

在该步骤中，为Docker容器中的镜像定义强制访问控制策略包括：

步骤S11：根据镜像的功能为强制访问控制策略定义名称。

如：policy_module(docker_apache，1.0)，即定义强制访问控制策略的名称为docker_apache，表示Docker容器中运行的是apache服务程序。

步骤S12：定义镜像的强制访问控制类型。

如virt_sandbox_domain_template(httpd_t)，即定义镜像的强制访问控制类型为httpd_t。

步骤S13：定义镜像的强制访问控制类型的类型权限上界。

本实施例中，镜像的强制访问控制类型的类型权限上界包括svirt_lxc_net_t。如typebounds http_t svirt_lxc_net_t，即定义镜像的强制访问控制类型的类型权限上界为svirt_lxc_net_t。

步骤S14：为镜像的强制访问控制类型定义名称。

如type http_exec_t，即为镜像的强制访问控制类型定义 名称为http_exec_t。

步骤S15：定义镜像的强制访问控制规则。

该步骤是为了在开启Docker容器中的进程时使用上述强制访问控制策略，即当开启Docker容器中的进程时，该进程按照定义的强制访问控制规则执行可执行文件，具体包括：如图2中所示，

当进程的类型和可执行文件的类型均属于系统策略中定义的类型集合时，进程不能执行可执行文件。

当进程的类型属于系统策略中定义的类型集合，且可执行文件的类型属于强制访问控制策略中定义的类型集合时，判断进程的类型权限是否低于强制访问控制类型的类型权限上界；如果是，进程能执行可执行文件，且进程的类型能切换为默认类型；否则，进程不能执行可执行文件，且进程的类型不能切换为默认类型。

当进程的类型属于强制访问控制策略中定义的类型集合，且可执行文件的类型属于系统策略中定义的类型集合时，判断可执行文件的类型权限是否低于强制访问控制类型的类型权限上界；如果是，进程能执行可执行文件，且进程的类型能切换为默认类型；否则，进程不能执行可执行文件，且进程的类型不能切换为默认类型。

当进程的类型和可执行文件的类型均属于强制访问控制策略中定义的类型集合时，进程能执行可执行文件，且进程的类型能切换为默认类型。

其中，系统策略中定义的类型集合为系统定义的除Docker容器以外的系统中的其他进程和文件的类型集合；强制访问控制策略中定义的类型集合为给Docker容器中的镜像定义的类型集合。本实施例中的系统如Linux操作系统。

需要说明的是，默认类型是指能执行可执行文件的进程切换到的类型，本发明中对默认类型的具体类型不做限定。

本实施例中将强制访问控制规则定义在Docker容器的镜像 中，在系统调用或访问Docker容器中的进程时，直接按照该强制访问控制规则运行即可，无需再实时对进程和可执行文件的类型进行判断和切换，从而简化了系统调用或访问Docker容器中的进程时的类型判断和切换过程，同时还避免了系统在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性。

下面举例说明Docker容器中的进程按照定义的强制访问控制规则执行可执行文件时的类型切换格式：

类型切换的完整格式为：

Type_transition source_type target_type：process default_type；其中，source_type表示进程的类型，target_type表示可执行文件的类型，default_type表示能执行可执行文件的进程切换到的类型。

例如：类型切换的语句为：type_transition svirt_lxc_net_t http_exec_t：process httpd_t；其意义表示当类型为svirt_lxc_net_t的进程执行类型为http_exec_t的可执行文件时，类型为svirt_lxc_net_t的进程能切换为类型为httpd_t的进程。

步骤S2：在Docker容器创建时，将强制访问控制策略嵌入镜像中的元数据中。

该步骤中，Docker容器支持通过LABEL指令给一个镜像增加元信息，本实施例通过在创建镜像时，让Docker容器镜像维护者在镜像的元数据中写入强制访问控制策略，从而加强了Docker容器的安全性。

实施例1-2的有益效果：实施例1-2所提供的Docker容器的创建方法，通过为Docker容器中的镜像提供定制的强制访问控制策略，能使进程中运行镜像时能使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问 Docker容器中的进程时的强制访问控制过程。

实施例3：

本实施例提供一种Docker容器的创建系统，如图3所示，包括：定义模块1，用于为Docker容器中的镜像定义强制访问控制策略，以使开启Docker容器中的进程时使用强制访问控制策略。嵌入模块2，用于在Docker容器创建时，将强制访问控制策略嵌入镜像中的元数据中。

该Docker容器的创建系统通过设置定义模块1和嵌入模块2，能为Docker容器中的镜像提供定制的强制访问控制策略，以使进程中运行镜像时能使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

本实施例中，定义模块1包括：第一定义单元11，用于根据镜像的功能为强制访问控制策略定义名称。第二定义单元12，用于定义镜像的强制访问控制类型。第三定义单元13，用于定义镜像的强制访问控制类型的类型权限上界。第四定义单元14，用于为镜像的强制访问控制类型定义名称。第五定义单元15，用于定义镜像的强制访问控制规则。

其中，镜像的强制访问控制类型的类型权限上界包括svirt_lxc_net_t。

本实施例中，定义模块1用于在开启Docker容器中的进程时，使进程按照强制访问控制规则执行可执行文件。定义模块1还用于在进程的类型和可执行文件的类型均属于系统策略中定义的类型集合时，使进程不能执行可执行文件。定义模块1还用于在进程的类型属于系统策略中定义的类型集合，且可执行文件的类型属于强制访问控制策略中定义的类型集合时，判断进程的类型权限是否低于强制访问控制类型的类型权限上界，并根据判 断结果确定进程是否能执行可执行文件和进程的类型是否能切换为默认类型。定义模块1还用于在进程的类型属于强制访问控制策略中定义的类型集合，且可执行文件的类型属于系统策略中定义的类型集合时，判断可执行文件的类型权限是否低于强制访问控制类型的类型权限上界，并根据判断结果确定进程是否能执行可执行文件和进程的类型是否能切换为默认类型。定义模块1还用于在进程的类型和可执行文件的类型均属于强制访问控制策略中定义的类型集合时，使进程能执行可执行文件，且进程的类型能切换为默认类型。

其中，系统策略中定义的类型集合为系统定义的除Docker容器以外的系统中的其他进程和文件的类型集合；强制访问控制策略中定义的类型集合为给Docker容器中的镜像定义的类型集合。

本实施例中的系统如Linux操作系统。

需要说明的是，默认类型是指能执行可执行文件的进程切换到的类型，本发明中对默认类型的具体类型不做限定。

本实施例中通过定义模块1将强制访问控制规则定义在Docker容器的镜像中，在系统调用或访问Docker容器中的进程时，直接按照该强制访问控制规则运行即可，无需再实时对进程和可执行文件的类型进行判断和切换，从而简化了系统调用或访问Docker容器中的进程时的类型判断和切换过程，同时还避免了系统在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性。

本实施例中，嵌入模块2通过Docker容器支持的LABEL指令给一个镜像增加元信息，本实施例通过在创建镜像时，在镜像的元数据中写入强制访问控制策略，从而加强了Docker容器的安全性。

实施例3的有益效果：实施例3中所提供的Docker容器的创建系统，通过设置定义模块和嵌入模块，能为Docker容器中的镜像提供定制的强制访问控制策略，以使进程中运行镜像时能 使用该强制访问控制策略，从而避免了主机内核(如Linux操作系统)在不同的系统调用中运行Docker容器中的进程时对Docker容器的安全形成威胁，加强了Docker容器的安全性；同时还简化了系统调用或访问Docker容器中的进程时的强制访问控制过程。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (8)

1.一种Docker容器的创建方法，其特征在于，包括：

为所述Docker容器中的镜像定义强制访问控制策略，以使开启所述Docker容器中的进程时使用所述强制访问控制策略；

在所述Docker容器创建时，将所述强制访问控制策略嵌入所述镜像中的元数据中。

2.根据权利要求1所述的Docker容器的创建方法，其特征在于，所述为所述Docker容器中的镜像定义强制访问控制策略包括：

根据所述镜像的功能为所述强制访问控制策略定义名称；

定义所述镜像的强制访问控制类型；

定义所述镜像的强制访问控制类型的类型权限上界；

为所述镜像的强制访问控制类型定义名称；

定义所述镜像的强制访问控制规则。

3.根据权利要求2所述的Docker容器的创建方法，其特征在于，所述镜像的强制访问控制类型的类型权限上界包括svirt_lxc_net_t。

4.根据权利要求2所述的Docker容器的创建方法，其特征在于，所述开启所述Docker容器中的进程时使用所述强制访问控制策略包括：

当开启所述Docker容器中的进程时，所述进程按照所述强制访问控制规则执行可执行文件，包括：

当所述进程的类型和所述可执行文件的类型均属于系统策略中定义的类型集合时，所述进程不能执行所述可执行文件；

当所述进程的类型属于所述系统策略中定义的类型集合，且所述可执行文件的类型属于所述强制访问控制策略中定义的类型集合时，判断所述进程的类型权限是否低于所述强制访问控制类型的类型权限上界，如果是，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；否则，所述进程不能执行所述可执行文件，且所述进程的类型不能切换为所述默认类型；

当所述进程的类型属于所述强制访问控制策略中定义的类型集合，且所述可执行文件的类型属于所述系统策略中定义的类型集合时，判断所述可执行文件的类型权限是否低于所述强制访问控制类型的类型权限上界；如果是，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；否则，所述进程不能执行所述可执行文件，且所述进程的类型不能切换为所述默认类型；

当所述进程的类型和所述可执行文件的类型均属于所述强制访问控制策略中定义的类型集合时，所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；

其中，所述系统策略中定义的类型集合为系统定义的除所述Docker容器以外的所述系统中的其他进程和文件的类型集合；所述强制访问控制策略中定义的类型集合为给所述Docker容器中的镜像定义的类型集合。

5.一种Docker容器的创建系统，其特征在于，包括：

定义模块，用于为所述Docker容器中的镜像定义强制访问控制策略，以使开启所述Docker容器中的进程时使用所述强制访问控制策略；

嵌入模块，用于在所述Docker容器创建时，将所述强制访问控制策略嵌入所述镜像中的元数据中。

6.根据权利要求5所述的Docker容器的创建系统，其特征在于，所述定义模块包括：

第一定义单元，用于根据所述镜像的功能为所述强制访问控制策略定义名称；

第二定义单元，用于定义所述镜像的强制访问控制类型；

第三定义单元，用于定义所述镜像的强制访问控制类型的类型权限上界；

第四定义单元，用于为所述镜像的强制访问控制类型定义名称；

第五定义单元，用于定义所述镜像的强制访问控制规则。

7.根据权利要求6所述的Docker容器的创建系统，其特征在于，所述镜像的强制访问控制类型的类型权限上界包括svirt_lxc_net_t。

8.根据权利要求6所述的Docker容器的创建系统，其特征在于，所述定义模块用于在开启所述Docker容器中的进程时，使所述进程按照所述强制访问控制规则执行可执行文件；

所述定义模块还用于在所述进程的类型和所述可执行文件的类型均属于系统策略中定义的类型集合时，使所述进程不能执行所述可执行文件；

所述定义模块还用于在所述进程的类型属于所述系统策略中定义的类型集合，且所述可执行文件的类型属于所述强制访问控制策略中定义的类型集合时，判断所述进程的类型权限是否低于所述强制访问控制类型的类型权限上界，并根据判断结果确定所述进程是否能执行所述可执行文件和所述进程的类型是否能切换为默认类型；

所述定义模块还用于在所述进程的类型属于所述强制访问控制策略中定义的类型集合，且所述可执行文件的类型属于所述系统策略中定义的类型集合时，判断所述可执行文件的类型权限是否低于所述强制访问控制类型的类型权限上界，并根据判断结果确定所述进程是否能执行所述可执行文件和所述进程的类型是否能切换为默认类型；

所述定义模块还用于在所述进程的类型和所述可执行文件的类型均属于所述强制访问控制策略中定义的类型集合时，使所述进程能执行所述可执行文件，且所述进程的类型能切换为默认类型；

其中，所述系统策略中定义的类型集合为系统定义的除所述Docker容器以外的所述系统中的其他进程和文件的类型集合；所述强制访问控制策略中定义的类型集合为给所述Docker容器中的镜像定义的类型集合。