CN116521306A

CN116521306A - Method for enabling selinux by container and computer equipment

Info

Publication number: CN116521306A
Application number: CN202210081737.5A
Authority: CN
Inventors: 修剑锋; 李坤; 徐海林
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-01-24
Filing date: 2022-01-24
Publication date: 2023-08-01

Abstract

The embodiment of the invention provides a method and computer equipment for enabling selinux by a container. The computer device runs an operating system, which enables selinux; the method comprises the following steps: fusing the container policy and the host policy to generate a policy rule file; generating container file information and host file information of a first file in an operating system, wherein the container file information comprises a container identifier, a file system name, a file name and a container file label, and the host file information comprises the file system name, the file name and the host file label; generating a new policy rule file based on the container file information, the host file information, and the policy rule file, the new policy rule file may include the container file information and the host file information. According to the embodiment of the invention, the differentiation of the container file label and the host file label is realized through the container file information and the host file information, so that the selinux in the container can be enabled, and the forced access control of the fine granularity of the selinux authority in the container is realized.

Description

Method for enabling selinux by container and computer equipment

[ field of technology ]

The invention relates to the technical field of computers, in particular to a method for enabling safety-enhanced linux (selinux for short) by a container and computer equipment.

[ background Art ]

The Linux container essentially synthesizes a set of related processes in the system that serve the same business object, and places the synthesized processes in a namespace (namespace), where the processes in the same namespace can communicate with each other but cannot view the processes in other namespaces. Each namespace may have its own independent hostname, process ID system, inter-process communication (IPC for short), network, file system, user, etc. resources.

In the scenes of cloud mobile phones, cloud games and the like, the android system runs in a container, and the android system needs to enable selinux to ensure the safety of the system. In the related art, when a container of an android system needs to be operated to enable selinux, the difference between the container file label and the host file label of the file cannot be realized, so that the selinux in the container cannot be enabled, and further forced access control of the fine granularity of the authority of the selinux in the container cannot be realized.

[ invention ]

In view of this, the present invention provides a method and computer device for enabling selinux in a container, thereby implementing a fine-grained forced access control of selinux rights within the container.

A first aspect provides a method of container enabling selinux, the method being applied to a computer device running an operating system, the operating system enabling selinux; the method comprises the following steps:

fusing the container policy and the host policy to generate a policy rule file;

generating container file information and host file information of a first file in the operating system, wherein the container file information comprises a container identifier, a file system name, a file name and a container file label, and the host file information comprises the file system name, the file name and the host file label;

generating a new policy rule file according to the container file information, the host file information and the policy rule file, wherein the new policy rule file can comprise the container file information and the host file information.

In one possible implementation, the method further includes:

and loading the new policy rule file into the kernel.

In one possible implementation manner, the generating container file information and host file information of the first file in the operating system includes:

and generating container file information and host file information of the first file through a selinux policy language genfscon.

In one possible implementation, the file system of the first file includes a procfs file system, a sysfs file system, a debug file system, a tracefs file system, or a binder file system.

In one possible implementation, the method further includes:

acquiring a file system name and a file name of a first file to be accessed and an identification of a process corresponding to the first file to be accessed;

inquiring a file label corresponding to the obtained file system name, file name and identification from the new strategy rule file according to the obtained file system name, file name and identification;

acquiring the SID corresponding to the file tag;

generating a first security context according to the identification and the SID;

searching a second security context in the configured index node data of the first file to be accessed through the identification of the process corresponding to the first file to be accessed, wherein the second security context is the security context corresponding to the identification of the process corresponding to the first file to be accessed;

and matching the first security context with the second security context, and accessing the first file to be accessed if the matching is successful.

In one possible implementation, the method further includes:

the method comprises the steps of configuring index node data of a first file, wherein the index node data can comprise a security context corresponding to a host and a security context corresponding to at least one container, the security context corresponding to the host comprises a security context identification SID, and the security context corresponding to the container comprises the security context identification SID and a container identification.

In one possible implementation, the identifier is a container identifier, and the file tag is a container file tag; or alternatively, the process may be performed,

the mark is empty, and the file label is a host file label.

In one possible implementation, the method further includes:

determining the number N of tags to be configured of lxcfs files in a container, wherein N is a positive integer;

starting N lxcfs processes, and configuring corresponding labels for each lxcfs process;

when the container is started, determining a designated lxcfs file of a designated lxcfs process from lxcfs files of different lxcfs processes according to the labels of the lxcfs files in the container, and mounting the designated lxcfs file into the container, wherein the label corresponding to the designated lxcfs process is the label of the lxcfs file in the container, and the designated lxcfs file is the lxcfs file corresponding to the lxcfs file in the container.

A second aspect provides a computer device comprising: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions that, when executed by the computer device, cause the computer device to perform the method of the first aspect or any of the possible implementations of the first aspect of the container-enabled selinux.

A third aspect provides a computer readable storage medium comprising a stored program, wherein the program when run controls a device in which the computer readable storage medium is located to perform the method of the first aspect or any of the possible implementations of the first aspect of container enabling selinux.

