JP2006190050A - Multitask execution system and multitask execution method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow safe cooperative work among tasks by access control of fine granularity without lowering the execution efficiency. <P>SOLUTION: The multitask execution system 1 is provided with: a specific key generation/imparting function 103 for generating a specific key and imparting it to an object to be operated; and a system call processing function 104 for decoding authority data of an operation subject task by using the specific key when the system call for performing operation to the object to be operated is called by the operation subject task and deciding on the basis of the decoded authority data whether or not the system call can be executed. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a multitask execution system and a multitask execution method using a modern operating system (OS) capable of executing a plurality of tasks simultaneously in parallel.

  In recent years, virtually all computers (computers), from personal computers (PCs) used by individuals to server computers that provide services such as EC (Electric Commerce), and supercomputers, have become “multitasking”. "Environment" is provided.

  The "multitasking environment" here is an environment that can simultaneously execute multiple "tasks" that are units of processing handled by computers. In the near future, even on platforms with limited resources such as mobile phones. It is expected to provide such a multitasking environment.

  In general, in an operating system that provides such a multitasking environment, not only a plurality of independent tasks can be executed simultaneously, but a plurality of independent tasks can cooperate to accomplish one task.

  Such collaborative work is realized in the form of “intertask communication” or “sharing of files, memories, etc. by a plurality of tasks”.

  However, particularly in a “multi-user system” in which a plurality of users having different interests can use one computer at the same time, a task operating on the same computer may be executed by different users. Therefore, it is a problem that a cooperative work can be freely performed between arbitrary tasks.

  Moreover, even if a computer is used only by a single user, there are generally tasks that are not directly executed by the user, such as tasks for managing the computer system itself. Even if it is a computer, it can be a problem that collaboration can be freely performed between arbitrary tasks.

  In order to solve such a problem, the collaborative work between tasks is limited by using properties such as “related relationships between tasks”, “access rights to specific resources such as files” and “user identifiers”. The method is known.

  In “UNIX (registered trademark)”, which is a typical multitasking operating system, as a method of restricting the cooperative work between tasks using “related relationships between tasks”, as a means of communication between related tasks. A method using a pipe to be used is known.

  In addition, as a method of restricting the cooperative work between tasks by using “access right to a specific resource such as a file”, a UNIX (registered trademark) domain socket used as a bidirectional communication means between arbitrary tasks is used. The method is known.

  Further, as a method of using the “user identifier”, a method of using a signal and shared memory that is asynchronous unidirectional communication is known.

  According to these methods, it is possible to permit collaborative work only between tasks that meet the respective conditions, so it is possible to solve the problem that the collaborative work is freely performed between arbitrary tasks. .

  However, each of these methods has a problem that the granularity of restricting the cooperative work between arbitrary tasks is coarse, and in principle, the cooperative work cannot be restricted between tasks executed by the same user. there were.

  Furthermore, in UNIX (registered trademark), a “root user” exists as a privileged user for managing a computer system. However, a task (root task) that operates under the “root user” is subject to all restrictions. In addition, since any operation can be performed on any task, there is a problem that interference from the root task cannot be prevented.

  Since the same concept of privileged users is adopted in many multitasking operating systems, it can be said that protecting other tasks from attacks by such privileged users is an important security issue. Note that many of the attacks that have occurred in recent years have occurred as a result of hijacking a task operating under a privileged user through a security hole.

  As a method for solving such a problem, an operating system called “trusted operating system” that realizes access right management in a stricter form is known.

  For example, in the operating system “SELinux” disclosed in Non-Patent Document 1, the above-described access authority management is realized by a technique called “Mandatory Access Control (MAC)”. “Mandatory access control” assigns finer granularity to most objects (files, tasks, etc.) existing on computer systems than when using conventional user identifiers, and is based on the assigned access rights. This is a technology that enforces access control.

  Since this essential access control technology is also applied to the above-mentioned root task, even if it is a root task, it is impossible to interfere with an arbitrary task, and a safe collaborative work is performed between tasks. Can realize an environment that can.

  Further, Patent Document 1 discloses access control using a “thread” which is a finer unit than a “task” as a program execution unit. The access control according to Patent Literature 1 is configured to explicitly set whether or not to permit a desired operation on a predetermined thread of a specific thread.

