JP2011081501A - Operating system program and computer carrying the same - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce a user's burden while maintaining computer security to some extent. <P>SOLUTION: An OS program includes a policy database which has a combination of a plurality of system calls to be regulated and actions to show contents of regulation processing and a system call hook module for monitoring the system call from a process. The system call hook module makes a processor execute a step S13 to determine a policy match where there is a combination of system calls corresponding to a combination of a plurality of system calls in the policy database in a plurality of system calls received one by one from the process, a step S16 to output action in the policy database to an OS main function part for policy match, and a step S17 to output the received system call to the OS main function part for policy non-match. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a computer security technique using an operating system.

  In recent years, with the spread of computers and IP networks, the situation where computer security is threatened, such as information leakage from computers and computer virus infection, has increased rapidly, and the importance of computer security technology has increased.

  Computer security technology can be broadly classified into a technique for preventing unauthorized entry into a computer and a technique for minimizing damage even if the computer is illegally entered.

  In the latter method, the most widely used is an execution control method represented by access control. Here, access control is a technique for restricting executable operations and accessible objects for each subject. Note that a subject is an entity that actively operates and corresponds to a user, a process, or the like, and a process is a program that is being executed. An object is an object to be operated, and corresponds to a file, a directory, or the like.

  As a method by this access control, SELinux (Security Enhanced Linux) described in Non-Patent Document 1 below can be cited.

  This SELinux method is software developed mainly by the NSA (National Security Agency), and is a method of restricting access at the OS (Operating System) level for each process running on a computer. is there.

  In this SELinux method, a label called a domain is set for all processes running on a computer, and an access type called an access vector for each type, and an access vector for each type (no access, no read, By setting the process domain and the object type, the process access restriction for each object is realized at the OS level.

  In this way, in the SELinux method, process access restrictions are realized at the OS level, so even if an unauthorized intruder loses the root privilege of the computer, the objects that can be accessed by the unauthorized intruder are Limited and can minimize damage.

Translated by Bill Mccarty Hiroya Taguchi and Kensuke Nezu Translated by Hideyuki Hayashi "SELinux System Management-Basics and Operation of Secure OS" O'Reilly Japan March 25, 2005

  However, in the SELinux method described above, every time a new process is added, it is necessary to set a domain for this process and to associate the domain with the object type, which imposes a burden on the computer user. There is a problem.

  The present invention pays attention to such problems of the prior art, and an object of the present invention is to provide a technique capable of reducing the burden on the user while ensuring a certain level of computer security.

An OS program according to the invention for solving the above problems is as follows:
An operating system (hereinafter referred to as OS) main function module for processing various system calls from the process;
A policy database including a plurality of policy data having a combination of a plurality of system calls to be regulated and an action which is a system call indicating a regulation processing content when a system call of the combination is output from the process When,
A system call hook module for monitoring the system call from the process;
Have
The system call hook module is
A system call accepting step for accepting a system call from the process;
When the system call is accepted in the system call accepting step, the plurality of system calls included in any one of the policy data in the policy database during the plurality of system calls sequentially accepted in the system call accepting step. A determination step for determining whether or not there is a system call corresponding to a combination and a policy match; and
If it is determined that the policy match is determined in the determination step, the action in the policy data targeted when the policy match is determined is acquired, the action is output, and the determination If it is determined that the policy match is not the step, out of the system calls received in the system call reception step, an instruction output step for outputting the latest system call that is the trigger for the determination in the determination step;
To the computer processor,
The OS main function module is
An instruction receiving step for receiving the system call or the action output in the instruction output step;
An instruction execution step of executing the process indicated by the system call or the action received in the instruction reception step;
Is executed by the processor.

In addition, a computer according to an invention for solving the above problems is
The OS program is mounted.

  In the present invention, a plurality of policy data in a policy database pre-installed in the OS program is used to secure the computer security within a certain range, and a new process is added as in the conventional SELinux method. Each time it is done, there is no need to set a domain for this process and to associate this domain with the object type, thereby reducing the burden on the computer user.

It is a block diagram of the computer in 1st embodiment which concerns on this invention. It is explanatory drawing which shows the data structure of the policy database in 1st embodiment which concerns on this invention. It is explanatory drawing which shows the example of description of the policy context in 1st embodiment which concerns on this invention. It is explanatory drawing which shows the data structure of the task structure in 1st embodiment which concerns on this invention. It is a flowchart which shows operation | movement of the system call hook part in 1st embodiment which concerns on this invention. It is a flowchart which shows the detailed process of the policy match determination process (S13) of FIG. It is explanatory drawing which shows the update process of the policy context in 1st embodiment which concerns on this invention. It is explanatory drawing which shows the update process of the variable corresponding table in 1st embodiment which concerns on this invention. It is a flowchart which shows operation | movement of the OS main function part in 1st embodiment which concerns on this invention. It is a block diagram of the computer in 2nd embodiment which concerns on this invention. It is explanatory drawing which shows the data structure of the task structure in 2nd embodiment which concerns on this invention. It is a flowchart which shows operation | movement of the system call hook part in 2nd embodiment which concerns on this invention. It is a flowchart which shows the detailed process of the policy match determination process (S13A) of FIG.

  Embodiments of a computer according to the present invention will be described below with reference to the drawings.

"First embodiment"
A first embodiment of a computer according to the present invention will be described with reference to FIGS.

  As shown in FIG. 1, the computer 100 according to the present embodiment includes a CPU 110 that executes various arithmetic processes, a RAM 120 that serves as a work area of the CPU 110, a ROM 130 that stores data, programs, and the like, and a hard disk drive device. To communicate with other devices via the network N, an auxiliary storage device 140 such as a display 151, an input device 152 such as a keyboard and a mouse, an input / output interface 150 that is an interface of the display 151 and the input device 152, and the like. Network interface 160.

  The auxiliary storage device 140 stores an OS (Operating System) program 141 and an application program 148 in advance. The OS program 141 is an OS main function module 142 that is a program for processing various system calls from a process, a system call hook module 143 that is a program for monitoring system calls from a process, and a restriction target. And a policy database 144 including a plurality of policy data in which combinations of a plurality of system calls are shown.

  The CPU 110 functionally includes an OS execution unit 111 and a process 118. In the OS execution unit 111, the CPU 110 loads the OS main function module 142 into the RAM 120, and the OS main function unit 113 that functions by executing the OS main function module 142, and the CPU 110 loads the system call hook module 143 into the RAM 120. And a system call hook unit 113 that functions when executed. The process 118 functions when the CPU 110 loads the application program 148 into the RAM 120 and executes it.

  The RAM 120 includes a task struct 121 for managing the process 118 by the OS execution unit 111, a policy data copy 125 that is a copy of one policy data in the policy database 144, and a system call from the process 118. A variable correspondence table 127 showing the relationship between the existing variables and the assigned values is created.

  The policy database 144 stored in the auxiliary storage device 140 has a plurality of policy data 145 and an object type table 146 as shown in FIG.

  The policy data 145 includes a policy ID 145a for uniquely identifying the policy data, a policy context 145b describing a combination of a plurality of system calls to be regulated, and a regulation to be processed by the OS main function unit 112. And an action 145c indicating the processing content.

  Here, the policy ID 145a is assigned 1, 2, 3,... In the order of the policy data having the highest importance.

  The policy context 145b is a combination of a plurality of system calls that may cause an unfavorable situation for the user, such as information leakage or system down, that is, as described above, a plurality of system calls to be regulated. Is described.

  The action 145c is a system call indicating the contents of restriction processing to be performed by the OS main function unit 112 when a plurality of system calls from the process match the policy context 145b. In the policy data 145, the area where the action 145c is described is when there is no system call to be processed by the OS main function unit 112 when a plurality of system calls from the process match the policy context 145b. Is blank. Further, in the policy data 145, an area in which the action 145c is described may describe a plurality of system calls by specifying the execution order.

  Specifically, the action 145c describes a system call “exit (1)” that means forced termination of the process that has output the system call, a system call that means stop of this process, and the like. In the action 145c, a system call for outputting an error message and a reception system call may be described in a form in which an output order is determined. This action means that a system call for outputting an error message is first output to the OS main function unit 112, and then the system call accepted in step 10 is output to the OS main function unit 112.

  The object type table 146 includes an object name area 146a for storing names of objects (access targets) such as files and directories stored in the auxiliary storage device 140, an object type area 146b for storing object attributes, Have

  As attributes of the object stored in the object type area 146b, there are “secret” indicating a file containing confidential information, “normal” indicating a general file, and the like.

  The plurality of policy data 145 in the policy database 144 is basically incorporated in advance in the OS program 141. However, the OS main function unit 112 receives new policy data from the input device 151. Alternatively, it is also possible to accept changes in existing policy data and store them in the policy database 144.

  Further, in the areas 146a and 146b of the object type table 146, when a file or the like is newly stored in the auxiliary storage device 140, it is received from the input device 151 by the OS main function unit 112 or the system call book unit 113. Data is stored. Therefore, when creating a new file or the like, the user operates the input device 151 and designates the object name and the object type. However, every time a user creates a new file, the user does not necessarily specify the object name and object type. However, when creating a file containing confidential information, the object name and object type Is preferably specified.

  Next, a specific description format of the policy context 145b described above will be described with reference to FIG.

  A combination of a plurality of system calls is expressed using “→”, “and”, and “or”.

  “→” indicates the order of system calls described on both sides centered on this “→”, and the system call described on the left side of “→” is more than the system call described on the right side of “→”. This symbol indicates that the output order from the process is first.

  “And” is a symbol that means that the system calls described on both sides of “and” are system calls from the process. Further, “or” is a symbol that means that one of the system calls described on both sides of “or” is a system call from a process.

  In addition, variables and object type conditional variables can be described as system call arguments. Variables are described in one or more alphabets. In the object type conditional variable, first, the object type is described, “&” is described on the right side of the object type, and the variable is described using one or more alphabets on the right side of the “&”.

  Specifically, the policy context 145Ab in FIG. 3 outputs the system call “sendto (x, y)” from the process after the system call “open (x)” is output from the process, and the system call “ This policy expresses the meaning that the argument of “open (x)” is equal to the first argument of the system call “sendto (x, y)”.

  Therefore, after the system call “open” is actually output from the process, the system call “sendto” is output from the process, and the arguments of the system call “open” and the first argument of the system call “sendto” Are equal, the combination of these system calls matches the policy indicated by this policy context 145bA.

  Actually, after the system call “open (x)” is output from the process, another system call is output from the process, and then the system call “sendto (x, y)” is output from the process. In this embodiment, it is defined that this policy matches the policy indicated by the policy context 145Ab.

  Further, the policy context 145Bb in FIG. 3 outputs a system call “open (x)” and a system call “sendto (x, y)” from the process, and an argument of the system call “open (x)”. This policy expresses the meaning that the first argument of the system call “sendto (x, y)” is equal.

  The policy context 145Cb in FIG. 3 is a policy expressing the meaning that one of the system calls “open (x)” and the system call “sendto (x, y)” is output from the process.

  In the policy context 145Db, one of the system call “open (x)” and the system call “read (x)” is output from the process, and then the system call “sendto (x, y)” is output from the process. In addition, the policy expresses the meaning that the argument of the system call “open (x)” or the system call “read (x)” is equal to the first argument of the system call “sendto (x, y)”.

  The policy context 145Eb in FIG. 3 outputs the system call “sendto (x, y)” from the process after the system call “open (x)” is output from the process, and the system call “open (x)”. ”And the first argument of the system call“ sendto (x, y) ”, and the object type of the argument“ x ”of the system call“ open (x) ”and the system call“ sendto (x, y) ” "Is a policy that expresses the meaning that the object type of the first argument" x "is" secret_t ".

  As described above, in the present embodiment, the combination of a plurality of system calls includes not only a case where a plurality of system calls are all included, but also a case where any of a plurality of system calls is included or a plurality of system calls. In addition, when the order is determined, a combination of these is included.

  The specific description format of the policy context 145b has been described above. Needless to say, a combination of a plurality of system calls may be described in another description format.

  Next, the task struct 121 will be described with reference to FIG.

  This task struct 121 is created on the RAM 120 by the OS execution unit 111 when the application program 148 (FIG. 1) related to the process 118 is started in order to manage the process 118 (FIG. 1).

  The task struct 121 includes a process state area 121a in which process states (normal operation, stopped, etc.) are stored, a process ID area 121b in which a process ID for uniquely identifying a process is stored, and a process It has a used memory amount area 121c for storing the used memory amount, a system call table 121d for storing a system call history from the process, and an area for storing the usage status of the CPU (not shown).

  The task struct 121 is created on the RAM 120 by the OS main function unit 112 when the application program 148 related to the process 118 is started. Also, the OS main function unit 112 updates all the data of each area of the task struct 121 except for the system call table 121d. On the other hand, the system call hook unit 113 updates the data in the system call table 121d.

  The system call hook unit 113, among the system calls sequentially output from the process 118, has a system call name that matches the system call name described in any of the policy data 145 in the policy database 144, as will be described later. System calls are stored in the system call table 121d in a linear list format. For example, in the case of a system call “open (x)”, “open” is the system call name.

  When adding a new system call to the system call table 121d, the system call hook unit 113 stores “→” and the new system call at the end of the list in the system call table 121d.

  Thus, by sequentially storing the system calls in the system call table 121, it is possible to specify the output order of each system call from the process.

  Next, the operation of the system call hook unit 113 will be described with reference to the flowcharts shown in FIGS.

  When the application program 148 is activated and the process 118 by the application program 148 becomes operable, the OS main function unit 112 expands the task struct 121 related to the process 118 on the RAM 121. At this stage, nothing is described in the system call table 121d (FIG. 4) of the task struct 121.

  When the process 118 becomes operable, the system call hook unit 113 starts monitoring the process 118, waits for a system call output from the process 118 (S10), and receives a system call from the process 118. It is determined whether or not the system call name of this system call matches the system call name of any system call described in the policy database 144 (S11).

  If the system call hook unit 113 determines that the system call name of the system call received in step 10 does not match the system call name of any system call described in the policy database 144, the system call hook unit 113 determines that the system call received in step 10 The data is output to the OS main function unit 112 (S17), and the process returns to Step 10. If the system call hook unit 113 determines that the system call name of the system call received in step 10 matches the system call name of any system call described in the policy database 144, the system call received in step 10 The call is described in the system call table 121d (FIG. 4) developed on the RAM 120 (S12). Then, the system call hook unit 113 performs policy match determination with policy data for the system call described in the system call table 121d (S13).

  If the system call hook unit 113 determines in the policy match determination process (S13) that the system call described in the system call table 121d matches the policy data, the policy ID of the policy data is stored in the RAM 120. Memorize temporarily. The policy match determination process will be described later in detail with reference to FIG.

  When the policy match determination process (S13) ends, the system call hook unit 113 determines whether a policy ID is stored in the RAM 120 (S14). When the system call hook unit 113 determines that the policy ID is not stored in the RAM 120, in other words, the system call described in the system call table 121d does not match the policy data, the system call hook unit 113 accepts it in step 10. The system call is output to the OS main function unit 112 (S17), and the process returns to Step 10.

  When the system call hook unit 113 determines that the policy ID is stored in the RAM 120, in other words, the system call described in the system call table 121d matches the policy data, the policy call An action which is a type of system call is extracted from the policy data of the ID (S15), this action is output to the OS main function unit 112 (S16), and the process returns to step 10.

  Next, detailed processing of the policy match determination processing (S13) will be described.

  Here, for convenience of the following description, as shown in the system call table 121d of FIG. 4, the process 118 outputs a system call “open (myfile)”, and then the system call “sendto (myfile, server)”. ”And then the system call“ close (...) ”Is output. Further, the policy database 144 stores only the policy data 145 of the policy ID “8” shown in FIG. 2 as the policy data 145, and the object type table 146 stores the data shown in FIG. Assume.

  As described above with reference to FIG. 5, when the system call “open (myfile)” is output from the process 118 and is received by the system call hook unit 113 (S10), the system call name “open” of this system call is Then, the system call name described in the policy data 145 of the policy database 144 shown in FIG. 2 is compared (S11). At this time, the system call hook unit 113 determines that the policy data 145 matches the system call name “open” of the received system call, and stores this system call “open (myfile)” in the RAM 120. It is described in the system call table 121d (FIG. 4) developed above (S12), and the policy match determination process (S13) is started.

  In the policy match determination process, as shown in the flowchart of FIG. 6, the system call hook unit 113 first extracts a system call as a head element from the system call table 121d as a target system call (S20). In this case, since only the system call “open (myfile)” is described in the system call table 121d, this system call “open (myfile)” is extracted as the target system call.

  Next, the system call hook unit 113 determines whether all the policy data 145 has been copied (S21). In this case, since the policy data 145 has not yet been copied, it is determined that not all of the policy data 145 has been copied, and the uncopied policy data 145 is copied and this is used as the policy data copy 125 to expand the RAM 121. At the same time, the change correspondence table 127 is expanded on the RAM 120 (S22).

  As shown in FIGS. 2 and 7, the policy data copy 125A created at this stage is a copy of the policy data 145. Therefore, the same policy ID 125a as the policy ID 145a of the policy data 145, and the policy data 145 The policy context copy 125Ab is the same as the policy context 145b and the action 125c is the same as the action 145c of the policy data.

  Further, as shown in FIG. 8, the variable correspondence table 127A stores a variable area 127a in which the arguments “x, y” in the policy data copy 125A are stored as variables, and an argument of the target system call as an assigned value. And an assigned value area 127b. At this stage, in the variable correspondence table 127A, arguments “x, y” of all system calls described in the polysilicon text copy 125Ab are stored in the variable area 127a, and nothing is stored in the substitution value area 127b. Not.

  The system call hook unit 113 compares the polysilicon text copy with the target system call (S23), and determines whether or not the target system call matches the corresponding element in the policy context copy (S24).

  In this determination, an element match is determined when the following three conditions a) b) c) are satisfied. However, the condition c) is a condition applied when the element corresponding to the target system call in the policy context copy is an object type conditional variable, and the element corresponding to the target system call in the policy context copy is an object. If the variable is not a type conditional variable, it is determined as an element match if the two conditions a) and b) are satisfied.

  a) The system call name of the target system call exists in the policy context copy.

  b) The arguments in the target system call are consistent with the combinations of variables and substitution values in the variable correspondence table 127A.

  c) The object type related to the argument in the target system call matches the object type described in the corresponding system call of the policy context copy.

  In this case, since the system call name “open” of the target system call “open (myfile)” and the system call name that is the first element in the polysilicon text copy 125Ab are “open” or “read”, the system call The hook unit 113 determines that the condition a) is satisfied.

  Further, in the variable correspondence table 127A (FIG. 8), “x, y” is stored in the variable area 127a, nothing is stored in the substitution value area 127b, and any value can be substituted as the substitution value. Since it is possible, the argument “myfile” in the target system call “open (myfile)” does not contradict the combination of the variable in the variable correspondence table 127A and the assignment value in the variable correspondence table 127A, and the system call hook The unit 113 determines that the condition b) is satisfied. In addition, the case where it contradicts is mentioned later.

  The object type related to the argument “myfile” in the target system call “open (myfile)” is “secret_t” according to the object type table 146 (FIG. 2), and the corresponding system call “open” in the policy context 125Ab Since the object type described in “1” is also “secret_t”, the system call hook unit 113 determines that the condition c) is satisfied.

  Therefore, in this case, the system call hook unit 113 determines that the target system call “open (myfile)” is element matched with the policy context 125Ab.

  If the system call hook unit 113 determines in step 24 that the target system call does not match the policy context copy, the system call hook unit 113 proceeds to step 27. If the system call hook unit 113 determines that the element matches, the polysilicon text copy and variable correspondence table 127 Is updated (S25).

  Here, the update of the polysilicon text copy means that the description content of this policy context copy is changed by changing the corresponding element for the target system call to "true" indicating that it matches in the policy context copy. Is to organize.

  Specifically, as shown in FIG. 7, in updating the polysilicon text copy 125Ab, the system call hook unit 113 first sets “open (secret_t & x)” determined as an element match in the polysilicon text copy 125Ab. Then, the polysilicon text copy 125Bb changed to “true” indicating the match is created. Next, since the left side of “or” in the policy context copy 125Bb becomes “true”, the policy context copy 125Cb is created by changing the whole or expression to “true”. This is the end of updating the policy context copy at this stage.

  The updating of the variable correspondence table 127 here is to store the argument of the target system call in the substitution value area 127b of the variable correspondence table 127.

  Specifically, as shown in FIG. 8, the system call hook unit 113 assigns a substitution value area corresponding to the argument “x” of the corresponding element in the polysilicon text copy 125Ab out of the substitution value area 127b of the variable correspondence table 127A. The argument “myfile” of the target system call “open (myfile)” is stored in 127b, and the variable correspondence table 127B is created.

  When the policy context copy and update of the variable correspondence table 127 are completed (S25), the system call hook unit 113 determines whether or not the policy is matched by accepting the target system call (S26), and determines that the policy is matched. The policy ID 125a of the policy data copy 125 is stored in the RAM 120 as a match policy ID (S29). If it is determined that the polycyan match, the process proceeds to step 27. The policy match determination is based on whether or not the description content of the policy context copy is only “true”.

  Here, as shown in FIG. 7, since the description content of the policy context copy 125Cb is not only “true”, it is determined as a polycyan match, and the process proceeds to step 27.

  The system call hook unit 113 determines whether or not all elements have been extracted from the system call table 121d when it is determined in step 24 that the elements do not match, and further, in the case where it is determined that polycyan matches in step 26 described above. (S27). If all elements have been extracted, the process proceeds to step 30, and if all elements have been extracted, the process proceeds to step 28.

  In this case, since only the system call “open (myfile)” is described in the system call table 121d, the system call hook unit 113 determines that all elements are extracted from the system call table 121d, and step 30 is performed. Proceed to

  In step 30, the system call hook unit 113 deletes the policy data copy and variable correspondence table 127 from the RAM 120 and returns to step 21.

  In step 21, the system call hook unit 113 determines whether all the policy data 145 has been copied as described above. Here, as described above, since it is assumed that one policy data 145 is not stored in the policy database 144, it is determined that all the policy data 145 has been copied, and the policy match determination process (S13) is performed. finish. On the other hand, when a plurality of policy data 145 is stored in the policy database 144, the system call hook unit 113 executes the processes after step 22 described above.

  As described above with reference to FIG. 5, the system call hook unit 113 determines whether or not the match policy ID is stored in the RAM 120 when the policy match determination process (S13) described above is completed (S14). ). In this case, since the match policy ID is not stored in the RAM 120, the system call accepted in step 10 is output to the OS main function unit 112 (S17), and the process returns to step 10.

  Next, a case where the system call “sendto (myfile, server)” is output from the process 118 after the above-described system call “open (myfile)” is output will be described.

  As described above with reference to FIG. 5, when the system call “sendto (myfile, server)” is output from the process 118 and is received by the system call hook unit 113 (S10), the system call name “sendto” of this system call is received. And the system call name described in the policy data 145 of the policy database 144 shown in FIG. 2 (S11). At this time, the system call hook unit 113 determines that the policy data 145 matches the system call name “sendto” of the received system call, and sends this system call “sendto (myfile, server)”. The information is added to the system call table 121d (FIG. 4) developed on the RAM 120 (S12). As a result, open (myfile) →... → sendto (myfile, server) is described in the system call table 121d.

  Next, the system call hook unit 113 performs policy match determination processing (S13). In this policy match determination process, the system call hook unit 113 first extracts a system call as a head element from the system call table 121d as a target system call as shown in the flowchart of FIG. 6 (S20). In this case, since the system call “open (myfile)” is described as the head element in the system call table 121d, this system call “open (myfile)” is extracted as the target system call.

  Thereafter, the system call hook unit 113 executes steps 21, 22, 23, 24, 25, 26, and 27 in the same manner as the policy match determination process when the system call “open (myfile)” is received. As a result, the policy context copy is in the state of the policy context copy 125Cb in FIG. 7, and the variable correspondence table 127 is in the state of the variable correspondence table 127B in FIG.

  In step 27, the system call hook unit 113 determines whether all elements have been extracted from the system call table 121d as described above. In this case, since the system call “sendto (myfile, server)” is described in addition to the system call “open (myfile)” in the system call table 121 d, the system call hook unit 113 is configured to use the system call table 121 d. From step S28, it is determined that all elements have not been extracted.

  In step 28, the system call hook unit 113 extracts the next element from the system call table 121d, sets this as the target system call, and returns to step 23. In this case, the system call hook unit 113 extracts the system call “sendto (myfile, server)” as the target system call.

  Next, as described above, the system call hook unit 113 compares the polysilicon text copy with the target system call (S23), and whether or not the target system call matches the corresponding element in the policy context copy. Is determined (S24).

  In this element match determination, since the element “sendto (x, y)” corresponding to the target system call “sendto (myfile, server)” in the policy context copy 125Cb is not an object type conditional variable, the above three conditions a) b) If condition a) b) is satisfied among c), it is determined as an element match.

  In this case, since the system call name “sendto” of the target system call “sendto (myfile, server)” and the system call name corresponding to the polysilicon text copy 125Cb are “sendto”, the system call hook portion 113 determines that the condition a) is satisfied.

  In this case, in the variable correspondence table 127B (FIG. 8), “x, y” is stored in the variable area 127a, and “myfile” is stored in the substitution value area 127b as the substitution value corresponding to the variable x. The substitution value for the variable y is not stored. In addition, the argument “myfile, server” in the target system call “sendto (myfile, server)” does not contradict the combination of the variable in the variable correspondence table 127A and the assigned value in the variable correspondence table 127A, and the system call The hook unit 113 determines that the condition b) is satisfied. If the target system call is “sendto (ourfile, server)”, since the value corresponding to the variable x is “ourfile” instead of “myfile”, the variables and variables in the variable correspondence table 127A are displayed. It is determined that the combination with the substitution value in the correspondence table 127A is inconsistent and the condition b) is not satisfied.

  Therefore, in this case, the system call hook unit 113 determines that the target system call “sendto (myfile, server) is element matched with the policy context 125Cb.

  If the system call hook unit 113 determines in step 23 that the target system call matches the policy context copy, the system call hook unit 113 updates the polysilicon text copy and variable correspondence table 127 (S25).

  Specifically, as shown in FIG. 7, when updating the polysilicon text copy 125Cb, the system call hook unit 113 first selects “sendto (x, y)” determined as an element match in the polysilicon text copy 125Cb. Then, the polysilicon text copy 125Db changed to “true” indicating the match is created. Next, since both sides of “→” in the policy context copy 125Db have become “true”, the policy context copy 125Eb in which the whole is changed to “true” is created. The policy context copy update is thus completed.

  Further, as shown in FIG. 8, the system call hook unit 113 sets the argument “y” among the arguments “x, y” of the corresponding element in the polysilicon text copy 125Cb in the substitution value area 127b of the variable correspondence table 127B. ”Is stored in the substitution value area 127b corresponding to“ sendto (myfile, server) ”, and a variable correspondence table 127E is created.

  When the policy context copy and update of the variable correspondence table 127 are completed, the system call hook unit 113 determines whether or not a policy match has been made by accepting the target system call as described above (S28). In this case, since the description content of the policy context copy 125Eb is only “true”, the policy match is determined, and the process proceeds to step 29.

  In step 29, the system call hook unit 113 stores the policy ID 125a of the policy data copy 125 in the RAM 120 as a match policy ID, as described above. In this case, the policy ID 125a “8” of the policy data copy 125 is stored in the RAM 120 as a match policy ID.

  Then, the system call hook unit 113 deletes the policy data copy 125 and the variable correspondence table 127 from the RAM 120 (S30), and then returns to step 21.

  If the system call hook unit 113 determines in step 21 that all the policy data 145 has been copied, the policy match determination process (S13) ends.

  As described above with reference to FIG. 5, the system call hook unit 113 determines whether or not the match policy ID is stored in the RAM 120 when the policy match determination process (S13) described above is completed (S14). ). In this case, since the match policy ID “8” is stored in the RAM 120, the system call hook unit 113 extracts “exit (1)” as the action 145c from the policy data 145 of the match policy ID “8”. (S15). The system call hook unit 113 outputs “exit (1)” as the action 145c to the OS main function unit 112 (S16), and then returns to step 10.

  In the policy match determination process (S13), since determination is performed for all of the plurality of policy data, the system call described in the system call table 121d matches the plurality of policy data and is stored in the RAM 120. Multiple match policy IDs may be stored. In this case, the system call hook unit 113 outputs to the OS main function unit 112 in order from the action in the policy data having a small match policy ID, that is, a high importance in step 16.

  Next, the operation of the OS main function unit 112 will be described with reference to the flowchart shown in FIG.

  The OS main function unit 112 waits for a system call output from the system call hook unit 113 (S40). When this system call is received, the OS main function unit 112 executes this system call (S41) and returns to step 40.

  The system call output from the system call hook unit 113 includes a system call received by the system call hook unit 113 from the process 118 and a system call as an action output by the system call hook unit 113 when a policy match is made. . Further, the system call as an action includes only a system call indicating process operation restriction, and may include a system call indicating process operation restriction and a reception system call (system call received from the process 118). is there.

  The OS main function unit 112 executes the above system call. Specifically, when a system call meaning forced termination or stop of a process is received as a system call as an action output by the system call hook unit 113 when a policy match is made, this process is forcibly terminated or stopped. Further, when a reception system call is accepted as a system call as an action following a system call for outputting an error message, the reception system call is executed after an error message is displayed on the display 152.

  As described above, in this embodiment, the security of the computer is ensured within a certain range by using a plurality of policy data in the policy database 144 pre-installed in the OS program 141. Thus, each time a new process is added, it is not necessary to set a domain for this process and to associate the domain with the object type, thereby reducing the burden on the computer user.

  Further, in the conventional SELinux method, for example, when an object is accessed by the system call “open”, if this object is a type of access restriction, execution of this system call is not permitted. However, in practice, information is not leaked to the outside simply by accessing a regulated object. That is, it is not necessary to prevent the act of accessing this object even for an object subject to access restriction.

  On the other hand, in the present embodiment, if there is policy data combining the system call “open” and the system call “sendto (system call indicating that an object is sent to another computer)” as policy data, This system call “open” is executed even if the object with the system call “open” is subject to access control. Then, after executing this system call “open”, if an attempt is made to execute the system call “sendto”, this execution is not permitted. Therefore, in this embodiment, information leakage can be prevented without unnecessarily restricting execution of system calls.

  In this embodiment, the OS main function unit 112 creates the task call 121 including the system call table 121d on the RAM 120. However, although the system call table 121d is created on the RAM, this system call table When 121d is not provided in the task struct 121, the system call hook unit 113 may create and update the system call table 121d.