A fourth aspect provides a computer program product comprising instructions which, when run on a computer or any of the at least one processors, cause the computer to perform the method of the first aspect or any of the possible implementations of the first aspect of container-enabling selinux.

In the technical scheme provided by the embodiment of the invention, the container policy and the host policy are fused to generate a policy rule file; generating container file information and host file information of a first file in the operating system, wherein the container file information comprises a container identifier, a file system name, a file name and a container file label, and the host file label comprises the file system name, the file name and the host file label; according to the container file information, the host file information and the policy rule file, a new policy rule file is generated, and the new policy rule file can comprise the container file information and the host file information.

[ description of the drawings ]

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a host and container enabled selinux in the related art;

FIG. 2 is a schematic diagram of a container enabled selinux in some embodiments;

FIG. 3 is a schematic diagram of a container-enabled selinux in other embodiments;

FIG. 4 is a schematic diagram of configuration inode data in some embodiments;

FIG. 5 is a flow diagram of a method of container enabling selinux in some embodiments;

FIG. 6 is a flow chart of a method of container enabling selinux in other embodiments;

FIG. 7 is a schematic diagram of a tag configuring an lxcfs file in some embodiments;

FIG. 8 is a flow diagram of configuring an lxcfs file tag in some embodiments;

fig. 9 is a schematic diagram of a computer device provided by some embodiments.

[ detailed description ] of the invention

For a better understanding of the technical solution of the present invention, the following detailed description of the embodiments of the present invention refers to the accompanying drawings.

It should be understood that the described embodiments are merely some, but not all, embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be understood that the term "and/or" as used herein is merely one way of describing an association of associated objects, meaning that there may be three relationships, e.g., a and/or b, which may represent: the first and second cases exist separately, and the first and second cases exist separately. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

Since embodiments of the present invention relate to the use of container-enabled selinux, related terms and related concepts to which embodiments of the present invention may relate are first described below for ease of understanding.

Operating system (operating system): the operating system is a program for managing computer hardware and software resources, and needs to handle basic transactions such as managing and configuring memory, prioritizing supply and demand of system resources, controlling input devices and output devices, operating networks, managing file systems, and the like, and also provides an operation interface for allowing a user to interact with the system, for example Windows, linux, and the like.

Operating system kernel (operating system kernel): the operating system kernel is software running at a higher privilege level in the operating system, such as a Linux kernel.

Container (container): a container is an executable unit of software that encapsulates applications, as well as libraries and dependent items, in a generic way. The container technology uses the operating system to provide a way of virtualization (e.g., in linux, i.e., nmespace and cgroup) to isolate processes and control the number of cpus, memories and disks that these container processes have access to.

Autonomous access control (DAC): the DAC manages its own object by its owner, and the owner decides whether to grant its own object access or partial access to other subjects. That is, under autonomous access control, a user can selectively share his files with other users at his own discretion.

Forced access control (MAC): MAC refers to an access control constrained by an operating system with the goal of restricting access by a subject or initiator or the ability to perform some operation on an object or target. In practice, the body is typically a process or thread, and the objects may be files, directories, TCP/UDP ports, shared memory segments, I/O devices, etc. The subject and object each have a set of security attributes. Every time a principal attempts to access an object, authorization rules are enforced by the operating system kernel, checking the security attributes and deciding whether access is available. Any operation by any principal on any object will be tested against a set of authorization rules (also called policies) to determine whether the operation is allowed.

SELinux: linux provides a Mandatory Access Control (MAC) system, under the limitations of which processes can only access those files or other resources specified in a policy.

SELinux mode of operation: a shutdown (Disable) mode in which selinux is turned off; a Permissive mode in which selinux is enabled but the security policy rules are not enforced, when the security policy rules should be denied, access is still allowed, but a message is sent to the log file indicating that access is denied; a enforcement (forcing) mode in which selinux is started and all security policy rules are enforced.

Policy and rule: SELinux defines the access rights of each subject to an object. It enforces the access allowed by the policy using a security policy (a set of rules that tell SELinux which can access and which cannot).

Access control cache (Access Vector Cache, AVC): the access rule of the checked subject to the object can be cached in AVC, and AVC can be checked to obtain the access rule when accessing next time, thereby improving the checking performance.

File context (filecontext): the configuration files of which files are marked with what kind of labels are specified by SELinux, and corresponding labels are marked on the files in the system according to the content of the filecontext files by an administrator.

Body (subject): the entity that can manipulate, access an object is generally referred to as a process.

Object (object): the resources operated and accessed by the subject may be files, directories, ports, devices, etc., and the process is sometimes also a guest.

Label (label): the policy rules define the identity to the subject or object, and SELinux controls access rights based on the tag. The Selinux labels files in several ways:

1. fs_use_xattr, in this way, the extended attribute of the file system is utilized, and the label is marked into an inode of the file system, for example, the file system is a file system supporting the extended attribute, such as ext2, ext3, xfs, btrofs, and the like, and the label information is stored in filecontext;