Specifically, according to Patent Document 1, operation authority information (that is, a predetermined thread) describing information on a thread (thread that performs an operation) that is permitted or denied to perform a desired operation on the operation target thread. By assigning information indicating which thread is allowed to perform the desired operation to the operation target thread, access control with fine granularity is realized.
JP 7-200317 A “Security-Enhanced Linux”, [searched on December 23, 2004], Internet <URL: http://www.nsa.gov/selinux/>

  However, in the conventional trusted operating system, all the objects existing on the computer system are newly labeled for managing the access right in addition to the owner label that existed in the normal operating system. Therefore, there is a problem that the cost of system management increases.

  In addition, there is a risk of a security hole if appropriate access authority cannot be given to an object, but it has been pointed out that this work becomes more difficult as the number of objects increases. Therefore, operating such a trusted operating system on a daily basis is much more difficult than operating an ordinary operating system.

  In addition, since a thread is a type of object that repeatedly generates and disappears dynamically in a computer system, the access control shown in Patent Document 1 causes a new thread to be created and disappeared each time on the computer system. Therefore, it is necessary to review the operation authority information to be assigned to the existing thread to which the operation authority information is given, and there is a problem that the execution efficiency is lowered.

  Therefore, the present invention has been made in view of the above points, and a multitask execution system and multitask execution that enable safe collaborative work between tasks by fine-grained access control without reducing execution efficiency. It aims to provide a method.

  The first feature of the present invention is that a unique key generation / grant function for generating and assigning a unique key to an operation target object and a system call for performing an operation on the operation target object are called by an operation subject task. The authority data confirmation function for decrypting authority data of the operating subject task using the unique key and determining whether or not the system call can be executed based on the decrypted authority data. The gist of this is a multitask execution system.

  According to this invention, when the authority data confirmation function can decrypt the authority data of the operation subject task with the unique key assigned to the operation target object and is permitted by the authority data, the operation subject task Is configured to allow an operation on the operation target object to be performed, so that a safe cooperative work between tasks can be realized.

  In addition, according to the invention, since authority data is generated not for the operation target object but for the operation subject task, every time a new object (including a task) is generated or deleted on the computer system. In addition, it is not necessary to review the granted authority data.

  That is, according to this invention, when a new operation subject task is generated, when an operation authority is newly obtained or abandoned during the execution of the operation subject task, only the operation subject task is operated on the operation target object. Since the authority only needs to be set, the complicated operation of reviewing the operation authority for the existing operation target object is not necessary.

  In the first aspect of the present invention, a task authentication function for performing an authentication process for the operation subject task in response to an authority data generation request from the operation subject task, and generating the authority data based on the authentication process result And an authority data generation function.

  In the first aspect of the present invention, the system includes a task information storage function for managing whether or not authentication processing for the operation subject task is performed, and the task authentication function refers to the task information storage function. When the authentication process for the operation subject task is not performed, the authentication process for the operation subject task may be performed.

  In the first feature of the present invention, the task authentication function is configured not to perform authentication processing for a child task of the operation subject task when the authentication processing for the operation subject task is performed. Also good.

  In the first aspect of the present invention, the operation subject task may be a login task that performs a login authentication process of a user, and the child task may be a login shell task that is executed after the login authentication process.

  In the first aspect of the present invention, the authority data confirmation function determines whether or not the system call can be executed based on a first condition, and determines that the system call can be executed. In this case, it may be configured to determine whether or not the system call can be executed based on the decrypted authority data.

  In the first aspect of the present invention, when the authority data confirmation function determines that the system call can be executed based on the authority data, the system call is executed based on a second condition. It may be configured to have a system call processing function for determining whether or not it can be performed.

  In the first feature of the present invention, the task information storage function is configured not to manage whether or not authentication processing is performed for a task that operates independently of user control. It may be.

  In the first aspect of the present invention, the unique key generation / giving function may be configured to generate a common key used in a common key encryption algorithm as the unique key.

  In the first feature of the present invention, the unique key generation and grant function may be configured to generate a public key and secret key pair used in a public key encryption algorithm as the unique key.

  In the first aspect of the present invention, as the authority data, a task ID for identifying the operation subject task, a system call ID for identifying the system call, an operation mode in the system call, and a validity period of the authority data You may be comprised so that can be set.

  The second feature of the present invention includes a unique key generation / grant function that generates and grants a unique key to the first task and the second task, and the first task includes the unique key. Is used to encrypt the authority data for the second task and send the encrypted authority data to the second task, the second task being the first task The multitask execution system is configured to determine that the first task is a legitimate task when the authority data transmitted from can be decrypted with the unique key. To do.

  According to a third aspect of the present invention, in the operating system, a step of generating and assigning a unique key to the operation subject task; and in the operating system, when the system call is called from the operation subject task, Decrypting authority data of the operation subject task using a unique key, and determining whether or not the system call can be executed based on the decrypted authority data. Is the gist.

  According to a fourth aspect of the present invention, in the operating system, a step of generating and assigning a unique key to the first task and the second task, and using the unique key in the first task, Encrypting the authority data for the second task and transmitting the encrypted authority data to the second task; and in the second task, the authority data transmitted from the first task The gist of the present invention is a multitask execution method including a step of determining that the first task is a legitimate task when decryption is possible using the unique key.

  As described above, according to the present invention, it is possible to provide a multitask execution system and a multitask execution method that enable safe collaborative work between tasks by fine-grained access control without reducing execution efficiency. Can do.