"Second embodiment"
A second embodiment of the computer according to the present invention will be described with reference to FIGS.

  The computer 100A of the present embodiment has the same hardware configuration as that of the first embodiment, but differs only in the software configuration. That is, the OS program 142A stored in the auxiliary storage device 140 is different from the first embodiment.

  The OS program 142A includes an OS main function module 142A and a system call hook module 143A that are different from those in the first embodiment, and a policy database 144 that is the same as that in the first embodiment.

  Thus, since the OS main function module 142A and the system call hook module 143A are different from the first embodiment, the OS execution unit 111A that is one of the functional configurations of the CPU 110, the OS main function unit 112A that is an element thereof, and the system call The hook portion 113A is also different from the first embodiment. Note that differences from the first embodiment regarding the OS main function unit 112A and the system call hook unit 113A will be described in the description of the operation described later.

  As shown in FIG. 11, the task struct 121A created on the RAM 120 has a policy data copy table 121e instead of the system call table 121d in the first embodiment.

  This policy data copy table 121e includes policy data copies 125, 125,..., Which are all of the policy data 145 stored in the policy database 144, and variables associated with the respective policy data copies 125, 125,. Correspondence tables 127, 127,...

  This task struct 121A is created on the RAM 120 when the OS main function unit 112A starts up the application program 148 related to the process 118. In addition, among the data of each area of the task struct 121A, the data of all areas except the policy copy table 121e are all updated by the OS main function unit 112A. On the other hand, the data in the policy copy table 121e is updated by the system call hook unit 113A.

  Next, the operation of the system call hook unit 113 will be described with reference to the flowcharts shown in FIGS. In FIG. 12 and FIG. 13, blocks that are given different signs from the first embodiment are blocks that perform processing different from the first embodiment.

  When the application program 148 is activated and the process 118 by the application program 148 becomes operable, the OS main function unit 112A develops a task struct 121A related to the process 118 on the RAM 121. At this time, in the policy data copy table 121e of the task struct 121A, as described above, the policy data copies 125, 125,... Of all the policy data 145 in the policy database 144 are created, and each policy data copy is also created. Variable correspondence tables 127, 127,... Are created in association with 125, 125,.

  The OS main function unit 112A of the present embodiment is different from the first embodiment in the operation of creating the task struct 121A described above.

  When the process 118 becomes operable, the system call hook unit 113A starts monitoring the process 118, waits for a system call output from the process 118 (S10), and receives a system call from the process 118. For this system call, a policy match with policy data is determined (S13A).

  Next, similarly to the first embodiment, the system call hook unit 113A determines whether or not a policy ID is stored in the RAM 120 (S14). When the system call hook unit 113A determines that no policy ID is stored in the RAM 120, in other words, a polycyan match, the system call hook unit 113A outputs this system call to the OS main function unit 112A (S17), and returns to step 10.

  When the system call hook unit 113A determines that the policy ID is stored in the RAM 120, in other words, a policy match, the system call hook unit 113A extracts an action that is a type of system call from the policy data copy of the policy ID (S15A) Then, after deleting the policy data copy 125 and variable correspondence table 127 of the policy ID, the new policy data copy 125 and variable correspondence table 127 of the policy ID is reproduced (S19). Then, the system call hook unit 113A outputs the action extracted in step 15A to the OS main function unit 112 (S16), and returns to step 10.

  Next, detailed processing of the policy match determination processing (S13A) will be described with reference to the flowchart of FIG.

  The system call hook unit 113A compares all the polysilicon text copies 125b, 125b,... In the policy data copy table 121e with the target system call (S23A), and this target system call is in any policy context copy 125b. Whether or not the corresponding element is matched is determined by the same determination method as in the first embodiment (S24A).

  If the system call hook unit 113A determines that the target system call does not match any of the corresponding elements in any policy context copy 125b, it immediately ends this policy match determination process (S13A).

  If the system call hook unit 113A determines that the elements match, it updates all policy context copies 125b determined to be element matches and the variable correspondence table 127 corresponding thereto by the same method as in the first embodiment. (S25A).

  Next, the system call hook unit 113A determines whether any of the policy context copies 125b updated in step 25A indicates that there is a policy match (S26a). Whether or not the policy context copy 125b indicates a policy match depends on whether or not the description content is only “true”, as in the first embodiment.

  If the system call hook unit 113A determines that any policy context copy 125b indicates a policy match, the system call hook unit 113A stores the policy ID 125a of the policy data copy 125b in the RAM 120 as a match policy ID (S29A). The determination process (S13A) ends. If it is determined that the polycyan match, the policy match determination process (S13A) is immediately terminated.

  As described above, in this embodiment as well, in this embodiment, the security of the computer is ensured within a certain range by using a plurality of policy data in the policy database 144 incorporated in advance in the OS program 141. The effect similar to 1st embodiment can be acquired.

  Furthermore, in this embodiment, although the generation time of the task struct 121A is longer than that in the first embodiment, the loop processing of steps 21 to 30 (FIG. 6) is performed for all policy data as in the first embodiment. Since all the policy data is processed together in each step without performing the processing, the overall processing speed can be increased.

  In this embodiment, the OS main function unit 112 creates the task struct 121A including the policy data copy table 121e on the RAM 120. However, although the policy data copy table 121e is created on the RAM 120, the task When not provided in the struct 121A, the system call hook unit 113 may create the policy data copy table 121e.

  100, 100A: Computer, 110: CPU, 111, 111A: OS execution unit, 112, 112A: OS main function unit, 113, 113A: System call hook unit, 118: Process, 120: RAM, 121, 121A: Task Struct, 121d: system call table, 121e: policy data copy table, 125: policy data copy, 125a: policy ID, 125b: policy context copy, 125c: action, 127: variable correspondence table, 140: auxiliary storage device, 141 141A: OS program, 142, 142A: OS main function module, 143, 143A: System call hook module, 144: Policy database, 145: Policy data, 146: Object type table, 148: Application Deployment program