2. fs_use_task, mainly for sockfs and pipfs files, the tags of such files inherit from the tags (security context) of the process that created them;

3. fs_use_trans, mainly for tmpfs and devtmpfs files, the new file created requires a set of relevant transformation (transformation) rules to complete the labelling process, if there is no such rule, the label (security context) specified by the file system is used;

4. the genefscon is suitable for file systems (vfat, ntfs and the like) which do not support the expansion attribute, and pseudo file systems (proc, sysfs and the like), the labels of the files are not stored in the filecontext file, are not labels given to the files by an administrator, are defined in the strategy file, and after the strategy is loaded, the kernel accesses the corresponding files and generates the labels according to the strategy file;

Security context: an attribute of a subject or object generated by a tag is managed by a Linux kernel, each security context having a unique ID (SID), the tag and the security context being in one-to-one correspondence.

inode: a data structure in a file system is used for describing file system objects (including files, directories, device files, sockets, pipes, etc.), and each inode stores the corresponding attribute of the file and also contains a security context.

lxcfs: lxcfs are to achieve view isolation of the cgroup resources, e.g., the container limits only one cpu, then the/proc/cpu info file provided by lxcfs has only one cpu, not all cpus of the system. lxcfs also isolates/proc files diskstats, meminfo, stat, swaps, uptime, etc.

rootfs: the root file system is mounted on the file system on the root/path, the host computer is provided with the root file system, the container is also provided with the root file system, and the container provides an isolated execution environment for the container process through rootfs.

To some extent, the Linux container implements a simple virtual, allowing multiple, mutually unaware, hosts (Host) to run simultaneously. In addition, in order to limit the use of the physical resources by the namespaces, certain restrictions need to be made on resources such as a central processing unit (central processing unit, CPU), a memory, an Input/Output (i.e., IO), etc. that can be used by the processes, which is a control group (i.e., cgroup) technology. In short, the Linux kernel completes isolation through the namespace and resource restriction through the control group, so the namespace and control group combine to form the underlying technology of the container.

Since the current linux kernel does not support the namespace technology of selinux, that is, the whole system can only have one selinux policy, selinuxfs, selinux running mode and one file can only have one label, the use of selinux in a container scene is limited. In this case, in order to enable selinux in a container and improve system security, a traditional idea is to label processes and files in the container with one or a limited number of labels, so as to realize coarse-grained authority control. However, the above solutions all have the following problems: 1. for pseudo file systems shared by containers such as proc and sysfs and a host, the labels of the containers and the host can only be consistent; 2. for lxcfs for containers, only one tag can be used for the entire file system. So even if selinux is enabled in the container, only coarse-grained rights control can be achieved, and the role of selinux is limited.

Particularly, when the android system is required to be operated in the container under the Application scenes such as the cloud mobile phone and the cloud game, the android system forcedly enables the selinux mechanism, and the policy rule file comprises thousands of rules, and many huge rules and labels corresponding to the files conflict with the rules at the host side and the labels corresponding to the files, so that the selinux cannot be operated in the container for operating the android system, and the cloud mobile phone and the cloud game can be blocked by detecting a non-real machine environment by an inverse simulator of an Application program (App). From another aspect, without the rights control of selinux, malware may attack other applications in the container, even escape to the host, illegally access resources on the host, and pose a significant threat to host security.

FIG. 1 is a schematic diagram of a related art host and container enabled selinux, as shown in FIG. 1, a body architecture of an Operating System (OS) of a computer device includes a user state and a kernel state, the user state includes a host and a container, the kernel state includes a selinux module and an object, and communication can be performed between the user state and the kernel state. The host includes policy & rule (filecontext) files, filecontext files, processes, and lxcfs processes, and the container includes processes. The selinux module comprises a selinux file system, a security server, a selinux abstract layer, an access control cache (Access Vector Cache, abbreviated as AVC) and a log. The host stores the policy rule file to the security server through the selinux file system, and the process of the host or the process of the container uses system call and autonomous access control (Discretionary Access Control, abbreviated as DAC) to access the object through the selinux module. In the selinux module, a selinux abstract layer requests permission to an access control cache, the access control cache accesses an object file when judging that access is allowed according to a policy rule file inquired from a security server, and the access control cache writes a refused access record into a log when judging that access is refused according to the policy rule file. Wherein, the selinux module is used for realizing MAC.

As shown in FIG. 1, the selinux is enabled on the host first, then the selinux-enabled parameters are loaded when the container engine dock is applied, and then the dock marks corresponding labels to processes and files in the container according to the content of the/etc/selinux/targeted/contexts/lxc _contexts file. For example, the content of the lxc _contexts file is as follows:

process＝“system_u:system_r:container_t:s0”

content＝“system_u:system_r:virt_var_lib_t:s0”

file＝“system_u:object_r:container_file_t:s0”

ro_file＝“system_u:object_r:container_ro_file_t:s0”

sandbox_kvm_process＝“system_u:system_r:svirt_qemu_net_t:s0”

sandbox_lxc_process＝“system_u:system_r:container_t:s0”