(Configuration of multitask execution system according to the first embodiment of the present invention)
The configuration of the multitask execution system 1 according to the first embodiment of the present invention will be described with reference to FIGS.

  The multitask execution system 1 according to the present embodiment realizes an environment in which a plurality of tasks 204 flexibly and safely perform cooperative operations in a modern operating system 101 capable of executing a plurality of tasks 204 in parallel at the same time. To be configured to manage task rights.

  In this specification, “an object to be operated” must be a kind that can actively perform a desired operation on another object (operation target object), and therefore, “a process (independent of other processes)”. Must be an object that is a unit for operating a program on a computer, such as “execution unit having a memory space” and “thread (execution unit sharing memory space with other threads)”.

  In the present specification, it is not necessary to distinguish between a process and a thread, and hence, “objects to be operated” will be collectively referred to as “operation subject tasks”.

  The multitask execution system 1 according to the present embodiment includes an operating system 101 and a plurality of objects. Here, the object includes a task 204-X that operates under the management of the operating system 101, a file 201-X and a memory 202-X that are the operation targets of the operating system 101 and the task 204-X, and a communication socket. 203-X and the like are included.

  In the case of performing communication between tasks, the task 204-X may also be an operation target. Therefore, the task 204-X plays a role as an operation subject task and also plays a role as an operation target object. There is also.

  An object including the task 204-X is assigned a unique key assignment area 205-X for assigning a unique key that can uniquely identify the object in the multitask execution system 1.

  The unique key assignment area 205-X is configured not to be accessible from other tasks. This property of “inaccessibility from other tasks” is due to an access management function provided by the trusted operating system, a method of encrypting the unique key assignment area 205-X with a key accessible only by the operating system, or the like. Can be realized.

  As will be described later, such a unique key is generated by a pseudo random number generation function 102 and a unique key generation / granting function 103 in the operating system 101, and is given to an object that requires management of fine-grained operation authority. Is.

  In the multitask execution system 1 according to the present embodiment, the task 204-X is determined to have the operation authority for the object by possessing data that can be verified by the unique key.

  Hereinafter, data that can be verified with a unique key assigned to such an object is referred to as “authority data”.

  In general, an operation on an operation target object by the operation subject task 204 -X is performed by a system call provided by the operating system 101.

  As shown in FIG. 1, the operating system 101 of the multitask execution system 1 according to this embodiment includes a pseudo-random number generation function 102, a unique key generation / assignment function 103, a system call processing function 104, and an authority data confirmation function 105. An authority data generation function 106, a task information storage function 107, an authority data storage function 108, a task authentication function 109, and an authentication information inheritance function 110.

  As shown in FIG. 2, the pseudo-random number generation function 102 generates a cryptographically strong pseudo-random bit string using key inputs, mouse inputs, various interrupts, thermal noise, and entropy sources such as random number generation hardware as original data. It is configured as follows.

  The unique key generation / assignment function 103 is configured to generate a unique key unique within the multitask execution system 1 based on the pseudo random number bit string generated by the pseudo random number generation function 102.

  For example, the unique key generation / assignment function 103 is configured to generate, as the unique key, a common key used in the common key encryption algorithm, or a public key / private key pair used in the public key encryption algorithm.

  The unique key generation / assignment function 103 is configured to assign the generated unique key to the operation target object. That is, the unique key generation / assignment function 103 is configured to store the generated unique key in the unique key assignment area 205 of the operation target object.

  When the system call processing function 104 receives a system call for performing an operation on the operation target object 201-1 called by the operation subject task 204-1, the system call processing function 104 executes the system call to the authority data confirmation function 105. It is configured to inquire about availability.

  Further, when the system call processing function 104 receives an answer indicating that the system call can be executed by the authority data confirmation function 105, the system call processing function 104 executes the system call, that is, the operation subject task 204-1 operates the object to be operated. It is configured to permit a desired operation to be performed on 201-1.

  The authority data confirmation function 105 is stored in the task information storage function 107 using the unique key for the operation target object 201-1 acquired from the unique key generation and grant function 103 in response to an inquiry from the system call processing function 104. The authority data of the operating subject task 204-1 is decrypted, and it is determined whether or not the system call can be executed based on the decrypted authority data.

  The authority data generation function 106 is configured to generate authority data of the operation subject task based on the authentication processing result for the operation subject task by the task authentication function 109.

  As shown in FIG. 3, the authority data generation function 106 includes “execution file name”, “task ID”, “system call type”, “operation mode”, and “valid start” as authority data for each object. "Time" and "Effective end time" can be set.

  Both “executable file name” and “task ID” identify an operation subject task that can perform an operation on the object. Here, the two types of information “executable file name” and “task ID” make it possible to specify the operation subject task when it already exists as a task at the time of generating authority data, and at that point it is still This is because it corresponds to two cases where the task does not exist.

  In general, the “task ID” assigned by the operating system 101 when a certain execution file is executed to become a task cannot be determined before the execution of the execution file.

  However, the proper use of “executable file name” and “task ID” as information for designating the operation subject task is not limited to the above example, and an already executing task is determined by “executable file name”. You may specify, and you may use both together.

  Furthermore, in order to realize authority data indicating that any task can perform an operation on the object as long as the task owns the authority data without specifying the operation subject task, the “executable file name” and “ A “wild card” (“*” in FIG. 3) may be used for “task ID”.

  The “system call type” indicates the type of system call permitted to be performed on the object (that is, the system call permitted to be performed on the object is identified). The “operation mode” indicates an operation mode in a system call that is permitted to be performed on the object.

  Furthermore, the validity period of the authority data can be set by the “valid start time” and the “valid end time”. By determining the validity period of the authority data, it is possible to reduce the risk of unnecessary authority data being misused after the system call is executed.

  In the example of FIG. 3, the authority data is expressed in a table format, but the expression format is not limited to this.

  The authority data generation function 106 is configured to encrypt the generated authority data with the unique key of the operation target object. As a result, the authority data is uniquely associated with a specific operation target object, so that the authority data cannot be diverted to other operation target objects.

  The authority data generation function 106 is configured to store the encrypted authority data in the operation subject task area in the task information storage function 107.

  The task information storage function 107 holds an independent operation subject task area corresponding to each task 204-X existing on the multitask execution system 1, and the authority data for the operation subject task is stored as the operation subject. It is configured to record in the task area.

  The task information storage function 107 is configured to manage whether or not an authentication process for a specific operation subject task is being performed. Specifically, as illustrated in FIG. 4, the task information storage function 107 displays “task ID” and “authentication processing” indicating whether or not authentication processing is being performed for the operation subject task identified by the task ID. "Process" is stored in association with each other.

  The authority data storage function 108 does not already exist as a task, but the authority data is stored in the file so that the authority data can be assigned in advance to an execution file that becomes a task at some point in the future. Configured to save as. In addition to the authority data, the execution file includes information such as a start date and time, a start command, and an argument.

  For example, the operating system 101 is configured to generate a specific task at the start date and time stored in the execution file according to the start command and arguments stored in the execution file.

  The task authentication function 109 is configured to perform an authentication process for the operation subject task in response to an authority data generation request (system call) from the operation subject task.

  That is, the authority data described above is generated by an authority data generation request (system call) from the operation subject task, but authority data indicating that an arbitrary task can perform an operation on an arbitrary object can be acquired. In other words, it is equivalent to not performing any authority management. Therefore, the task authentication function 109 is configured to limit the tasks that can generate such authority data, that is, generate and record authority data after determining that the task is a correct task.

  Here, the task authentication function 109 may be configured to perform the above-described authentication process by diverting a function used by a normal operating system to perform the user authentication process, or a unique authentication process. A function for performing the above-described authentication processing may be prepared and the above-described authentication process may be performed.

  Further, the task authentication function 109 may be configured to refer to the task information storage function 107 and perform the authentication process for the operation subject task when the authentication process for the operation subject task is not performed. Good.

  Further, the task authentication function 109 is configured not to perform the authentication process for the child task of the operation subject task when the authentication processing for the operation subject task is performed.

  The authentication information inheritance function 110 is configured to cause the child task of the operation subject task to inherit information that the authentication process for the operation subject task has already been performed.

  That is, the authentication information inheritance function 110 generates the authenticated information and authority data corresponding to the operation subject task 204-1 recorded in the task information storage function 107, and thereafter generated by the operation subject task 204-1. It is configured to be inherited for a child task.

  The authentication information inheritance function 110 needs to be realized as an additional function to the general operating system 101. For example, in the case of an operating system in UNIX (registered trademark), a child task is a task related to the parent task itself. Since it is generated in the form of copying information (authenticated information, authority data, etc.), it is not specifically required.

  In any case, it is possible to grant authority data only to the operator task that has performed the authentication process, and to allow the child task to inherit information that the authentication process has already been performed. That is, as a child task of a task that is executed after logging in after logging in to a computer (generally, it is a command interpretation system called a login shell, but in a window environment, a window manager or the like often plays a role) The convenience of using a computer is ensured in the form of performing various tasks.

  As described above, the operating system 101 according to the present embodiment is a case where a system call for operating the operation target object 201-1 is called by the operation subject task 204-1, and the operation target object 201-1 is operated. When the operation authority for 1 is managed, whether or not the system call can be executed by checking whether or not the operating subject task 204-1 that called the system call has appropriate authority data Is configured to determine.

