JP2012048609A - Security policy generation program, and secure os computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology for setting access authority which is required by an application as security policy without depending on an operation history of the application.SOLUTION: The security policy generation program reads at least one of an execution file of the application which operates on a secure OS, a setting file of the application, a file list which constitutes the application, and analyzes which access authority on the secure OS becomes necessary in relation to the files. In addition, its analysis result is output as a security policy candidate of the secure OS.

Description

  The present invention relates to a technology for generating a security policy of a secure OS (Operating System).

  In general, the access authority for a resource (file, network port, etc.) on the OS of the computer is set by the owner of the resource. Further, there is a privileged user having all the authority, and the OS administrator can set the resource access authority as the privileged user.

  On the other hand, the secure OS is an OS in which a privileged user having all rights is excluded and a minimum access authority can be given for each process (for example, for each execution file of an application). Settings regarding what access authority each process has are described in a file called a security policy file.

  In the secure OS, the OS ensures that the process accesses only the resources that the process requires. Therefore, even if there is a security hole in the process and the process is taken over by an attacker, the security damage caused by the process can be minimized.

  In order to assign the minimum necessary authority to the process on the secure OS, it is necessary to appropriately set the security policy. However, the setting items for access authority are often enormous, and the work is complicated. Therefore, a technology that supports the work of setting a security policy has been studied. For example, techniques such as the following Patent Document 1 and Non-Patent Document 1 have been proposed.

  Patent Document 1 describes a technology for automatically generating a security policy setting from an operation log of an application. Non-Patent Document 1 describes a technique for simplifying the description of a security policy.

JP 2005-128623 A