the tags included in the content of the lxc _contexts file include various tags such as "system_u: system_r: container_t: s0" and "system_u: system_r: virt_var_lib_t: s0", and the types of tags are limited and fine-grained authority control is not supported.

The related art solution in fig. 1 has the following technical problems: 1) The processes in the container and the used files can only be the labels specified in the lxc _contexts file, so that the complex scene of running the android container cannot be met completely, and the android system has a great number of label types and complex policy rules. 2) The same file can only have one type of label, i.e., after the file is re-labeled in the container, the label of the file on the host is also the label of the container. For file systems such as procfs, sysfs that use selinux genfs syntax to configure labels and that are shared between the host and the container, the labels of the host and the container can only be the same, and therefore, conflicts may occur for the container to run the android system (e.g., the android system is inconsistent with the labels required by the host system for the same file), resulting in the selinux function being disabled in the container. 3) For files in the lxcfs file system, all files can only have one label, and label differentiation cannot be achieved. In the original android system, different labels and different strategies are configured for different files aiming at the files of/proc/cpu info,/proc/meminfo,/proc/stats and the like; if the android system runs in the container, the files are simulated by the lxcfs file system, and lxcfs can only be configured into one label for the whole file system, so that different labels can not be independently configured for different files under the file system. 4) The labels of the processes and files in all containers are identical.

Another related art provides an open source scheme, container-selinux, which mainly provides a filecontext file, and part of the content of the filecontext file is as follows:

the open source scheme also provides a policy rule file for the label of the container, and part of the content of the policy rule file is as follows:

allow container_runtime_domain self：capability～{sys_module}；

allow container_runtime_domain self：capability2～{mac_override mac_admin}；

allow container_runtime_domain self：cap_userns～{sys_module}；

allow container_runtime_domain self：cap2_userns～{mac_override mac_admin}；

allow container_runtime_domain self：process{getcap setcap setexec setpgid setsched signal_perms}；

allow container_runtime_domain self：netlink_route_socket rw_netlink_socket_perms；；

allow container_runtime_domain self：netlink_xfrm_socket create_netlink_socket_perms；

allow container_runtime_domain self：netlink_audit_socket create_netlink_socket_perms；

allow container_runtime_dcmain self：unix_dgram_socket{create_socket_perms sendto}；

allow container_runtime_domain self：unix_stream_socket{create_stream_socket_perms connectto}；

allow container_runtime_domain container_var_lib_t：dir mounton；

allow container_runtime_dcmain container_var_lib_t：chr_file mounton；

can_exec(container_runtime_domain，container_var_lib_t)

as can be seen from the above, the tag existing in the content of the filecontext file includes "system_u: object_r: container_config_t, s0"," system_u: object_r: the number of labels such as container_var_lib_t, s0 "is larger than that of the related art scheme in fig. 1, but the number of file labels of the open source scheme is also limited. Compared with the related technology in fig. 1, the open source scheme has no essential difference, the container label and the strategy provided by the open source scheme can not meet the requirement of the container for running the android system, and the technical problem existing in the open source scheme is the same as that existing in the related technology in fig. 1.

In summary, in the scenes of cloud mobile phones, cloud games and the like, the android system runs in the container, and the android system needs to enable selinux to ensure the safety of the system. In the related art, when a container of an android system needs to be operated to enable selinux, the difference between the container label and the host label of the file cannot be realized, so that the selinux in the container cannot be enabled, and further forced access control of the fine granularity of the selinux authority in the container cannot be realized.

In order to solve the technical problems in the related art, the embodiment of the invention provides a method for enabling selinux by a container.

FIG. 2 is a schematic diagram of a container enable selinux in some embodiments, and a method of container enable selinux in an embodiment of the present invention is described in detail below with reference to FIG. 2. The method is applied to a computer device, which can be a cloud server as an alternative. The computer device runs an operating system in the container that enables selinux, e.g., the operating system may include an android system or a non-android system, e.g., the non-android system may include a selinux-enabled linux system, e.g., the container operating system of ubuntu or the container operating system of redhat. In the embodiment of the invention, an android system is described by taking an example of running in a container.

As shown in fig. 2, the architecture of the operating system of the computer device includes a user state and a kernel state, the user state includes a host and a container, the kernel state includes a selinux module and an object, and communication can be performed between the user state and the kernel state. The host includes policy & rule (filecontext) files, filecontext files, processes, and a plurality of lxcfs processes, and the container includes processes and filecontext files. The selinux module comprises a selinux file system, a security server, a selinux abstract layer, an access control cache (Access Vector Cache, abbreviated as AVC) and a log. The host stores the policy rule file to the security server through the selinux file system, and the process of the host or the process of the container adopts system call and autonomous access control (Discretionary Access Control, abbreviated as DAC) to access the object file through the selinux module. In the selinux module, a selinux abstract layer requests permission to an access control cache, the access control cache accesses an object file when judging that access is allowed according to a policy rule file inquired from a security server, and the access control cache writes a refused access record into a log when judging that access is refused according to the policy rule file. Wherein, the selinux module is used for realizing MAC. The access control cache caches the obtained policy rule file after obtaining the policy rule file from the security server for the first time, and the cached policy rule file can be directly adopted when the object file is forcedly accessed subsequently, so that the policy rule file does not need to be obtained from the security server again.