(Operation of the multitask execution system according to the first embodiment of the present invention)
The operation of the multitask execution system according to the first embodiment of the present invention will be described with reference to FIGS.

  First, with reference to FIG. 5, an operation of generating authority data in the operating system 101 of the multitask execution system 1 according to the present embodiment will be described.

  When the authority data generation function 106 receives an authority data generation request (system call) from the operating subject task 204-1 via the system call processing function 104 in step S101, the authority data generation function 106 refers to the task information storage function 107 in step S102. Thus, it is determined whether or not the authentication process for the operation subject task 204-1 has already been performed.

  If it is determined that the authentication process has already been performed, the operation proceeds to step S104. If it is determined that the authentication process has not yet been performed, the operation proceeds to step S103.

  In step S103, the task authentication function 109 performs an authentication process for the operation subject task 204-1 as will be described later.

  If the result of the authentication process is affirmative in step S104, that is, if the received authority data generation request is confirmed to be valid, the operation proceeds to step S105, and the result of the authentication process is negative. If there is, that is, if the received authority data generation request is not recognized as valid, this operation ends abnormally.

  As a criterion for determining the validity of the authority data generation request, when the operation subject task 204-1 and the operation target object 201-1 belong to the same user, the operation subject task 204-1 is assigned to the operation target object. The policy is to make it possible to grant authority data indicating that any operation can be performed.

  Then, as in the case where authority data indicating that the operation subject task can perform a desired operation needs to be given to an operation target object belonging to a user different from the user to which the operation subject task belongs, The policy is preferably configured to require explicit settings in advance only in cases where it does not work well. As a result, by executing the above-described authentication process as a precondition for acquiring the authority data while avoiding the complicated pre-setting as in the trusted operating system, the executing subject task 204-1 can execute the program. Even in the case of being hijacked due to a security hole in the middle, it is possible to prevent a bad act from being performed on another operation target object 201-1 in the multitask execution system 1.

  In step S105, the authority data generation function 106 generates authority data indicating that the operation subject task can perform a desired operation on the operation target object. In step S106, the authority data generation function 106 converts the authority data into the operation data. It is encrypted with the unique key for the target object and recorded in the operation subject task area of the task information storage function 107.

  Secondly, with reference to FIG. 6, the authentication process for the operation subject task 204-1 will be described.

  In step S201, the task authentication function 109 determines whether or not the task 204-1 that has called the authority data generation request (system call) described above is a task that is permitted to request generation of authority data. . As described above, this determination is realized by performing an authentication process for the owner of the task.

  Such authentication processing may be performed using a user name and password used when logging in to a general operating system, and may include a biometric data such as a personal identification number, a one-time password and a fingerprint, and a secret key on a smart card. Technology can be used.

  Depending on the technology used for the authentication process, if the user is determined to be an authorized user as a result of presenting appropriate information (password, fingerprint data, secret key on the smart card, etc.) to the multitask execution system 1, The operation proceeds to step S203, and otherwise, the operation ends abnormally.

  In step S203, the task authentication function 109 records information (authenticated information) indicating that the authentication process for the operation subject task 204-1 has been completed in the task information storage function 107.

  Thirdly, referring to FIG. 7 and FIG. 8, in the multitask execution system 1 according to the present embodiment, a system call called by the operation subject task 204-1 (to perform an operation on the operation target object 201-1). The operation to execute is described.

  In the example of FIG. 7, the operating system 101 determines whether or not the system call can be executed based on the normal condition (first condition), and determines that the system call can be executed. In addition, it is configured to determine whether or not the system call can be executed based on the decrypted authority data.

  The multitask execution system 1 in the example of FIG. 7 is a method that realizes finer-level authority management in an operating system that can perform only general coarse-grained authority management, that is, the limitation of the cooperative work provided by the operating system. Employs a strengthening method.

  As shown in FIG. 7, in step S301, the system call processing function 104 determines whether or not the system call can be executed based on a normal condition (first condition) such as a user ID.

  If it is determined that it is possible, the operation proceeds to step S302. If it is determined that the operation is not possible, the operation performs error processing in step S306 (that is, ends without executing the system call). To do).

  In step S302, the authority data confirmation function 105 determines whether or not a unique key is assigned to the operation target object 201-1.

  If not granted, this operation directly executes the system call in step S307. If granted, the operation proceeds to step S303.

  In step S <b> 303, the authority data confirmation function 105 determines whether authority data is stored in the area for the operation subject task 204-1 in the task information storage function 107. If stored, the operation proceeds to step S304. If not stored, the operation proceeds to step S306.

  In step S304, the authority data confirmation function 105 determines whether the stored authority data can be decrypted with the unique key assigned to the operation target object. If the decoding is successful, the operation proceeds to step S305. If the decoding is not possible, the operation proceeds to step S306.

  In step S306, the authority data confirmation function 105 determines whether or not the processing content to be executed by the system call is described in the authority data (that is, whether or not the system call can be executed). .

  If the determination result is affirmative, in step S307, the system call processing function 104 executes the system call. On the other hand, if the determination result is negative, in step S306, the system call processing function 104 ends without executing the system call.

  On the other hand, in the example of FIG. 8, when the operating system 101 determines whether or not the system call can be executed based on the decrypted authority data, and determines that the system call can be executed, It is configured to determine whether or not the system call can be executed based on a normal condition (second condition).

  The multitask execution system 1 in the example of FIG. 8 is a method for allowing an operation in a form in which authority settings are temporarily overridden in an operating system that requires subordinate authority management like a trusted operating system. In other words, a system that relaxes restrictions on cooperative work provided by the operating system is adopted.

  As shown in FIG. 8, in step S401, the authority data confirmation function 105 determines whether a unique key is assigned to the operation target object 201-1. If not, the operation proceeds to step S406. If granted, the operation proceeds to step S402.

  In step S <b> 402, the authority data confirmation function 105 determines whether authority data is stored in the area for the operation subject task 204-1 in the task information storage function 107. If stored, the operation proceeds to step S403. If not stored, the operation proceeds to step S406.

  In step S403, the authority data confirmation function 105 determines whether the stored authority data can be decrypted with the unique key assigned to the operation target object. If the decoding is successful, the operation proceeds to step S404. If the decoding is not possible, the operation proceeds to step S406.

  In step S404, the authority data confirmation function 105 determines whether or not the processing content to be executed by the system call is described in the authority data (that is, whether or not the system call can be executed). .

  If the determination result is affirmative, the system call processing function 104 executes the system call in step S405. On the other hand, if the determination result is negative, in step S406, the system call processing function 104 executes the system call based on a condition (second condition) in a normal trusted operating system such as a user ID. Judge whether or not

  If it is determined that it is possible, in step S405, the system call processing function 104 executes the system call. On the other hand, if it is determined that it is not possible, the system call processing function 104 performs error processing in step S407 (that is, ends without executing the system call).

  Fourth, referring to FIG. 9, for example, as seen in UNIX (registered trademark), an operating system configured to generate a child task by duplicating its task information by the operation subject task. The processing required when executing the daemon task will be described.

  The daemon task is a general term for tasks that exist without parent-child relationship with other tasks and that provide services on the multitask execution system 1, that is, tasks that operate independently of user control.

  Daemon tasks are often used to provide services in response to requests from the network, and are therefore the type of task that is most often attacked. Therefore, if the daemon task can acquire arbitrary authority data, the risk to the multitask execution system 1 increases.

  Therefore, when generating the daemon task, the operating system 101 needs to delete the authentication processing completed information relating to the daemon task from the task information storage function 107.

  In other words, the task information storage function is configured not to manage whether or not authentication processing for the daemon task is being performed for a task (daemon task) that operates independently of user control.

  In order to generate authority data for a daemon task for which authenticated information has been deleted from the task information storage device 107, authentication processing for the daemon task must be performed. Authentication processing for daemon task users is essential. Therefore, since there is no opportunity to perform authentication processing for the user of the daemon task, it can be difficult for the daemon task hijacked by the attacker to perform a bad act on the multitask execution system 1.

  A daemon task is also generated as a child task of a specific task in the same way as a general task. Therefore, if authenticated information or authority data of a parent task is held in the task information storage function 107, the daemon task It is necessary to prevent inheritance of the authenticated information or authority data of the parent task.

  As shown in FIG. 9, when creating a daemon task, the operating system 101 determines whether or not authenticated information related to the daemon task is stored in the task information storage function 107 in step S501.

  If it is determined that the information is stored, the operating system 101 deletes the authenticated information in step S502. On the other hand, if it is determined that it is not stored, the operation proceeds to step S503.

  In step S <b> 503, the operating system 101 determines whether authority data relating to the daemon task is stored in the task information storage function 107.

  If it is determined that it is stored, the operating system 101 deletes the authority data in step S504. On the other hand, if it is determined that it is not stored, this operation ends.

