Kernel-Based Container File Access Control Architecture to Protect Important Application Information

Abstract

Container platforms ease the deployment of applications and respond to failures. The advantages of container platforms have promoted their use in information services. However, the use of container platforms is accompanied by associated security risks. For instance, malware uploaded by users can leak important information, and malicious operators can cause unauthorized modifications to important files to create service errors. These security threats degrade the quality of information services and reduce their reliability. To overcome these issues, important container files should be protected by file-access control functions. However, legacy file-access control techniques, such as umask and SecureOS, do not support container platforms. To address this problem, we propose a novel kernel-based architecture in this study to control access to container files. The proposed container file-access control architecture comprises three components. The functionality and performance of the proposed architecture were assessed by implementing it on a Linux platform. Our analysis confirmed that the proposed architecture adequately controls users’ access to container files and performs on par with legacy file-access control techniques.

1. Introduction

Cloud platforms can be classified into virtual machines (VMs), which include operating systems (OSs), and containers, which do not include OSs, in terms of instance type. VMs implement complete virtualization and run their instances on Hypervisor. In contrast, container platforms are implementations of Linux containers (LXC) [1]. An LXC is a runtime environment comprising tools, templates, and libraries [2]. A container is a unit that composes files and directories into a single package. Technical implementations of LXC are referred to as container platforms. A container platform includes a container execution environment and related supporting systems [3]. An information service manager creates a container image, including an application file/directory, registry, and other application environments, whenever an application or information is required to be distributed via a container platform [4]. The information service manager can create a container by executing the container image [5]. Because the container is executed based on the file/directory and other environments included in the container image, the application execution environment is independent of the user environment. Moreover, containers are protected from other containers and system applications because they operate in isolated environments [6]. Therefore, multiple applications can be simultaneously executed on container platforms. Container platforms exhibit high resource efficiency because they support dynamic resource management [7]. For instance, container platforms provide high-availability (HA) and load-balancing (LB) functions [8]. Because of these characteristics, a significant number of recent information services are being constructed using container platforms [9,10].

Container-based information services may include important files depending on the service object and structure during the creation of a container image or during operation, impacting the provision of application services significantly. If the configuration file included in the container is deleted or modified because of incorrect management, the application service may malfunction [11]. In other cases, users may upload malware to a server, which can access the application configuration file and leak important information to external agents. Therefore, important files, such as configuration files, that may be included in containers must be protected from unauthorized access [12].

In legacy information services, either umask or SecureOS is used to protect important files from unauthorized access [13]. Although the system manager can easily set up the umask policy, detailed configurations cannot be established. Additionally, the umask function cannot prevent superuser access. SecureOS addresses a few of the aforementioned limitations of umask. It is a policy-based access control technique that supports multiple access control models such as mandatory access control (MAC), discretionary access control (DAC), and role-based access control (RBAC) [14]. Because SecureOS can effectively protect important application files and directories, it is extensively utilized in real-world information services. However, SecureOS was developed before container platforms were introduced. Therefore, although SecureOS focuses on the access control function for files in the OS’s file system, it does not provide access control for files located inside containers. Therefore, it cannot be used to prevent unauthorized access to container files.

To address this limitation, we propose a kernel-based container file-access control architecture to prevent unauthorized access to container files. The proposed architecture provides a policy-based access control function that monitors the access of container files, allowing authorized processes to proceed and denying permission to unauthorized processes. The proposed architecture is implemented at the kernel level, preventing users from bypassing the access control function. Furthermore, the security manager can verify the enforcement of the access control function based on log files.

Ideally, the function and performance of the proposed architecture should be effective in terms of denying unauthorized access. Therefore, both the positive and negative functions and the performance of the proposed structure were verified in this study.

The primary contributions of the proposed architecture can be summarized as follows:

• All container file-access events of users can be monitored in real time.
• The security environment of application services is strengthened by denying unauthorized access to container files.
• The proposed architecture has minimal effect or other services because only a few system resources are used to provide the access control function.
• The rapid enforcement of the access control function minimizes the performance degradation of the application service.
• The proposed architecture can serve as a security tool because it supports the identification of potentially malicious attackers and processes.