Fig. 3 is a schematic diagram of a container-enabled selinux in other embodiments, and fig. 3 is a specific application of the container-enabled selinux in fig. 2. Fig. 3 differs from fig. 2 in that: the container in fig. 3 is an android container, which includes a zygate process, a filecontext file, app1 and app2. The rest of the structure will be described with reference to fig. 2, and will not be described here again. Fig. 3 may be applied in a cloud cell phone or cloud game scenario.

And fusing the container policy and the host policy to generate a policy rule file. The policy rules file may include the types and rules defined by the selinux policy. As shown in fig. 2, the file under root file system (rootfs) in the container needs its own tag, for example, the independent filecontext file needs its own tag. And the filecontext file of the host also needs its own tag. The labels of the filecontext file of the container and the labels of the filecontext file of the host are different.

And generating container file information and host file information of the first file in the operating system, wherein the container file information comprises a container identifier, a file system name and a container file label, and the host file information comprises the file system name, the file name and the host file label. Specifically, the container file information and the host file information of the first file may be generated by a Selinux policy language genfscon. Various file systems may be configured by using the genefscon syntax, for example, the file system of the first file may include a procfs file system, a sysfs file system, a debugfs file system, a tracefs file system, or a binder file system, which in the embodiment of the present invention is described by taking the procfs file system as an example. The syntax of genfscon may be: genefscon fs_name partial_path fs_context. The genefscon grammar is used for representing files with file names of partial_path in a file system of fs_name, and file labels of fs_context. For example, the phrase "genfscon proc/kallsystems system_u: object_r: system_map_t: s0" indicates that the label of the/proc/kallsystems file under procfs is system_u: object_r: system_map_t: s0. For the same first file, when the container-needed label and the host-needed label do not coincide, for example, the container-needed label is "genfscon proc/kallsyms system_u: object_r: aosp_system_map_t: s0", a label conflict occurs at the time of policy fusion. In order to solve the above-mentioned label conflict problem, the embodiment of the present invention supports that the same file has multiple labels by expanding the semantic expression capability of genfscon and by expanding the new semantics of genfscon, for example, the multiple labels may include a host file label and a container file label. The new semantic of the extended genefscon is "genefscon ns.fs_name partial_path fs_context", wherein "ns" is a container identifier, "fs_name" is a file system name, "partial_path" is a file name, "fs_context" is a file tag, and at this time, the "genefscon ns.fs_name partial_path fs_context" is used to represent container file information. If "ns" is empty, "genefscon ns.fs_name partial_path fs_context" is used to represent the host file information. For example, the host file information may be "genefscon proc/kallsystems system_u: object_r: system_map_t: s0", where "proc" is a file system name, "kallsystems" is a file name, "system_u: object_r: system_map_t: s0" is a host file tag; one container file information may be "genefscon aosp1.Proc/kallsyms system_u: object_r: aosp1_system_map_t: s0", where "aosp1" is a container identification, "proc" is a file system name, "kallsyms" is a file name, "system_u: object_r: aosp1_system_map_t: s0" is a container file tag; another container file tag may be "genefscon aosp2. Proc/kallsystems system_u: object_r: aosp2_system_map_t: s0", where "aosp2" is the container identification, "proc" is the file system name, "kallsystems" is the file name, "system_u: object_r: aosp2_system_map_t: s0" is the container file tag. It can be seen that, for the same first file named "kallsyms", the host file information of the first file and the container file information corresponding to different containers are different, and the host file tag of the first file and the container file tag corresponding to different containers are also different. By expanding the genefscon grammar, the same file can be supported to have multiple labels under the condition of keeping the compatibility of the original use mode, the problem of label conflict between the container and a host strategy is solved, and the purpose of fine granularity control of selinux authority in the container is achieved.

Generating a new policy rule file according to the container file information, the host file information and the policy rule file, wherein the new policy rule file can comprise the container file information and the host file information, and loading the new policy rule file into the kernel. Because both the container file information and the host file information are generated by the genescon, the new policy rules file supports the genescon extension function. As shown in fig. 2 and 3, the host stores the new policy rule file to the security server through the selinux file system to implement loading the new policy rule file into the kernel. The policy rules file in fig. 2 and 3 supports the genescon extension function, and the security server in fig. 2 and 3 also supports the genescon extension function.

The embodiment of the invention completes the configuration process of the host file label and the container file label of the same first file. Then, if mandatory access control (Mandatory Access Control, abbreviated as MAC) needs to be performed on the file, the security context of the inode data needs to be extended to support the extension of genfscon on the selinux policy. The process of configuring the security context and accessing the object file is described in detail below.