(Operation and effect of the multitask execution system according to the first embodiment of the present invention)
According to the multitask execution system according to the first embodiment of the present invention, the authority data confirmation function 105 can decrypt the authority data of the operation subject task 204-1 with the unique key assigned to the operation target object 201-1. And when it is permitted by the authority data, the operation subject task 204-1 is configured to permit the operation on the operation target object 201-1. Collaborative work can be realized.

  Further, according to the multitask execution system according to the first embodiment of the present invention, since the authority data is generated not for the operation target object 201-1 but for the operation subject task 204-1, the computer system Whenever new objects (including tasks) are created or deleted, it is not necessary to review the granted authority data.

  That is, according to the multitask execution system according to the first embodiment of the present invention, when the operation subject task 204-1 is newly generated, the operation authority is newly obtained during the execution of the operation subject task 204-1 or When abandoning, it is only necessary to set the operation authority for the operation target object 201-1 only for the operation subject task 204-1. Therefore, it is complicated to review the operation authority for the existing operation target object 201-1. No need to operate.

(Modification 1)
With reference to FIGS. 10 and 11, a multitask execution system 1 according to the first modification of the present embodiment will be described.

  As illustrated in FIG. 10, the multitask execution system 1 according to this modification example includes a login task (operation subject task) 301 that performs user login authentication processing in addition to the operating system 101 according to the first embodiment described above. And a login shell task (child task) 302 executed after the login authentication process.

  Hereinafter, a login process (an example of an operating system in UNIX (registered trademark)) in the multitask execution system 1 according to the first modification will be described with reference to FIGS. 10 and 11.

  In step S601, when the user inputs a user name in response to a login prompt displayed on the display of the user terminal, the operating system 101 generates a login task (login task 301) for performing login authentication processing.

  When the user inputs a password in response to the password prompt displayed on the display of the user terminal, the login task 301 in the multitask execution system 1 determines whether or not the input password belongs to the user. By referring to the password database or the like, the login authentication process for the user is performed.

  If the login authentication process fails, the login task 301 requests re-input of the password for the predetermined number of attempts, and if all the login authentication processes fail thereafter, this operation ends in error.

  On the other hand, if the login authentication process is successful, in step S602, the login task 301 is executed after the login process in the task information storage function 105 to the effect that the login authentication process for the user has been completed (authenticated information). Record in the operation subject task area.

  In step S603, the login task creates a child task by copying the content of the login task itself by calling a fork system call.

  In step S604, the generated child task starts execution of the login shell task (initial program, command interpreting system program) by calling an execute system call (the argument is a login shell task).

  Here, since the authenticated information is recorded in the login shell task area in the task information storage function 107, the login shell task and child tasks further generated from the login shell task (excluding the daemon task) Thereafter, authority data can be freely acquired without requiring authentication processing by the task authentication function 109, so that convenience in a general system usage form is ensured.

  On the other hand, in step S605, the login task that is the parent task deletes the authenticated information registered in the task information storage function 107 after the fork system call processing ends, and then ends the login shell task that is the child task. Wait.

  The reason why the login task deletes the authenticated information from the task information storage function 107 is that if the login task is hijacked by an attacker, the risk of adversely affecting the multitask execution system 1 is as much as possible. This is to eliminate it.

  Note that the general login authentication process is an authentication process using a password as described above, but the present invention is not limited thereto. That is, since the multitask execution system 1 according to the present modification example holds not the password itself but abstract information indicating whether or not it is authenticated, other authentication such as smart card or public key encryption is used. The present invention can be easily applied to a system using the mechanism as a login authentication unit.