"SEEdit: SELinux Security Policy Configuration System with Higher Level Language", Proc. Of 23rd Large Installation System Administration Conference (LISA '09), pp.107-117 (11, 2009), URL: http: //www.usenix. org / event / lisa09 / tech / full_papers / nakamura.pdf (acquired on August 10, 2010)

  In order to appropriately set the security policy of the secure OS, it is necessary to set whether or not access is possible for all access authorities that the application may use.

  In the technique described in Patent Document 1, an operation history is acquired in a form such as an audit log by actually operating an application, and an access permission required by the application is set with reference to the history. In this method, it is necessary to repeatedly perform an application test operation in order to cover the access authority that can be used by the application, and there is a possibility that the number of work steps for acquiring the operation history may be increased. Depending on the specifications of the secure OS, the audit log may be simply described to prevent performance degradation. In this case, it is difficult to obtain a complete operation history from the audit log.

  The present invention has been made to solve the above-described problems, and provides a technique capable of setting an access right required by an application as a security policy without depending on the operation history of the application. For the purpose.

  The security policy generation program according to the present invention reads at least one of an execution file of an application operating on the secure OS, an application setting file, and a file list constituting the application, and relates to these files on the secure OS. Analyze which access rights are required. The analysis result is output as a security policy candidate of the secure OS.

  According to the security policy generation program according to the present invention, it is possible to grasp which access authority is required when executing an application by analyzing a file related to the application. Thereby, it is possible to know the access authority necessary on the secure OS without executing the application. In addition, since the access authority is presented as a security policy candidate, the work load for setting the security policy can be reduced.

1 is a configuration diagram of a secure OS computer 100 according to Embodiment 1. FIG. 2 is a diagram illustrating a configuration of a security policy file 120 and data examples. FIG. 2 is a configuration diagram of an application package 140. FIG. 5 is a diagram illustrating a description example of an application setting file 142. FIG. 5 is a diagram illustrating a description example of an application configuration file 143. FIG. 3 is a functional configuration diagram of a security policy generation program 130. FIG. 3 is a diagram illustrating a configuration of a network permission pattern file 136 and an example of data. FIG. The structure and data example of the symbol permission correspondence table 137 are shown. It is a figure which shows the example of the result by which the disassembler part 131 disassembled the execution file of the application and converted into the assembly instruction. It is a figure which shows the example of the result as which the disassembler part 131 extracted the symbol by disassembling the execution file of an application. 4 is an overall operation flow of the security policy generation program 130. It is a figure which shows the detailed flow of step S1102. It is a figure which shows the detailed flow of step S1103. It is a figure which shows the detailed flow of step S1104. It is a figure which shows an example of the file access control policy setting screen 1500 which the setting presentation part 135 displays on a screen in step S1105. It is a figure which shows an example of the network access control policy setting screen 1600 which the setting presentation part 135 displays on a screen in step S1105. It is a figure which shows an example of the Capability access control policy setting screen 1700 which the setting presentation part 135 displays on a screen in step S1105.

<Embodiment 1>
FIG. 1 is a configuration diagram of a secure OS computer 100 according to the first embodiment of the present invention. The secure OS computer 100 is a computer equipped with a secure OS, and includes a secure OS 110, a security policy file 120, and a security policy generation program 130. If necessary, an application package 140 that stores application programs, necessary setting files, and the like can be installed. Furthermore, a package management program 150 for managing installed application packages may be provided.

  In addition to the configuration shown in FIG. 1, the secure OS computer 100 includes a secure OS 110 and a CPU (Central Processing Unit) that executes each of the above programs. In addition, a configuration such as a storage device such as an HDD (Hard Disk Drive) that stores data such as the secure OS 110, each of the above programs, and the security policy file 120, a memory, a network interface, and the like is provided as appropriate.

  In the following, for convenience of explanation, the secure OS 110 and the programs such as the above-mentioned programs may be described as the operation subject, but it is added that it is an arithmetic device such as a CPU that actually executes these programs. .

  The secure OS 110 is an OS of the secure OS computer 100. The secure OS 110 controls access to resources included in the secure OS computer 100 according to the description of the security policy file 120. An example of the security policy file 120 will be described later.

  The security policy generation program 130 analyzes a file included in the application package 140 and generates the security policy file 120 or a template thereof. Details will be described later.

  The application package 140 is a file in which an application execution file, an application setting file, an application configuration file, and the like are packaged together. Typically, it is configured in the form of an installer package. The internal configuration of the application package 140 will be described later.

  The package management program 150 manages application packages installed in the secure OS computer 100 and executes processing such as setting change and uninstallation.

  The operator 200 instructs the secure OS computer 100 to execute the security policy generation program 130 using a keyboard, a mouse or the like provided in the secure OS computer 100. Further, the content of the security policy file 120 is finally determined by correcting the template of the security policy file 120 presented by the security policy generation program 130. Screens used by the operator 200 for correction work will be described later.

  FIG. 2 is a diagram illustrating a configuration of the security policy file 120 and an example of data. Here, for convenience of explanation, an example of data in a table format is shown, but the data format is not limited to this.

  The security policy file 120 has a subject field 121, an object field 122, and a permission field 123.

  The subject field 121 describes an executable file name of a program that operates using access authority on the secure OS 110. An example of this field is a field describing the installation destination file path of the application execution file included in the application package 140.

  The object field 122 describes a resource on the secure OS 110 that is accessed by the program described in the subject field 121. The resource here means a file, a folder, a network port on the secure OS 110, a special access authority called “Capability” to be described later, and the like. That is, it refers to a target that requires access authority on the secure OS 110 for access.

  The permission field 123 describes the access authority that the program described in the subject field 121 has for the resource described in the object field 122. An example of this field is described below.

  The data example on the first line describes the access authority that the program “/ sbin / httpd” has for the file “/ var / www / *”. Since this line describes the access authority for the file, examples of the access authority include “read permission (read)” and “write permission (write)”.

  The data example on the second line describes the access authority that the program “/ sbin / httpd” has for the network resource “TCP port 80”. The access authority for network resources is similar to the access authority for files and folders, but the names are different. Here, it is exemplified that “bind (waiting for a connection request from the outside)” can be made to the TCP port 80.

  The data example on the third line describes that the program “/ sbin / ftpd” can execute the capability “setup”. Capability refers to a function that can directly call a kernel function (system call) provided in the secure OS 110 from an application program. When the kernel function is directly called, an operation exceeding the function of a normal application can be executed. Therefore, it is necessary to carefully set the access authority for the capability. The following are examples of Capabilities.

(Capability example 1: setup)
The setid is a function for temporarily changing a user ID for executing an application to another user ID. The other user ID referred to here may include a privileged user ID.
(Capability example 2: root)
“root” is a function for changing the root directory for the application. An application whose root directory has been changed cannot access files outside that range.

  FIG. 3 is a configuration diagram of the application package 140. The application package 140 is a file for installing an application running on the secure OS 110 in the secure OS computer 100, and internally includes an application execution file 141, an application setting file 142, and an application configuration file 143.

  The application execution file 141 is an execution format file that is the main body of the application. The application setting file 142 describes setting parameters used when the application execution file 141 is executed. The application configuration file 143 describes information about the entire application such as a list of files to be installed together with the application execution file 141 or a file to be modified, the name of the application, the version of the application, and the like. Examples of the application setting file 142 and the application configuration file 143 will be described with reference to FIGS.

  FIG. 4 is a diagram illustrating a description example of the application setting file 142. The first line describes a folder path where the application stores a cache file. The second line describes the TCP port number on which the application waits for connection.

  FIG. 5 is a diagram illustrating a description example of the application configuration file 143. The first line describes the name of the application. The second line describes the version number of the application. The third and subsequent lines describe a list of files that are newly installed or modified by installing the application. The package management program 150 performs processing such as installation, uninstallation, and content modification of these files.

  The configuration of the secure OS computer 100 has been described above. Next, the detailed configuration of the security policy generation program 130 will be described.

  FIG. 6 is a functional configuration diagram of the security policy generation program 130. The security policy generation program 130 includes a disassembler unit 131, a file access analysis unit 132, a network access analysis unit 133, a capability access analysis unit 134, a setting presentation unit 135, a network permission pattern file 136, and a symbol permission correspondence table 137. These may be configured in the same program file, or may be configured in the form of individual submodules.

  The disassembler unit 131 has a function of converting an application execution file into an assembly language, and a function of extracting a symbol used internally by the application execution file. A symbol is an identifier such as a function name used internally when an executable file calls a function. By analyzing which symbol the executable file uses, it is possible to determine which function the executable file uses. This function includes functions belonging to Capability access such as system calls.

  The file access analysis unit 132 estimates which file may be accessed when the application execution file 141 included in the application package 140 operates. Details will be described later with reference to FIG.

  When the application execution file 141 included in the application package 140 operates, the network access analysis unit 133 estimates which network resource may be accessed. Details will be described later with reference to FIG.

  The Capability access analysis unit 134 estimates which Capability access authority may be used when the application execution file 141 included in the application package 140 operates. Details will be described later with reference to FIG.

  The setting presentation unit 135 displays the analysis results of the file access analysis unit 132, the network access analysis unit 133, and the capability access analysis unit 134 on a display provided in the secure OS computer 100. The screen image will be described again with reference to FIGS.

  The network permission pattern file 136 describes an operation pattern presumed to be executed when an application execution file uses network resources. The network access analysis unit 133 matches the operation pattern described in this file with the operation pattern obtained from the processing result of the disassembler unit 131 or the file access analysis unit 132, and extracts the corresponding one. Details will be described later with reference to FIG.

  The symbol permission correspondence table 137 is a table describing a correspondence relationship between a symbol used by an execution file of an application and a Capability access authority necessary for using the symbol. The capability access analysis unit 134 matches the symbols obtained from the processing result of the disassembler unit 131 with the symbols described in this table, and extracts the corresponding ones. Details will be described later with reference to FIG.

  FIG. 7 is a diagram showing a configuration and data example of the network permission pattern file 136. The network permission pattern file 136 has a pattern field 1361 and a pattern name field 1362.

  A pattern field 1361 describes a pattern of assembly instructions to be executed when an application execution file accesses a network resource. Also, among the setting parameters that can be described in the application setting file 142, those that are used when the execution file accesses the network resource are described.

  A pattern name field 1362 describes a name provided for identifying each pattern.

Hereinafter, an example shown in each row of FIG. 7 will be described.
(Figure 7: Line 1: Port number)
The first line of FIG. 7 describes an assembly instruction pattern in which an execution file calls a UNIX (registered trademark) htons (host to network short) function to set a port number. When the execution file of the application executes these assembly instructions, it can be determined that the network resource (here, the port number) is accessed. The variable parameters are generalized using <>. In this example, the port number is variable for each execution, so <number> is described. The same applies to the following examples.

(Figure 7: 2nd line: bind system call)
The second line in FIG. 7 describes an assembly instruction pattern in which the execution file calls the bind system call and waits for a connection from the network. When waiting for a connection from the network, the network resource is used, and therefore it is necessary to determine whether or not the access right to the resource is appropriate. Therefore, when this pattern is included in the execution file, it is decided to extract it.

(Figure 7: 3rd line: connect system call)
The third line in FIG. 7 describes an assembly instruction pattern in which the execution file calls the connect system call to connect to the external network. When connecting to an external network, since network resources are used, it is necessary to determine whether or not the access authority to the resources is appropriate.

(Figure 7: 4th line: socket system call)
The fourth line in FIG. 7 describes an assembly instruction pattern in which an execution file calls a socket system call and sets a communication protocol to be used. The <number> part indicates the protocol. When the OS is Linux, if <number> is 1, TCP indicates that UDP is set. When setting a communication protocol, since network resources are used, it is necessary to determine whether or not the access authority to the resources is appropriate.

(Figure 7: 5th line: Port standby)
The fifth line in FIG. 7 describes an example of application setting parameters for waiting for an execution file to connect to a predetermined TCP port from an external terminal. This line exemplifies a pattern described in the application setting file 142. When the executable file opens a port and waits for a connection, the network resource is used, so it is necessary to determine whether or not the access right to the resource is appropriate. Although this line is common to the second line in that it describes a pattern waiting for a connection from the network, the second line is an assembly instruction pattern in the execution file, whereas this line is in the application setting file 142. This is different from the description pattern.

  The network access analysis unit 133 matches the operation pattern described in this file with the assembly instruction (or description in the application setting file 142) obtained from the processing result of the disassembler unit 131, and the two match. To extract. If there is a portion where both match, it is understood that the execution file accesses the network resource, so that it is extracted in order to set the access authority in a later step.

  FIG. 8 shows a configuration and data example of the symbol permission correspondence table 137. The symbol permission correspondence table 137 has a symbol field 1371 and a permission field 1372. The symbol permission correspondence table 137 describes which capability access authority is required when executing the function specified by the symbol included in the execution file. Since the symbol name does not necessarily indicate the capability access authority itself, the correspondence between the two is specified using this table.

  The capability access analysis unit 134 matches the correspondence described in this file with the assembly instruction obtained from the processing result of the disassembler unit 131, and extracts a portion where both match. When there is a portion where both match, it is understood that the execution file uses the capability access authority, so that it is extracted in order to set whether or not the access authority can be used in a later step.

  Here, only the correspondence between the symbol and the capability access authority is illustrated here, but when other access authority on the secure OS is required when executing the function corresponding to the symbol, the corresponding relation is described. You may do it.

  FIG. 9 is a diagram illustrating an example of a result of the disassembler unit 131 disassembling an application execution file and converting it into an assembly instruction. The network access analysis unit 133 extracts a part that matches the assembly instruction pattern described in the network permission pattern file 136 from the assembly instructions shown in FIG.

  FIG. 10 is a diagram illustrating an example of a result of the disassembler unit 131 disassembling an application execution file and extracting symbols. The capability access analysis unit 134 extracts a portion that matches the symbol pattern described in the symbol permission correspondence table 137 from the symbols shown in FIG.

  The detailed configuration of the security policy generation program 130 has been described above. Next, the operation of the security policy generation program 130 will be described.

  FIG. 11 is an overall operation flow of the security policy generation program 130. Hereinafter, each step of FIG. 11 will be described. Here, the case where each file included in the application package 140 is an analysis target is illustrated, but only one or two of the files can be the analysis target. For example, the application execution file 141 alone can be analyzed.

(FIG. 11: Step S1101)
The disassembler unit 131 of the security policy generation program 130 disassembles the application execution file 141 included in the application package 140, and obtains the analysis results illustrated in FIGS.

(FIG. 11: Step S1102)
The file access analysis unit 132 of the security policy generation program 130 analyzes the application setting file 142 and the application configuration file 143. Details of this step will be described later with reference to FIG.

(FIG. 11: Step S1103)
The network access analysis unit 133 of the security policy generation program 130 analyzes the processing result of step S1101 and the application configuration file 143 using the network permission pattern file 136. Details of this step will be described later with reference to FIG.

(FIG. 11: Step S1104)
The capability access analysis unit 134 of the security policy generation program 130 analyzes the processing result of step S1101 using the symbol permission correspondence table 137. Details of this step will be described later with reference to FIG.

(FIG. 11: Step S1105)
The setting presentation unit 135 of the security policy generation program 130 displays a screen for setting the security policy file 120, as illustrated in FIGS. The result of steps S1101 to S1104 is reflected on the same screen.

FIG. 12 is a diagram showing a detailed flow of step S1102. Hereinafter, each step of FIG. 12 will be described.
(FIG. 12: Step S1102_01)
The file access analysis unit 132 analyzes the application setting file 142 and extracts a list of files that may be accessed by the application. For example, a character string starting with “/” is determined as describing a file name and extracted. In the description example shown in FIG. 4, “/ var / chahce / foo” is extracted as the file name.

(FIG. 12: Step S1102_02)
The file access analysis unit 132 analyzes the application configuration file 143 and extracts a list of files that the application may access after installing the application. The extraction criteria may be the same as in step S1102_01. In the description example shown in FIG. 5, “/ sbin / foo”, “/etc/foo/foo.conf”, and “/ var / log / foo” are extracted as file names.

FIG. 13 is a diagram showing a detailed flow of step S1103. Hereinafter, each step of FIG. 13 will be described.
(FIG. 13: Step S1103_01)
The network access analysis unit 133 extracts a portion where the analysis result in step S1101 matches the assembly instruction pattern described in the network permission pattern file 136. When the example of the network permission pattern file 136 shown in FIG. 7 is compared with the example of the disassembly result shown in FIG. 9, the following results are obtained.

(FIG. 13: Step S1103_01: Extraction Example)
“Movl” and “call” in the fifth to sixth lines in FIG. 9 match the pattern for calling the socket function in the fourth line in FIG. “Movl” and “call” in the 7th to 8th lines in FIG. 9 match the pattern for calling the htons function in the 1st line in FIG. “Call” in the last line in FIG. 9 matches the pattern for calling the bind system call in the second line in FIG.

(FIG. 13: Step S1103_02)
The network access analysis unit 133 extracts a portion where the application setting file 142 matches the description pattern described in the network permission pattern file 136. When the example of the network permission pattern file 136 shown in FIG. 7 is compared with the description example of the application setting file 142 shown in FIG. 4, the following results are obtained.

(FIG. 13: Step S1103_02: Extraction Example)
“Listen on 9999” in the second line in FIG. 4 matches the pattern for waiting for network connection (pattern using the bind system call) described in the fifth line in FIG.

FIG. 14 is a diagram showing a detailed flow of step S1104. Hereinafter, each step of FIG. 14 will be described.
(FIG. 14: Step S1104_01)
The capability access analysis unit 134 extracts a portion where the analysis result in step S1101 matches the symbol pattern described in the symbol permission correspondence table 137. When the example of the symbol permission correspondence table 137 shown in FIG. 8 and the disassembly result example shown in FIG. 10 are compared, the following results are obtained.

(FIG. 14: Step S1104_01: Extraction Example)
“Root” in the fourth line in FIG. 10 matches the pattern for calling the root system call in the first line in FIG.

  FIG. 15 is a diagram showing an example of a file access control policy setting screen 1500 displayed on the screen by the setting presenting unit 135 in step S1105. The file access control policy setting screen 1500 displays the analysis results in step S1102, that is, the analysis results of the application setting file 142 and the application configuration file 143 on the screen.

  The file access control policy setting screen 1500 includes a check box 1501, a file list 1502, a permission selection box 1503, and an apply button 1504. The upper part of the screen has tabs for switching to the screens shown in FIGS.

  A check box 1501 selects whether to reflect the permission setting for the file displayed in the file list 1502 in the security policy file 120. To reflect, turn on the check.

  The file list 1502 displays a list of files extracted by the file access analysis unit 132 from the application setting file 142 and the application configuration file 143. The file list displayed here may be accessed by the application analyzed in the operation flow of FIG.

  The permission selection box 1503 has options for selecting which access authority is granted to the application analyzed in the operation flow of FIG. 11 for the files displayed in the file list 1502. Since the application is assumed to have at least read access to the file displayed in the file list 1502, the default value is “Read”.

  The access authority application button 1504 is a button for instructing the security policy generation program 130 to reflect the setting on the file access control policy setting screen 1500 in the security policy file 120.

  FIG. 16 is a diagram showing an example of a network access control policy setting screen 1600 displayed on the screen by the setting presenting unit 135 in step S1105. The network access control policy setting screen 1600 displays the analysis result in step S1103, that is, the analysis results of the application execution file 141 and the application setting file 142 on the screen.

  The network access control policy setting screen 1600 includes a protocol display unit 1601, a port number display unit 1602, a permission display unit 1603, a check box 1604, and an apply button 1605. The upper part of the screen has a tab for switching to the screen shown in FIG. 15 or FIG. 17 described later.

  The protocol display unit 1601, the port number display unit 1602, and the permission display unit 1603 display a list of network resources that can be accessed by the application analyzed in the operation flow of FIG. 11 as the analysis result of step S1103.

  The setter 200 selects a network resource to be reflected in the security policy file 120 using the check box 1604 and presses an apply button 1605. The security policy generation program 130 reflects in the security policy file 120 that access to the selected network resource is permitted.

  FIG. 17 is a diagram showing an example of the Capability access control policy setting screen 1700 displayed on the screen by the setting presenting unit 135 in step S1105. The Capability access control policy setting screen 1700 displays the analysis result in step S1104, that is, the analysis result of the application execution file 141 on the screen.

  The capability access control policy setting screen 1700 includes a check box 1701, a capability display unit 1702, and an apply button 1703. The upper part of the screen has tabs for switching to the screens shown in FIGS.

  A check box 1701 selects whether or not to reflect the permission setting for the capability access displayed in the capability display unit 1702 in the security policy file 120. To reflect, turn on the check. The capability display unit 1702 displays the list of capability access extracted in step S1104.

  The setter 200 selects the capability access authority to be reflected in the security policy file 120 using the check box 1701 and presses the apply button 1703. The security policy generation program 130 reflects in the security policy file 120 that access to the selected network resource is permitted.

<Embodiment 1: Summary>
As described above, the security policy generation program 130 according to the first embodiment reads at least one of the application execution file 141, the application setting file 142, and the application configuration file 143, and grants access authority that the application may use. Extract. As a result, the necessary access authority setting candidates can be presented without executing the application, so that the work load related to the setting of the security policy file 120 can be reduced.

  Also, the security policy generation program 130 according to the first embodiment disassembles the application execution file 141 and compares it with the network permission pattern file 136, and extracts an assembly instruction pattern for accessing the network resource. This makes it possible to present access authority candidates necessary for network resources without executing an application.

  In addition, the security policy generation program 130 according to the first exemplary embodiment extracts symbols included in the application execution file 141, and indicates the capability access authority required when executing the function corresponding to the symbol, in the symbol permission correspondence table. It is specified by 137. This makes it possible to present necessary Capability access authority candidates without executing the application.

  Further, it is assumed that the security policy generation program 130 according to the first embodiment extracts the file name described in the application setting file 142 or the application configuration file 143, and the application needs access authority to the file. And present it. This makes it possible to present access authority candidates necessary for the file without executing the application.

<Embodiment 2>
In the first embodiment, the secure OS 110 is assumed to be a UNIX-based OS, and UNIX system calls such as “root” and “setup” have been described as examples. However, the method according to the present invention can be applied to any secure OS.

  If the OS is different, what corresponds to the system call is different, and the expression form of the symbol name and network resource may be different. However, it is applicable to any OS in that at least one of the application execution file 141, the application setting file 142, and the application configuration file 143 is analyzed to extract necessary access authority candidates.

  In the first embodiment, an example in which the application package 140 or a file included in the application package 140 is analyzed has been described. However, an already installed execution file or the like can also be analyzed using the same method.

  100: secure OS computer, 110: secure OS, 120: security policy file, 121: subject field, 122: object field, 123: permission field, 130: security policy generation program, 131: disassembler unit, 132: file access analysis , 133: Network access analysis unit, 134: Capability access analysis unit, 135: Setting presentation unit, 136: Network permission pattern file, 1361: Pattern field, 1362: Pattern name field, 137: Symbol permission correspondence table, 1371: Symbol Field, 1372: permission field, 140: application package, 141: application Execution file, 142: application setting file, 143: application configuration file, 150: package management program, 200: setter, 1500: file access control policy setting screen, 1501: check box, 1502: file list, 1503: permission Selection box, 1504: Apply button, 1600: Network access control policy setting screen, 1601: Protocol display section, 1602: Port number display section, 1603: Permission display section, 1604: Check box, 1605: Apply button, 1700: Capability access Control policy setting screen, 1701: check box, 1702: capability display section, 1703: apply button.

Claims (5)

A program for causing a computer to execute a process for generating a security policy for a secure OS,
A read step of reading at least one of an execution file of an application operating on the secure OS, a setting file describing setting parameters of the application, and a configuration file describing a file list constituting the application;
When executing the executable file, when the executable file uses the setting parameter, or when the executable file uses a file described in the file list, any of the secure OSs An access analysis step for analyzing whether access authority is required;
Outputting the result of the access analysis step as a candidate for the security policy;
A security policy generation program characterized in that In the access analysis step, the computer
Disassembling and converting the executable to assembly language;
Extracting a process for accessing network resources on the secure OS from the assembly language;
Extracting an access right for accessing the network resource as an access right required on the secure OS;
The security policy generation program according to claim 1, wherein: In the access analysis step, the computer
A symbol extraction step of extracting symbols included in the executable file;
Reading a symbol permission correspondence table describing access authority required on the secure OS when executing a function corresponding to a symbol included in an execution file of an application;
A search step for searching for an access right described in the symbol permission correspondence table corresponding to the symbol extracted in the symbol extraction step;
Specifying the access authority obtained as a result of the search step as an access authority required on the secure OS;
The security policy generation program according to claim 1 or 2, wherein the security policy generation program is executed. In the access analysis step, the computer
Read access authority is required on the secure OS for the file specified by the setting file as the file used by the application or the file specified by the file list described by the configuration file The security policy generation program according to any one of claims 1 to 3, wherein the security policy generation program is determined. The security policy generation program according to any one of claims 1 to 4,
A secure OS using a security policy generated by the security policy generation program;
A secure OS computer system comprising:

Images