An index node (inode) data of a first file is configured, the inode data may include a security context corresponding to a host and a security context corresponding to at least one container, the security context corresponding to the host including a security context identifier (Security Context ID, abbreviated SID), the security context corresponding to the container including a SID and a container identifier, wherein the SID is used to uniquely identify the security context. The security context in the inode data is expanded in the linux kernel, the original security context is expanded into a plurality of security contexts, and besides the original information, a container identifier is added to the security context of each container, wherein the container identifier is used for indicating that the security context is bound with the container identifier of the corresponding container. The container identifier is added to the process in the linux kernel, the container identifier corresponding to the process can be configured in a user mode, and the process copied in the process copying process inherits the container identifier. When the container is started, the initialization process needs to configure the container identifier of the container where the process is located, each container only needs to configure the container identifier once when the process is initialized, and all subprocesses in the container inherit the container identifier. FIG. 4 is a schematic diagram of configuring inode data in some embodiments, as shown in FIG. 4, security context 1 corresponding to container 1 and security context 2 corresponding to container 2 are configured in the inode data, security context 1 including SID 1 and container identification 1 is configured by task 1, security context 2 including SID2 and container identification 2 is configured by task 2, as shown in FIG. 4. And configuring the container identifier 1 corresponding to the process of the container 1 and configuring the container identifier 2 corresponding to the process of the container 2 in a user mode. When the container 1 is started, initializing a process, wherein the container identification 1 of the container 1 where the process is positioned needs to be configured; when the container 2 is started, the initialization process needs to configure the container identifier 2 of the container 2 in which the process is located.

In the embodiment of the invention, after the security context is configured in the inode data, the object file can be accessed. The access procedure is described in detail below.

And acquiring the file system name and the file name of the first file to be accessed and the identification of the process corresponding to the first file to be accessed.

And inquiring file labels corresponding to the acquired file system names, file names and identifications from the new strategy rule files according to the acquired file system names, file names and identifications. As an alternative, when the identifier is a container identifier, the file tag is a container file tag, the new policy rule file includes container file information, and "container identifier, file system name and file name" are corresponding to the container file tag in the container file information, so that the container file tag corresponding to "container identifier, file system name and file name" can be queried from the container file information. As another alternative, when the identifier is a host identifier (i.e. the identifier is null), the file tag is a host file tag, the new policy rule file includes host file information, and the host file information corresponds to the container file tag with "file system name and file name", so that the host file tag corresponding to "file system name and file name" can be queried from the host file information.

And obtaining the SID corresponding to the file tag. The file label and the SID have a corresponding relation, so that after the file label is obtained, the SID corresponding to the file label can be inquired according to the corresponding relation of the file label and the SID. When the file label is a container file label, inquiring the SID corresponding to the container file label; and when the file label is a host file label, inquiring the SID corresponding to the host file label. As shown in fig. 4, for example, if the identification is the container identification 1, the SID 1 corresponding to the container identification 1 is searched out.

A first security context is generated based on the identification and the SID. If the SID is the SID corresponding to the container file label, the identification is the container identification, the generated first security context comprises the SID and the container identification, and the first security context is the first security context corresponding to the container. If the SID is the SID corresponding to the host file tag, the identification is null, and the generated first security context comprises the SID, and the first security context is the first security context corresponding to the host. As shown in fig. 4, for example, the first security context generated from the container identification 1 and SID 1 is security context 1, security context 1 including SID 1 and container identification 1; for another example, the second security context generated from container identification 2 and SID 2 is security context 2, security context 2 comprising SID 2 and container identification 2.

And searching a second security context in the configured inode data of the first file to be accessed through the identification of the process corresponding to the first file to be accessed, wherein the second security context is the security context corresponding to the identification of the process corresponding to the first file to be accessed. If the identifier is a container identifier, searching a security context in which the container identifier is located in the inode data, wherein the security context in which the container identifier is located is the security context corresponding to the identifier; if the identifier is empty, the security context without the container identifier is found in the inode data, and the security context without the container identifier is the security context corresponding to the identifier. As shown in fig. 4, if the identifier is a container identifier 1, the second security context is the security context 1; if the identifier is the container identifier 2, the second security context is the security context 2.

Matching the first security context with the second security context; if the matching is successful, the first file to be accessed can be accessed. For example, the first security context is security context 1, the second security context is security context 1, and matching the first security context and the second security context is consistent, which indicates that the matching is successful, so that it is determined that the first file to be accessed has access rights, and the first file to be accessed can be accessed. If the first security context is inconsistent with the second security context, and the matching fails, determining that the first security context does not have the access right, and refusing to access the first file to be accessed.

The above-described mandatory access control procedure is applicable to a scenario in which a process in a container (including a process that accesses the first file to be accessed) needs to access the first file to be accessed through mandatory access control, for example, the access may include an open access, a read access, or a write access, etc.

One workflow of the container enabled selinux method is illustrated below by a specific embodiment. Fig. 5 is a flow chart of a method of container enabling selinux in some embodiments, as shown in fig. 5, the method comprising:

and 102, fusing the container policy and the host policy to generate a policy rule file.