(Modification 2)
A multitask execution system 1 according to a second modification of the present embodiment will be described with reference to FIGS. In the second modification, the case where the operation target objects are both “tasks” is targeted. As described above, a case where a task is an operation target object can be seen, for example, when performing communication between tasks. FIG. 12 shows an example in which communication between tasks is performed between task A (204-1) and task B (204-2).

  In the second modification example, the unique key generation / granting function 103 determines whether the task A (first task) 204-1 and task B (second task) 204-2 are between task A and task B. A unique key for inter-task communication is generated and assigned.

  Further, the task A is configured to encrypt the authority data for the task B using the above-described unique key, and transmit the encrypted authority data to the task B.

  Further, the task B is configured to determine that the task A is a valid task when the authority data transmitted from the task A can be decrypted with the unique key.

  Hereinafter, with reference to FIG. 13, an operation in which inter-task communication is performed between the task A and the task B in the multitask execution system 1 according to the second modification will be described.

  In step S701, task A and task B acquire the unique key for inter-task communication generated by the unique key generation and grant function 103, and store it in the unique key assignment areas 205-7 and 205-8, respectively.

  In step S702, task A and task B acquire the authority data for the partner task generated by the authority data generation function 106, and store them in the unique key assignment areas 205-7 and 205-8, respectively.

  In step S703, task A and task B place authority data for the partner task at the head of the communication data for the partner task. Then, the task A and the task B that have received such communication data determine whether or not the authority data placed at the head of the communication data can be correctly verified (decrypted) with its own unique key.

  When the verification (decryption) is successful, the task A and the task B determine that the communication partner is a valid task, and perform reception processing on the communication data. On the other hand, if verification (decryption) fails, Task A and Task B determine that the communication partner is not a valid task, and discard the communication data without performing reception processing.

  In the multitask execution system 1 according to the second modification, it is possible to eliminate the intervention of the operating system by entrusting the execution of authority data verification work to the task itself.

  The multitask execution system 1 according to the second modification example has the properties that “the operation subject is a task”, “the operation content is not a system call”, and “the operation content is uniquely determined from the context in which it is executed”. As the contents of the authority data, only the “task ID” and the “valid period” need be described as shown in FIG. Further, since the operating subject already exists as a task, it is not necessary to allow a wild card for the task ID.

  In the multitask execution system 1 according to the second modification example, it is essential to hold the unique key so that it cannot be read from other tasks, and the authority data cannot be read from other tasks as well. It is desirable that

  As a method for safely storing such important data on the memory of a task that exists outside the protection range of the operating system, for example, a method other than the holding task disclosed in Japanese Patent Application Laid-Open No. 2004-272816 can be used. A technique for preventing access to the memory can be used.

