Review Reports

Reviewer

No.

Disadvantage

Response

Reviewer 1

1

In introduction, they should add the emerging and usage of container technology nowadays. Comparison between container technology and VM technology can be added. No related works with similar interest is described.

In response to your comment, we have mentioned current container platform usage trends and the differences between VMs and containers in lines 25–28 on page 1, and the inability of SecureOS to control container file access in lines 62–65 on page 2.

2

Some terms are used before they are carefully defined 

In response to your comment, we have introduced all abbreviations at their first instance of use.

3

The problem formulation should be written more carefully and professionally. 

Eg: x is not a set; Sets U, P, AR are not defined properly; What is “but r /in AR” at 266th line; What is “matched”?; At line 272, what does the “the values are true” means? X is the access request which can not be True; x is all access request and access control?; r or x is an access request?

In response to your comment, we have rewritten the problem formulation and related descriptions. All elements and functions have been redefined clearly.

4

If they ensure that the proposal satisfies some security principles, explanations about the satisfaction should be added.   

In response to your comment, we have explained access control security principles in lines 148-154 of page 4. Moreover, we have discussed why the file access-control architecture proposed in this study satisfies the security principles in the concluding section in lines 496-501 on page 15.

5

Contributions have not been demonstrated well. Please give proof for them by explanations or experiments. 

The contributions of this study have been stated on page 2 of the original manuscript. However, in response to your comment, we have added an elaborate discussion of the contributions of this study to the Conclusions in lines494-496 on page15.

6

How a container file access control policy guaranteeing the security of system is shown in the experiment. The results have not shown anything about security. 

In response to your comment, we have added examples of an authorized access case and an unauthorized access case, and added a description of the effect on security in the subsection 'Verification Analysis' in lines 463-464 on page 15.

7

Add a legend into the Fig. 15 

In response to your comment, we have added a legend to the Fig. 10 on page 14.

8

Most of the terminal images do not provide any useful information

In the original manuscript, we had discussed all terminal objects using images to demonstrate that all unit functions operate correctly. However, in response to your comment, we have removed this discussion as well as all related images and descriptions.

Reviewer

No.

Disadvantage

Response

Reviewer 2

1

Authors claim "However, the existing SecureOS technique does not support container platforms; therefore, it cannot deny unauthorized access to container files".  More explanations are needed. 

In response to your comment, we have explained why SecureOS cannot enforce access control on container files in lines 63–65 on page 2.

Reviewer

No.

Disadvantage

Response

Reviewer 3

1

A much deeper study in terms of performance degradation is needed. In the current work, this aspect is only measured and discussed briefly. It is not suitable as a performance evaluation.

In response to your comment, we have added more detailed analysis of performance degradation in the subsection 'Verification Analysis' in lines 467–477 on page 15.

2

The first part of the study is based on a variety of existing works. But it is essential to clarify the strong points and novelty of the proposal with respect the state of the art.

In response to your comment, we have mentioned the novelty of the study with respect to the requirements of container file access-control architectures in lines 204–206 on page 5.

3

The same happens with the novelties of Figure 6.

Figure 6 depicts a block diagram describing the process of obtaining internal information of the container without obtaining the host OS. It demonstrates how security techniques can be enforced within containers. We think that this explains the novelty of our study adequately. However, in response to your comment, we have clarified the novelty of the study with respect to the differences between the proposed architecture and legacy file access-control techniques in lines 344–347 on page 10.

4

What would happen if other types of containers would be considered, apart from Linux-based containers?

Implementation of architectures with container platforms of other types involve consideration of the container platform's file system's mounting and usage mechanism. Other factors remain unchanged.

We do not think that this consideration is relevant to our manuscript. Thus, statements about this have not been added.

5

The use of other Linux systems would affect the performance of the proposal, such as an Ubuntu operating system?

We believe that although the use of other operating systems may induce absolute differences in the measured performance, it would not induce any relative differences.

6

In Table 2, additional measures would be great. At least, standard deviation, and justify them. They are very simple in the current form.

We have added standard deviation to Table 2 on page 13 and explained its connotations.

7

How are the dummy policies generated? Each step must be justified.

We apologize for this omission. We have added a description of dummy policy definitions, roles, and generation procedures in lines 439–442 on page 14.

8

Is the operating system tunned in some way, so that the different measures are in the same conditions?

The CPU usage rate and policy enforcement time of SELinux and the proposed architecture were measured after disconnecting the network in a clean OS state. Thus, the two sets of measurements were recorded in identical environments.

9

Detailing the future possible works, I understand this a first step to increase security with addition steps.

In response to your comment, we have mentioned that the proposed architecture represents the first step to strengthen overall container security in the concluding section in lines 494–496 on page 15.

Reviewer

No.

Disadvantage

Response

Reviewer 2

1

The new version has addressed my concerns and queries.  

Thank you for your comment.