Step 104, generating container file information and host file information of the first file in the operating system, wherein the container file information comprises a container identifier, a file system name, a file name and a container file label, and the host file information comprises the file system name, the file name and the host file label.

Specifically, the container file information and the host file information of the first file may be generated by the selinux policy language genfscon.

In an embodiment of the present invention, the file system of the first file includes a procfs file system, a sysfs file system, a debug file system, a tracefs file system or a binder file system.

Step 106, generating a new policy rule file according to the container file information, the host file information and the policy rule file, wherein the new policy rule file can comprise the container file information and the host file information.

Step 108, loading the new policy rule file into the kernel.

As an alternative, referring to fig. 6, a process of configuring a security context in inode data and accessing an object file may also be performed after step 108. Fig. 6 is a flow chart of a method of enabling selinux by a container in other embodiments, as shown in fig. 6, the method comprising:

step 110, configuring index node data of the first file, where the index node data may include a security context corresponding to the host and a security context corresponding to at least one container, the security context corresponding to the host includes a security context identifier SID, and the security context corresponding to the container includes a security context identifier SID and a container identifier.

Step 112, obtaining the file system name and the file name of the first file to be accessed and the identification of the process corresponding to the first file to be accessed.

Step 114, according to the obtained file system name, file name and identification, inquiring the file label corresponding to the obtained file system name, file name and identification from the new policy rule file.

Step 116, obtaining the SID corresponding to the file tag.

Step 118, generating a first security context based on the identification and the SID.

Step 120, searching a second security context in the configured inode data of the first file to be accessed through the identifier of the process corresponding to the first file to be accessed, where the second security context is a security context corresponding to the identifier of the process corresponding to the first file to be accessed.

Step 122, matching the first security context with the second security context, and if the matching is successful, accessing the first file to be accessed.

The method for enabling the selinux by the container provided by the embodiment of the invention supports the complicated selinux strategy of the operating system, thereby realizing the forced access control of the fine granularity in the container and simultaneously achieving the purpose of anti-simulator detection. The embodiment of the invention expands the genescon grammar of the selinux and the security context of the inode data of the kernel, can complete the function of enabling the selinux by the container with little modifier, and has good compatibility and low maintenance cost.

In the embodiment of the invention, in order to enable the tags of the lxcfs files in the container to be configured independently, that is, different tags can be configured for the lxcfs files provided by the lxcfs file system, and the method can be realized by a mode of configuring multiple lxcfs processes and different tags for each lxcfs process. FIG. 7 is a schematic diagram of a tag configuring an lxcfs file in some embodiments, as shown in FIG. 7, in the following manner:

before the container is started, the number N of tags required to be configured for the lxcfs files in the container is determined, wherein N is a positive integer. The number of the tags to be configured is the number of the tags actually required by the lxcfs file under the lxcfs process. For example, there are 5 lxcfs files under the lxcfs process, if the tags of the 5 lxcfs files are the same, then n=1; if the tag of 2 lxcfs files is a and the tag of 3 lxcfs files is B in 5 lxcfs files, n=2; if the tags of each of the 5 lxcfs files are not identical, then n=5.

And starting N lxcfs processes, and configuring a corresponding tag (label) for each lxcfs process. Specifically, different lxcfs processes correspond to different labels, and then the labels of all lxcfs files under each lxcfs process are labels corresponding to the lxcfs process. And each lxcfs process transmits the corresponding label to the linux kernel in a mode of starting parameter-o context=label, and then the labels of all lxcfs files generated under the lxcfs process are labels of the afferent linux kernel. For example:

lxcfs Process 1: lxcfs-o nonompty, context=label 1/var/lib/lxc/01

lxcfs Process 2: lxcfs-o nonompty, context=label 2/var/lib/lxc/02.

As can be seen from the above parameters, the labels of all files (/ var/lib/lxc/01) under the lxcfs process 1 are labels 1 (label 1), and the labels of all files (/ var/lib/lxc/02) under the lxcfs process 2 are labels 2 (label 2).

When the container is started, determining a specified lxcfs file of the specified lxcfs process from lxcfs files of different lxcfs processes according to labels of lxcfs files in the container, and mounting the specified lxcfs file into the container. The tag corresponding to the lxcfs process is designated as a tag of an lxcfs file in the container, and the lxcfs file is designated as an lxcfs file corresponding to the lxcfs file in the container. As shown in FIG. 7, FIG. 7 shows container A, container B, lxcfs Process 1 and lxcfs Process 2. As shown in FIG. 7, for example, the tag required for the lxcfs file "/proc/cpu info" in container A and container B is label1, the lxcfs process is designated as lxcfs process 1, the lxcfs file is designated as "/var/lib/lxc/01/proc/cpu info", and then the/var/lib/lxc/01/proc/cpu info of lxcfs process 1 can be mounted into container A and container B; as another example, the label required for the lxcfs file "/proc/stat" in container A and container B is label2, the lxcfs process is designated as lxcfs process 2, the lxcfs file is designated as "/var/lib/lxc/02/proc/stat", and then/var/lib/lxc/02/proc/stat of lxcfs process 2 can be mounted into container A and container B. All the labels of the lxcfs files in the lxcfs process are labels corresponding to the lxcfs process, and the labels of the lxcfs files mounted in the container are labels corresponding to the lxcfs process, so that independent configuration of the labels of the lxcfs files in the container is realized.