1 is an overall configuration diagram of a multitask execution system according to a first embodiment of the present invention. It is a figure for demonstrating an example of the production | generation method of the key in the multitask execution system which concerns on the 1st Embodiment of this invention. It is a figure which shows an example of the authority data of the multitask execution system which concerns on the 1st Embodiment of this invention. It is a figure which shows an example of the memory content in the task information storage function of the multitask execution system which concerns on the 1st Embodiment of this invention. 5 is a flowchart showing an operation of processing an authority data generation request in the multitask execution system according to the first embodiment of the present invention. It is a flowchart which shows operation | movement of the task authentication function in the multitask execution system which concerns on the 1st Embodiment of this invention. 5 is a flowchart showing an operation for processing a system call in the multitask execution system according to the first embodiment of the present invention. 5 is a flowchart showing an operation for processing a system call in the multitask execution system according to the first embodiment of the present invention. It is a flowchart which shows the operation | movement at the time of producing | generating a daemon task in the multitask execution system which concerns on the 1st Embodiment of this invention. It is a whole block diagram of the multitask execution system which concerns on the example 1 of a change of this invention. It is a flowchart which shows operation | movement of the multitask execution system which concerns on the example 1 of a change of this invention. It is a whole block diagram of the multitask execution system which concerns on the modification 2 of this invention. It is a flowchart which shows operation | movement of the multitask execution system which concerns on the modification 2 of this invention. It is a figure which shows an example of the authority data in the multitask execution system which concerns on the example 2 of a change of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Multitask execution system 101 ... Operating system 102 ... Pseudorandom number generation function 103 ... Unique key generation grant function 104 ... System call processing function 105 ... Authority data confirmation function 106 ... Authority data generation function 107 ... Task information storage function 108 ... Authority Data storage function 109 ... task authentication function 110 ... authentication information inheritance function 201 ... file 202 ... memory area 203 ... socket 204 ... task 205 ... unique key allocation area