Claims (8)

In an OS program having an operating system (hereinafter referred to as OS) main function module for processing various system calls from a process,
A policy database including a plurality of policy data having a combination of a plurality of system calls to be regulated and an action which is a system call indicating a regulation processing content when a system call of the combination is output from the process When,
A system call hook module for monitoring the system call from the process;
Have
The system call hook module is
A system call accepting step for accepting a system call from the process;
When the system call is accepted in the system call accepting step, the plurality of system calls included in any one of the policy data in the policy database during the plurality of system calls sequentially accepted in the system call accepting step. A determination step for determining whether or not there is a system call corresponding to a combination and a policy match; and
If it is determined that the policy match is determined in the determination step, the action in the policy data targeted when the policy match is determined is acquired, the action is output, and the determination If it is determined that the policy match is not the step, out of the system calls received in the system call reception step, an instruction output step for outputting the latest system call that is the trigger for the determination in the determination step;
To the computer processor,
The OS main function module is
An instruction receiving step for receiving the system call or the action output in the instruction output step;
An instruction execution step of executing the process indicated by the system call or the action received in the instruction reception step;
Causing the processor to execute
An OS program characterized by that. In the OS program according to claim 1,
The system call hook module is
Each time a system call is accepted in the system call accepting step, the system call name of the system call matches the system call name of the system call included in any one of the policy data of the policy database A call name determination step for determining whether or not to perform,
A system call storage step of storing the system call of the system call name determined to match in the call name determination step in the storage means of the computer as a system call history;
To the processor,
In the determining step, it is determined whether or not there is a combination corresponding to a combination of a plurality of system calls in any of policy data in the policy database among a plurality of system calls in the system call history. If there is a corresponding combination, the policy match is used.
An OS program characterized by that. In the OS program according to claim 2,
In the determination step,
A policy data copy step of copying one copy of uncopied policy data among a plurality of policy data in the policy database and storing the policy data in the storage means as a policy data copy;
The latest system call is extracted as a target system call from the system call history, the target system call is compared with the policy data copy, and a plurality of target system calls and a plurality of policy data copies included in the policy data copy are compared. An element match determination step for determining whether or not there is an element match corresponding to any one of the system calls;
When it is determined in the element match determination step that the target system call corresponds to any one of a plurality of system calls included in the policy data copy and is the element match A policy data copy update step for changing the corresponding system call in the policy data copy to a description indicating that an element match has occurred;
It is determined whether or not the policy data updated in the policy data copy update step includes a system call that does not match the elements, and is determined as the policy match when the system calls that do not match the elements are not included. A policy matching step;
When it is determined that the element match is not the element match in the element match determination step, and when it is determined that the policy match determination step is not the policy match, the system call history is the newest system call next to the target system call. A target system call extraction step that extracts the element match determination step with respect to the new target system call,
Run
The policy data copy step is repeatedly executed when the new target system call cannot be extracted from the system call history.
An OS program characterized by that. In the OS program according to claim 3,
The OS main function module or the system call hook module is
Receiving the object identification information stored in the storage means of the computer and the object type indicating whether or not access to the object should be restricted, and storing the object type in the storage means of the computer, Let the processor run,
In the element match determination step,
Determining whether a system call name of the target system call matches a system call name of any one of the plurality of system calls included in the policy data copy;
If it is determined that both system call names match, if the corresponding system call in the policy data copy that matches the system call name of the target system call includes an object type, refer to the storage means. , Grasp the object type related to the argument included in the target system call, determine whether both object types match,
When it is determined that both object types match, the element match is used.
An OS program characterized by that. In the OS program according to claim 1,
The OS main function module or the system call hook module copies all policy data in the policy database at the time of starting the process, and stores the copy in the storage unit of the computer as a policy data copy Causing the processor to execute steps,
In the determination step,
Each time a system call is accepted in the system call accepting step, the system call is regarded as a target system call, all policy data copies stored in the storage means are compared, and the target system call and all the policy data are compared. An element match determination step for determining whether or not an element match corresponds to any one of a plurality of system calls included in the copy; and
In the element match determination step, it is determined that the target system call corresponds to any one of a plurality of system calls included in all the policy data copies and is the element match. Then, the policy data copy update step for changing the corresponding system call in the policy data copy to a description indicating that the element match has occurred,
It is determined whether or not the policy data updated in the policy data copy update step includes a system call that does not match the elements, and is determined as the policy match when the system calls that do not match the elements are not included. A policy matching step;
Run the
An OS program characterized by that. In the OS program according to claim 5,
The OS main function module or the system call hook module is
Receiving the object identification information stored in the storage means of the computer and the object type indicating whether or not access to the object should be restricted, and storing the object type in the storage means of the computer, Let the processor run,
In the element match determination step,
Determining whether a system call name of the target system call matches a system call name of any one of the plurality of system calls included in the policy data copy;
If it is determined that both system call names match, if the corresponding system call in the policy data copy that matches the system call name of the target system call includes an object type, refer to the storage means. , Grasp the object type related to the argument included in the target system call, determine whether both object types match,
When it is determined that both object types match, the element match is used.
An OS program characterized by that. In the OS program according to claim 1,
The combination of the plurality of system calls included in the policy data is data that includes the plurality of system calls and describes the combination form of the plurality of system calls.
An OS program characterized by that. In a computer comprising storage means and a processor for executing various processes,
The OS program according to any one of claims 1 to 7 is stored in the storage unit,
The processor executes the OS main function module and the system call hook module in the OS program.
A computer characterized by that.

Images