The remainder of this paper is organized as follows. The operational methodology and limitations of legacy file access control techniques are explained in Section 2. In Section 3, the proposed container file access control architecture and the role of each component are discussed. In Section 4, the implementation of the kernel-based architecture is presented, and the unit function of each component with respect to container file access control functions is described. The verification of the functions and the performance of the proposed architecture is presented in Section 5. Finally, the conclusions of the study are summarized in Section 6.

2. Related Works

2.1. LXC and Container Platforms

LXC provides an environment for the independent and simultaneous operation of multiple containers within a single system [15]. The application service manager can create multiple containers by repeatedly running a single image on a single system. In other words, containers can be repeatedly executed as long as the system resources allow it [16].

The image of a container may include software (SW) that performs a specific function. The application service manager can use the SW by spawning a container and executing the container image without actually installing the SW [17], and even modify the container image if required [18]. Multiple containers that are simultaneously executed share the kernel of the OS. Typically, containers being executed share all resources of the OS. Although the OS dynamically allocates resources to each container upon its execution, specific resources can be pre-emptively selected, if required [19].

The container platform is an implementation of LXC because it satisfies the technical requirements of LXC and supports various operating environments. In addition to Docker, examples of currently used container platforms include AWS Fargate, Google Kubernetes, and Apache Mesos [20,21]. It is evident that container platforms are widely utilized as operating environments in multiple information services because of their numerous advantages.

As indicated in Figure 1, a container platform comprises a container engine, container image, container, container registry, container management interface, storage, and scheduler [22].

The container engine provides an isolated environment for the execution of containers [23]. A container image is a deployment unit that remains static prior to container execution [24]. A container registry is a server on which container images are registered, and the container management interface serves as a user management interface for the execution and monitoring of containers [25]. The container storage is a repository for container images [26]. Finally, the scheduler handles periodic executions of the container [27].

The system manager can configure network configurations, such as the maximum session and throughput, of each container [28]. The HA or LB function of the information service can be implemented by executing a container and applying the network configurations of the container platform. These advantages have promoted the use of container platforms [29].

2.2. Security Threats and Requirements

Container platform-based information services are susceptible to security threats, similar to any other service. Any container created by executing a container image includes an application environment such as a configuration file for application execution, a system account, or a library path. Therefore, a malicious attacker accessing the system environment can delete or modify the application environment, inducing the malfunction of container-based applications [30].

In general, important files may be included in the container during its execution or may be input into the container when an application service is provided. Additionally, the service manager or users can share or upload important files to the container, respectively. Thus, a service user may upload malware, which, if executed, may delete or modify user files stored in the container or leak important information included in the file [31].

Therefore, both important and user files should be protected in this environment. A secure environment [32] must guarantee confidentiality, availability, integrity, authentication, and access control. In particular, the access control function monitors user access to sensitive files and denies unauthorized access or modification by verifying whether the requesting subject is allowed to access the requested object [33,34].

All security technologies are required to satisfy specific security principles, such as identifiability, self-awareness, appropriate boundaries, convenience, locatability, and visibility. Among these, this study focuses on locatability and convenience. Locatability represents the degree of choice of the security manager, and convenience represents the ease of security-function enforcement [35]. Therefore, a protection mechanism should be developed to protect important container files, and security managers can choose to enforce it on container platforms at their own discretion [36].

2.3. Legacy File Access control Techniques

Umask and SecureOS are the two most widely used file access control techniques. Umask is an OS-level access control technique for users and user groups that is utilized in most OSs. Umask operates based on access privileges defined by the owner for each role (owner, owner group, and others) with respect to the file/directory. Furthermore, the OS monitors and identifies users (subjects) accessing files (objects). Subsequently, the roles of users are verified to determine whether access should be provided. Therefore, umask simply uses the access control function as a policy configured by the file/directory owner [37].

SecureOS is a policy-based access control technique that monitors access to resources from a single point in the kernel and denies access when the policy is violated. It provides access control functions for files/directories, application processes, and devices. Access control models, such as MAC, DAC, and RBAC, are supported in terms of subject identifiers, including security groups, user roles, users, and user groups [38].