The workflow of configuring lxcfs file tags is illustrated below by one specific embodiment. FIG. 8 is a flow diagram of configuring lxcfs file tags in some embodiments, as shown in FIG. 8, the method comprising:

step 302, determining the number N of tags to be configured for the lxcfs file in the container, wherein N is a positive integer.

Step 304, starting N lxcfs processes, and configuring corresponding tags for each lxcfs process.

And 306, when the container is started, determining a designated lxcfs file of a designated lxcfs process from lxcfs files of different lxcfs processes according to the label of the lxcfs file in the container, and mounting the designated lxcfs file into the container, wherein the label corresponding to the designated lxcfs process is the label of the lxcfs file in the container, and the designated lxcfs file is the lxcfs file corresponding to the lxcfs file in the container.

In the embodiment of the invention, the independent configuration of the labels of the lxcfs files in the container is realized by configuring different labels for the lxcfs files of the multiple lxcfs processes and then selecting the files with corresponding labels from the different lxcfs processes to mount the files to the container. Therefore, the tag configuration granularity of the lxcfs file in the container can be thinned, and the purpose of controlling the fine granularity of selinux authority in the container is achieved.

Embodiments of the present invention provide a computer readable storage medium having instructions stored therein which, when executed on a computer, cause the computer to perform the steps of the container-enabled selinux method embodiments described above.

Embodiments of the present invention provide a computer program product comprising instructions which, when run on a computer or any of the at least one processors, cause the computer to perform the steps of the container-enabled selinux method embodiments described above.

The embodiment of the invention provides computer equipment. The computer device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions that, when executed by the computer device, cause the computer device to be operable to perform the various steps of the container-enabled selinux method embodiments described above.

Fig. 9 is a schematic diagram of a computer device provided in some embodiments, as shown in fig. 9, the computer device 10 includes: a processor 11, a memory 12, and a computer program 13 stored in the memory 12 and executable on the processor 11, the computer program 13 when executed by the processor 11 implements the method for container enable selinux in the embodiment, and is not described in detail herein to avoid repetition.

Computer device 10 includes, but is not limited to, a processor 11, a memory 12. It will be appreciated by those skilled in the art that fig. 9 is merely an example of the computer device 10 and is not intended to limit the computer device 10, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., a server may also include an input-output device, a network access device, a bus, etc.

The processor 11 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field-programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 12 may be an internal storage unit of the computer device 10, such as a hard disk or memory of the computer device 10. The memory 12 may also be an external storage device of the server 10, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the computer device 10. Further, the memory 12 may also include both internal storage units and external storage devices of the computer device 10. The memory 12 is used to store computer programs and other programs and data required by the computer device 10. The memory 12 may also be used to temporarily store data that has been output or is to be output.

In the embodiments of the present invention, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relation of association objects, and indicates that there may be three kinds of relations, for example, a and/or B, and may indicate that a alone exists, a and B together, and B alone exists. Wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of the following" and the like means any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

Those of ordinary skill in the art will appreciate that the various elements and algorithm steps described in the embodiments disclosed herein can be implemented as a combination of electronic hardware, computer software, and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In several embodiments provided by the present invention, any of the functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely exemplary embodiments of the present invention, and any person skilled in the art may easily conceive of changes or substitutions within the technical scope of the present invention, which should be covered by the present invention. The protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method of container-enabled selinux, the method being applied to a computer device running an operating system that enables selinux; the method comprises the following steps:

fusing the container policy and the host policy to generate a policy rule file;

2. The method as recited in claim 1, further comprising:

And loading the new policy rule file into the kernel.

3. The method of claim 1, wherein generating container file information and host file information for the first file in the operating system comprises:

4. A method according to any one of claims 1 to 3, wherein the file system of the first file comprises a procfs file system, a sysfs file system, a debug file system, a tracefs file system or a binder file system.

5. The method as recited in claim 1, further comprising:

acquiring the SID corresponding to the file tag;

6. The method as recited in claim 5, further comprising:

7. The method of claim 5 or 6, wherein the identification is a container identification and the file tag is a container file tag; or alternatively, the process may be performed,

the mark is empty, and the file label is a host file label.

8. The method as recited in claim 1, further comprising:

9. A computer device, comprising: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions, which when executed by the computer device, cause the computer device to perform the method of container-enabled selinux of any of claims 1 to 8.

10. A computer readable storage medium, characterized in that the computer readable storage medium comprises a stored program, wherein the program when run controls a device in which the computer readable storage medium is located to perform the method of container enabling selinux of any one of claims 1 to 8.

11. A computer program product comprising instructions which, when run on a computer or any of the at least one processor, cause the computer to perform the method of container enabling selinux of any of claims 1 to 8.