We have checked each of the responses for tone, language, clarity, and correspondence with the reviewers’ comments and the changes made in the revised manuscript. We will do our best to resubmit the revised manuscript.

Reviewer

No.

Disadvantage

Response

Reviewer 3

1

After revising the resubmission of the manuscript, I think author have not solve my three first points. Authors only make some additional descriptions. They have to be addressed exhaustively.

- A much deeper study in terms of performance degradation is needed The results section mut be extended with additional results (a stronger study).

We appreciate your kind comments. We want to explain two things.

The first is about performance degradation.

Performance degradation was our mistake.

SELinux's policy structure is a hashtable. However, the proposed container file access control architecture's policy structure is a two-dimensional linked list. Therefore, the performance was relatively low. Thus, we matched the policy structure of our proposed container file access control architecture with that of SELinux. As a result, the policy enforcement time was measured to be approximately the same. The result of measuring policy enforcement time is described in Figure 10 on p. 14, and the result analysis is described in lines 472-479 on p. 15.

The second is the additional performance verification you commented on.

This study proposes an information security technique. Therefore, function and performance are verified in the system software environment.

As you know, there are three sw computing resources required to provide information security techniques: CPU usage rate, memory usage amount, and storage usage amount.

CPU usage rate is a very important verification item. Thus, we measured the CPU usage rate when performing access policy registration and compared the result with SELinux.

Additionally, this study proposes an access control architecture. Thus, our proposal is included in the security domain. Therefore, the container file access control architecture proposed this study should meet the timeliness security principle. Thus, we measured the access control policy time and compared it with SELinux.

Access control policy is registered in memory. As the policy count increases, the memory usage amount also increases proportionally. This is the user's choice. Thus, we did not even do memory usage amount verification.

Storage is not used in the container file access control architecture proposed in this study. Thus, we did not verify the storage usage amount.

Although we think we have verified all performance related to the container file access control architecture, you commented that additional performance verification should be done. We do not know what additional performance verification to perform. Thus, please let us know what additional performance verification is necessary.

2

The first part of the study is based on a variety of existing works. But it is essential to clarify the strong points and novelty of the proposal with respect the state of the art.  For instance, in [16] (numbered as [17] in the second version on the manuscript), an approach with a similar purpose is presented and evaluated. What are the novelties of this work with respect that reference? The main differences must be stated and the result section has to be extended.

As you know, sw architecture is composed of structure, handling information, mechanisms, and so on, which depend on sw's objects and functions.

Our study's object is to protect the confidentiality and integrity of user information stored in container files by verifying user access authority. The same security techniques as our study's object are only available with SecureOS. SecureOS protects user information's confidentiality and integrity in files. SecureOS, which is widely used, includes SELinux, AppArmor, and GPO. Thus, we analyzed these SecureOS techniques and described their limitations for container platforms in Section 2.4.

However, [17]'s security object is different from our study's object. We explain the differences between our study and [17] in the below table (because of another reviewer's comment response, we added a description to the first section and cited the reference. Thus, [16]'s reference number is changed to [17].).

Of course, [17] is good security technique about container platform for safe provision of the container platform’s main function. However, we think [17] has nothing to do with our study, because [17]’s object is not similar to our study’s object. Additionally, [17]’s architecture cannot provide user access control about the container file. Thus, [17] cannot protect the user’s container file.

Based on the table above, we believe that [17] is not relevant to our study. Thus, we did not describe [17] in our study. We only cite [17] to describe the container platform’s usage case.

3

The same happens with the novelties of Figure 6. This fact is not addressed in the new version of the manuscript. As my previous comment, it is essential to address the novelties of the architecture (by comparing with the state of the art).  

As you know, the novelty of the security study is:

1. Identifying new security threats.

2. Analyzing information service environment and its vulnerability.

3. Defining security objects.

4. Propose security technique or methodology that can deny/reduce security threats or overcome vulnerability.

Thus, we

- describe current information service environments-container platform

- Identify security threat can occur on container platform

- Analyzing legacy security technique’s limitation and container platform’s features

- Propose new security technique architecture to protect user information in container file,

in Sections 1, 2, and 3 including Figure 6. Additionally, we also verify our container file access control architecture’s function and performance.

Furthermore, we describe our contribution in the conclusion at p. 15, lines 494-500.

Thus, we believe that our study's novelty has been sufficiently described.

We hope you understand our study's novelties and contribution, and we believe that you do not want the security threat on container platform to remain.

Thank you all for your review comments.

Reviewer

No.

Disadvantage

Response

Reviewer 3

1

After revising the second resubmission of the manuscript, I think author have solved all my concerns. I only miss enforce the paper with these clarifications, even comparing with the previous work with the table incorporated in the cover letter. As for results, it would be desirable mentioning too possible overload in terms of memory usage (apart from CPU and time).

Thank you for the helpful and insightful comments.

Accordingly, we have added considerations when using many container-file access control policies to Section 6, Lines 503–508.

Thank you for all your help toward improving our manuscript.