SELinux and AppArmor are well-established SecureOS architectures provided by the Linux OS, and the group policy object (GPO) is available on Windows [39,40].

Figure 2 depicts the four-tier structure of SELinux, which is a representative SecureOS architecture. SELinux is based on an access control policy in which the user sets the policy identification number (ID) (object), including the user ID (subject), via the policy management interface, which is then transferred to the Security Server and converted into an object file/directory path by searching the SELinux Filesystem. If the Security Server determines the object file/directory to be complete, the user ID and file/directory path (object) are registered in the Access Vector Cache (AVC). Whenever a file access event occurs, the corresponding event information is transferred to AVC, which extracts the user ID and file/directory path accessing the object. If a user’s file access event matches the access control policy, user access is denied, and the event is logged. Both AppArmor and GPO provide kernel-based file access control, and their structures are similar to that of SELinux [41].

2.4. Limitations of the Legacy File Access control Techniques

Umask is primarily an access control function for OSs that is also applied to the container platforms [42]. Despite its easy application, it suffers from specific limitations. For instance, umask can identify only three roles—owner, owner group, and others. Therefore, umask cannot control access provided to specific users or user groups. Additionally, umask always provides access to superuser accounts, such as root or administrator accounts [43]. This compromises the owner’s understanding of the users and user-group organizations accessing the files/directories [44]. Most importantly, umask is application-specific within containers. When a user file is uploaded to a container, configuring umask for each uploaded file is inconvenient. Additionally, as diverse applications can be uploaded to containers, the application service manager is required to understand all the application characteristics to configure umask correctly, which is practically impossible.

SecureOS mitigates a few of the aforementioned limitations of umask. For instance, SecureOS uses the access control policy to control access to the files or directories of specific subjects such as users and user groups. Moreover, the SecureOS policy can deny access to the container. However, no SecureOS system, including SELinux, AppArmor, and GPO, considers the container environment [45,46,47]. As a result, access to the file/directory located inside containers cannot be denied using SecureOS.

Thus, the development of a dedicated mechanism for container file access control and its incorporation within system security frameworks, such as SecureOS, is essential to protect container files. Unfortunately, no such mechanism has been proposed yet.

3. Kernel-Based Container File Access control Architecture

3.1. Design Considerations

Typically, the protected object and accessing subject must be uniquely identifiable to ensure access control.

The accessing subject is the user account (user ID) or the user group account (group ID) of the host OS. Therefore, legacy access control techniques adopt the user account as the subject of the access control policy. However, this practice cannot be adopted in a container platform system because of its isolated nature. Figure 3 indicates that the same user account may exist both in the host OS as well as the container on a container platform [48]. The container platform internally uses the namespace technique, which ensures the independence of user accounts and files/directories in the container. Although the user accounts in the host OS and container have identical user IDs, the container platform is processed as a different account by namespace. Namespace separates user IDs into session IDs (SIDs) and independently processes each SID. This isolation feature is the most significant advantage of container platforms. However, access control suffers from specific disadvantages in this case. As mentioned above, an identifier is required to be used as the subject of the file in the container’s access control policy because of the non-uniqueness of the user account.

Legacy file access control techniques, such as SELinux, AppArmor, and GPO, use the absolute path to the requested file as the object. However, it cannot be used as an object in container platforms. Figure 4 illustrates the difference between a file path (virtual file path, Vf) known to the accessing user and a real path (absolute file path, Af) [49]. This difference can be attributed to the namespace of the container platform. Therefore, the object of the access control policy must be a real path for the access control policy to be valid with respect to container files [50].

However, because typical real paths are considerably long and contain random strings, it is inconvenient to use them during the configuration of the access control policy. Moreover, it violates certain security principles. Therefore, the file path known to the user is used to register the access control policy for the container files. However, policy registration requires the conversion of a file path known to the user (Vf) to a real path (Af).

3.2. Access Control Policy Structure

The enforcement of access control must satisfy the security principles of non-bypassability and single-point enforcement. To achieve these, kernel-level implementation is essential, which facilitates the acquisition of information to identify a user’s file-access event. At this level, the user’s file-access event is processed by an interrupt function, and detailed information is registered in the interrupt request queue (IRQ). The SID of the user account and the Af to be accessed are uniquely identified in the IRQ; this information can be used as a component of the access control policy.