Claims (14)

A unique key generation and grant function for generating and assigning a unique key to the operation target object;
When a system call for performing an operation on the operation target object is called by an operation subject task, the authority data of the operation subject task is decrypted using the unique key, and the system call is based on the decrypted authority data. A multi-task execution system comprising: an authority data confirmation function for determining whether or not it can be executed. A task authentication function for performing an authentication process for the operation subject task in response to the authority data generation request from the operation subject task;
The multitask execution system according to claim 1, further comprising an authority data generation function that generates the authority data based on the authentication processing result. A task information storage function for managing whether or not authentication processing for the operation subject task is performed;
The task authentication function is configured to refer to the task information storage function and perform authentication processing for the operation subject task when authentication processing for the operation subject task is not performed. The multitask execution system according to claim 2, wherein:   The task authentication function is configured such that when authentication processing is performed on the operation subject task, authentication processing is not performed on a child task of the operation subject task. The multitask execution system described.   5. The multitask execution according to claim 4, wherein the operation subject task is a login task that performs a login authentication process of a user, and the child task is a login shell task that is executed after the login authentication process. system.   The authority data confirmation function determines whether or not the system call can be executed based on the authority data when it is determined that the system call can be executed based on the first condition. The multitask execution system according to claim 1, wherein the multitask execution system is configured to do so.   When it is determined by the authority data confirmation function that the system call can be executed based on the authority data, it is determined whether the system call can be executed based on a second condition. The multitask execution system according to claim 1, further comprising a system call processing function.   The task information storage function is configured not to manage whether or not an authentication process is performed for a task that operates independently of user control. 4. The multitask execution system according to 3.   The multitask execution system according to claim 1, wherein the unique key generation / giving function is configured to generate a common key used in a common key encryption algorithm as the unique key.   The multitask execution system according to claim 1, wherein the unique key generation / giving function is configured to generate, as the unique key, a pair of a public key and a secret key used in a public key encryption algorithm.   As the authority data, a task ID for identifying the operation subject task, a system call ID for identifying the system call, an operation mode in the system call, and a validity period of the authority data can be set. The multitask execution system according to claim 1. It has a unique key generation / grant function that generates and grants unique keys to the first task and the second task,
The first task is configured to encrypt the authority data for the second task using the unique key, and transmit the encrypted authority data to the second task,
The second task is configured to determine that the first task is a valid task when the authority data transmitted from the first task can be decrypted with the unique key. A multitask execution system characterized by In the operating system, generating and assigning a unique key to the operation target object;
In the operating system, when a system call for performing an operation on the operation target object is called by an operation subject task, the authority data of the operation subject task is decrypted using the unique key, and the decrypted authority data is And a step of determining whether or not the system call can be executed based on the method. In the operating system, generating and assigning a unique key to the first task and the second task;
In the first task, encrypting the authority data for the second task using the unique key, and transmitting the encrypted authority data to the second task;
In the second task, when the authority data transmitted from the first task can be decrypted with the unique key, the step of determining that the first task is a valid task is included. A multitask execution method characterized by the above.

Images