In general, access control policies should be easy to remember and implement. However, remembering SIDs may be difficult for users. Because the SID of an account in a container cannot be obtained from the host OS, it cannot be used as an access control policy. Similarly, Af is unknown to the user; thus, it cannot be included in an access control policy because it depends on container initialization.

In this study, the container ID (Ct) was used as an additional identifier to facilitate the identification of files in the user container. Figure 5 illustrates the structure of the access control policy used to identify the access events associated with container files.

The container file-access event (Ev) includes SID and Af. SID is generated when the user logs in, but it changes with every login and, thus, is not suitable to be used as an element in the container file-access policy. Therefore, the user ID (Uid) of the container and the container ID (Ct) are used to identify the container SID. Because of its high length, Af violates the security principle regarding convenience. Therefore, Ct and Vf are used to identify the Af of a container file.

To define the container access control mechanism, the container file access control policy and container file access event are defined as follows:

$$\begin{gathered} \mathrm{The} \mathrm{container} \mathrm{file} \mathrm{access} \mathrm{control} \mathrm{policy} \mathrm{is} \mathrm{denoted} \mathrm{by} P \\ \mathrm{Container} \mathrm{file} \mathrm{access} \mathrm{event} \mathrm{is} \mathrm{denoted} \mathrm{by} Ev \\ \mathrm{Access} \mathrm{control} \mathrm{policy} \mathrm{enforcement} \mathrm{is} \mathrm{denoted} \mathrm{by} ACE \\ \mathrm{Access} \mathrm{control} \mathrm{policy} \mathrm{enforcement} \mathrm{result} \mathrm{is} \mathrm{denoted} \mathrm{by} PER \\ {\mathrm{The} \mathrm{e} \mathrm{in} \mathrm{which} \mathrm{the} \mathrm{elements} \mathrm{of} \mathrm{e} \mathrm{and} \mathrm{P} \mathrm{match} \mathrm{is} \mathrm{denoted} \mathrm{by} \mathrm{Ev}}_P. \end{gathered}$$

PER is defined as follows:

$$PER=ACE(Ev)=\left\{\begin{array}{l}0, Ev \notin { \mathrm{Ev}}_{{}_P}\\ 1, Ev \in { \mathrm{Ev}}_{{}_P}\end{array}\right.$$

PER can have one of two outcomes—allow or deny. The following notations are used for the two cases:

$$\begin{gathered} \mathrm{The} ‘\mathrm{deny}’ \mathrm{outcome} \mathrm{of} PER \mathrm{is} \mathrm{denoted} \mathrm{by} PE{R}_1 \\ \mathrm{The} ‘\mathrm{allow}’ \mathrm{outcome} \mathrm{of} PER\mathrm{is} \mathrm{denoted} \mathrm{by} PE{R}_0 \end{gathered}$$

P comprises three elements—Ct, Vf, and Uid. The following notations are used for them:

$$\begin{gathered} Ct\mathrm{defined} \mathrm{in} \mathrm{access}-\mathrm{control} \mathrm{policy},P,\mathrm{is} \mathrm{denoted} \mathrm{by}C{t}_p \\ Vf \mathrm{defined} \mathrm{in} \mathrm{access} \mathrm{control} \mathrm{policy},P, \mathrm{is} \mathrm{denoted} \mathrm{by} V{f}_p \\ Uid \mathrm{defined} \mathrm{in} \mathrm{access} \mathrm{control} \mathrm{policy}, P, \mathrm{is} \mathrm{denoted} \mathrm{by} Ui{d}_p \end{gathered}$$

PER₁ can be expressed as follows:

$$PE{R}_1=ACE(E{v}_P)=ACE(E{v}_{C{t}_{{}_P}•V{f}_{{}_P}•Ui{d}_{{}_P}})$$

(1)

Additionally, when the elements do not match those of the access control policy, the access request is allowed, corresponding to the outcome, PER₀, as follows:

$$PE{R}_0=ACE(E{v}_{\overline{P}})=ACE(E{v}_{\overline{C{t}_{{}_P}}}+E{v}_{\overline{V{f}_{{}_P}}}+E{v}_{\overline{Ui{d}_{{}_P}}})$$

(2)

This is obtained by applying De Morgan’s law to Equation (1).

Equations (1) and (2) indicate that the user is denied access if all the three elements (i.e., Vf, Ct, and Uid) match with the parameters of the access control policy. Conversely, access is provided if any one of them does not match.

Therefore, if Equations (1) and (2) hold, the proposed intra-container file access control architecture can be considered to be valid.

3.3. Access Control Architecture for Container Files

The proposed access control architecture for container files is designed to satisfy the following conditions:

• Preserve container features.
• Minimize changes in the container platform configuration.
• Use information known to users that can be easily used.
• Minimize resources required for providing the access control function.

Considering the specific characteristics of the container platform, we propose a container file access control architecture, whose schematic is shown in Figure 6.

The proposed access control architecture for container files comprises the following three components. The Host Agent serves as the interface of the Security Manager that selects the access control policy. The Container Agent denotes a daemon that converts the access control policy elements to actual information. The File Access Controller monitors user access to the container files and enforces access control policies.

The Security Manager selects the access control policy based on Uid, Ct, and Vf via the Host Agent. The access control policy elements (Uid, Ct, and Vf) are transmitted to the Container Agent, which converts the Uid and Vf into SID and Af, respectively. Subsequently, the Container Agent transmits the SID and Af to the Host Agent, which then transmits them to the File Access Controller for the registration of the access control policy. The File Access Controller receives the access control policy from the Host Agent and registers it as a kernel-based access control policy.

When a user accesses a container file, the kernel creates an IRQ for the user file in the container access event. The File Access Controller monitors the kernel IRQ. If the container file access event node is registered to the kernel IRQ, the File Access Controller obtains the SID and Af corresponding to the event. Subsequently, the File Access Controller enforces the access control policy by comparing the SID and Af with the selected values in the security policy database. If a matching set of SID and Af is identified, the file-access-event node is deleted from the kernel and the STOLEN code is returned. The accessing user is displayed a denial message. Figure 7 depicts a sequential diagram of this process.

Other file-protection techniques, such as umask or SecureOS, cannot obtain the Af corresponding to the container file and, thus, cannot protect container files. By contrast, the architecture proposed in this study obtains the Af corresponding to the container file’s Vf.

4. Implementation on the Linux Platform

To verify the effectiveness of the proposed architecture, we implemented the access control logic in an environment based on CentOS 8.3 (kernel version 4.18.0-394) and the Docker container platform (version 4.2.0). Figure 8 depicts the implemented access control logic.

In the proposed architecture, the Host Agent was implemented as ConPolicy executed in the Linux shell, whereas the Container Agent was implemented as Cont_Agt_D, which acted as a server daemon. The File Access Controller was implemented as the Container File Access Control Kernel Driver, which was divided into policy management (Kernel Policy Manager) and enforcement (File Access Control Handler) components. ConPolicy and Cont_Agt_D communicated using the TCP/IP socket protocol, whereas ConPolicy and Container File Access Control Kernel Driver communicated using system calls. The Policy List was implemented as the Security Policy DB. Kernel Policy Manager served as the system call handler for system calls initiated by the ConPolicy. It registered SID and Af to the Policy List. Finally, the File Access Control Handler was a kernel module used to enforce the access control policies.

4.1. ConPolicy

ConPolicy was an executable command executed in the Linux shell. Here, Ct represents the number used for identifying Cont_Agt_D. ConPolicy verified Uid, Ct, and Vf. If all the arguments were determined to be accurate, ConPolicy transmitted them to Cont_Agt_D and waited for a response from Cont_Agt_D. Once ConPolicy received the SID and Af from Cont_Agt_D, it transmitted them to the Kernel Policy Manager via a system call.

4.2. Cont_Agt_D

Cont_Agt_D was a daemon program that served as a Container Agent. Cont_Agt_D received the Uid and Vf from ConPolicy and obtained the SID on this basis. Similarly, Cont_Agt_D obtained the Af based on the Ct and Vf. Subsequently, Cont_Agt_D transmitted them back to ConPolicy.

4.3. Container File Access Control Kernel Driver

4.3.1. Kernel Policy Manager

The Kernel Policy Manager in the Container File Access Control Kernel Driver received the SID and Af from ConPolicy and registered them onto the Policy List. Figure 9 depicts the structure of the Policy List. To ensure rapid search in the access control policy, the Policy List was considered to be a two-level hashtable based on Af and SID like SELinux’s policy structure.

4.3.2. File Access Control Handler

When a user accessed a container file, the container engine converted Vf into Af and transmitted it to the kernel. The kernel then generated a file-access-event node and registered it in the IRQ.

The File Access Control Handler is a kernel function used to enforce the access control policy. Typically, it registers a file access event hooking function onto the Linux security module [51]. When a file access event occurs, the file access event hooking function obtains the corresponding object and subject information [52]. Subsequently, it calls the access control policy to enforce the function registered in the File Access Control Handler.

In this study, the File Access Control Handler search-policy node in the Policy List corresponded to the SID and Af of the file access event. If a matching set of Af and SID were identified in the Policy List, the file access event was marked as STOLEN. If the interrupt function was marked as STOLEN in the kernel, its process was halted and the user was denied access to the file in the container.

5. Verification of the Container File Access Control Architecture

5.1. Function Verification Items

To ensure the operational accuracy of the container file access control function of the proposed architecture, we verified the positive and negative items, as listed in

Table 1. Functionalities used for verification.

Class	Verification Item	Description
Positive	PEnforce_P1	Verification of Equation (1) After selecting the container file access control policy, verify whether file access is denied when the subject and object of the file accessed are identical to those in the registered access control policy.
Negative	PEnforce_N1	Verification of $PE{R}_0=ACE(e_{\overline{C{t}_{{}_P}}})$, which is a part of Equation (2) Verify whether the container ID of the file accessed is different from that in the registered access control policy, even if the Uid and Vf are identical.
	PEnforce_N2	Verification of $PE{R}_0=ACE(e_{\overline{V{f}_{{}_P}}})$, which is a part of Equation (2) Verify whether the container ID and Uid of the file accessed are identical to those in the registered access control policy, even if the Vf is different.
	PEnforce_N3	Verification of $PE{R}_0=ACE(e_{\overline{Ui{d}_{{}_P}}})$, which is a part of Equation (2) Verify whether the container ID and Vf of the file accessed are identical to those in the registered access control policy, even if the Uid is different.

.

5.2. Performance Verification

Ideally, the container file access control architecture should not interfere with other services, and the cost of access control functions should be minimal. To evaluate the performance of the proposed access control architecture from this perspective, we measured the central processing unit (CPU) share (%) required for the policy registration and the enforcement time of the access control policy. The assessment was performed using an Intel i7-8700 CPU with a memory of 32 GB and a hard disk of 10 TB. The performance of the proposed architecture was compared with that of SELinux.

5.2.1. CPU Usage

To measure the CPU usage rate required to register the access control policy, we created a shell script to register multiple access control policies. The policy registration shell script repeatedly applied ConPolicy a specified number of times. During the execution of the shell script and the registration of the access control policy, the CPU usage rate was recorded using the Linux top command.

To validate the performance of the proposed architecture, the same test was conducted on SELinux. The performances of the two approaches were compared with respect to the CPU usage rates.

Table 2. Central processing unit usage rates of SELinux and the proposed architecture.

SELinux policy registration CPU usage rate (%)	1	2	3	4	5	Average	Standard deviation
	3.8	3.6	2.9	3.6	3.4	3.60	0.319
	6	7	8	9	10
	3.3	3.6	4.0	4.0	3.8
Proposed architecturepolicy registration CPU usage rate (%)	1	2	3	4	5	Average	Standard deviation
	4.8	5.1	4.4	3.9	4.4	4.57	0.445
	6	7	8	9	10
	4.2	4.6	4.0	5.1	5.2

summarizes the mean CPU usage rates and the corresponding standard deviations over 10 iterations, amounting to the registration of 500 access control policies in SELinux and the proposed architecture for each.

The results indicate that the CPU usage rate required for the policy registration was slightly higher (4.57%) in the case of the proposed architecture than that for SELinux (3.60%). This increment was attributed to the different tasks performed during the policy registration process. SELinux directly sets the Af while registering an access control policy. In contrast, a Vf is used while registering the access control policy by the proposed architecture. This heightens the CPU usage because the Host Agent is required to convert the Vf into an Af.

5.2.2. Policy Enforcement Time

To minimize the enforcement time of the container file-access control policy, we measured the final policy enforcement times when multiple access control policies were registered in the Policy List simultaneously. A dummy policy is a policy that is not actually used and only serves to delay the final policy enforcement time. In this experiment, it was generated by a script created for performance measurement by combining a random Vf, a random container ID, and a random Uid. The measured policy enforcement time of the proposed architecture was compared with that of SELinux to evaluate the performance of the former.

The numbers of dummy container file access control policies used to measure the final policy enforcement time were considered to be 500, 1000, 2000, 4000, 5000, and 6000. The final policy enforcement time was measured considering the starting time of the matching access control policy application.

Figure 10 illustrates the average times required to register the final access control policy during 10 iterations of registering multiple dummy access control policies.

As shown in Figure 10, the policy enforcement time of the proposed container file access architecture is almost the same as that of SELinux.

5.3. Verification Analysis

In the functional verification step, we confirmed that the proposed access control architecture denied only those events that matched the container file access control policy and allowed the rest. Thus, based on the access control policy set by the security manager, authorized users can access sensitive files, but unauthorized users cannot.

Additionally, we determined that the CPU usage rate required to register the access control policy and the enforcement time of the proposed architecture were slightly higher than those of SELinux. This is attributed to the methodological differences between the two architectures. SELinux uses Af as the object element of the security policy. In contrast, the proposed architecture uses Vf and the container ID. These are combined to obtain the Af of the target file, which is then added to the policy database. Thus, the more complicated policy registration task of the proposed system naturally requires more time and a higher CPU usage rate than SELinux.

Depending on the number of dummy policies, there are cases where the policy enforcement times of SELinux or the proposed container file access control architecture are earlier or later than each other. However, the policy enforcement times of the two security techniques were confirmed to be virtually the same. This is because the policy-list structure of the proposed container file-access control architecture and the policy structure of SELinux are all hashtable structures. Although the process of calculating hash ID one more than SELinux’s policy structure was added, it was confirmed that this process did not significantly affect the policy enforcement time.

Therefore, the proposed access control architecture can be considered to be sufficiently effective in terms of functionality and performance.

6. Conclusions

Container platform-based information services ensure easy distribution and installation of applications. The numerous advantages of container platforms, such as dynamic resource-sharing functions and fault tolerance functions, have promoted the development of information services based on container platforms as well as research on expanding their scope.

To ensure stable operation of container platform-based information services, important files of container-based applications must be protected. However, legacy file access control techniques do not support container platforms.

Therefore, in this study, a container file access control architecture comprising three components and a feature implemented at the kernel level was proposed. The proposed architecture was implemented in a Linux environment to verify the effectiveness of its functions and performance. The analysis confirmed that the proposed access control function was normally provided, and the performance of the proposed system was satisfactory.

The key contribution of this study is the expansion of the limited access control coverage of legacy security environments to container platforms, which is the first step toward comprehensive container platform security. In particular, the container file access control architecture proposed in this study can monitor user access of container files in real time and prevent unauthorized access. In addition, because the resources used for access control were confirmed to be insignificant, it does not affect other application services. Therefore, the container file access control architecture proposed in this study satisfies hitherto unfulfilled security principles for access control on container files.

Container-based application services can use various resources such as registries, processes, devices, and files/directories. The access control policy is registered in memory. As the policy count increases, the memory usage also increases proportionally. If the number of container files to be protected increases, the kernel memory-usage rate for registering the container-file access control policy increases. This can degrade the system performance. Therefore, an appropriate number of container-file access control policies must be enforced. Although all resources must be protected to provide stable service, this study proposed a protective architecture only for container files. Therefore, future research is necessary to consider the protection of other resources.