WO2017157202A1 - 执行系统调用的方法及装置 - Google Patents

执行系统调用的方法及装置 Download PDF

Info

Publication number
WO2017157202A1
WO2017157202A1 PCT/CN2017/075853 CN2017075853W WO2017157202A1 WO 2017157202 A1 WO2017157202 A1 WO 2017157202A1 CN 2017075853 W CN2017075853 W CN 2017075853W WO 2017157202 A1 WO2017157202 A1 WO 2017157202A1
Authority
WO
WIPO (PCT)
Prior art keywords
system call
category
access
performer
executor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/075853
Other languages
English (en)
French (fr)
Inventor
裘绍翔
许来光
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017157202A1 publication Critical patent/WO2017157202A1/zh
Priority to US16/132,039 priority Critical patent/US11093647B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • the present application relates to system call technology, and in particular, to a method and apparatus for executing a system call.
  • the present application also relates to another method and apparatus for performing system calls.
  • an operating system such as Linux
  • kernel space and user space each running at different levels, logically isolated from each other.
  • Applications typically do not allow access to kernel data, nor can they use kernel functions. They can only manipulate user data in user space, calling user space functions.
  • system call seyscall
  • a system call When a system call is executed, it is usually trapped in the kernel through a soft interrupt mechanism, that is, it enters the kernel space before the corresponding system service routine can be executed.
  • a system call can be thought of as an interface between the kernel and the user space: the request from the user space is communicated to the kernel, and the kernel sends the request back to the user space after the request has been processed.
  • the operating system usually provides a large number of system calls, these system calls are exposed in the user space, on the one hand, in the entire life cycle of most applications, many system calls are not called, on the other hand, exposed System calls in user space may have various security vulnerabilities. If they are maliciously exploited, they may pose a security risk to the entire system. Therefore, it is necessary to limit the execution of system calls by the application.
  • the Linux system supports a simple Seccomp (secure computing mode) sandbox mechanism that provides a secure mode of operation in which the application process can only call four system calls, namely read, write. , exit and sigreturn, otherwise the application will be terminated.
  • Seccomp sandbox mechanism implements restrictions on system calls, it cannot be differentiated because it treats all controlled processes equally; and since only four system calls of read, write, exit, and sigreturn are opened, It is not scalable and cannot meet the reasonable access requirements of user space for system calls.
  • the embodiment of the present invention provides a method and an apparatus for executing a system call to solve the problem that the prior art cannot implement differentiated control when the system call is restricted, and the number of open system calls cannot meet the access requirement.
  • the embodiment of the present application further provides another method and apparatus for executing a system call.
  • the application provides a method for executing a system call, including:
  • the determining whether the performer of the system call has access rights to the system call includes:
  • the access category of the system call and the access rights of the performer to each category system call are preset.
  • the executor access rights of each category system call and the category of the system call are respectively described by a binary bit string, and the length thereof is respectively consistent with the number of categories of system calls, and the two binary bit strings are respectively Each of the bits corresponds to a system call category of the same sequence number; wherein a value of each bit in the binary bit string describing the access right indicates whether the performer has access to a corresponding class system call, A value describing each bit in a binary bit string of a class to which the system call belongs indicates whether the system call belongs to a corresponding class, and represents a value having access rights to a corresponding class system call, and indicating that the system call belongs to The values of the corresponding categories are consistent;
  • a binary bit string describing the access authority and a binary bit describing a category to which the system call belongs String, bitwise bitwise operation
  • Whether the performer has the access right to the category to which the system call belongs is determined according to the operation result.
  • a 1 in a binary bit string describing the access authority indicates that the performer has an access right to a corresponding category system call, 0 means no; and a binary bit string describing a category to which the system call belongs 1, indicating that the system call belongs to the corresponding category, and 0 means not belonging;
  • Performing the bitwise operation bit by bit includes: performing bitwise AND operation bit by bit;
  • the determining, according to the operation result, whether the performer has the access right to the category to which the system call belongs includes: if the execution result is not all 0, determining that the performer has the access right to the category to which the system call belongs.
  • the setting, by the executor, the access permission of the executor to each type of system call is implemented by: storing, by the executor, an access right of each type of system call and its identity identification information;
  • the obtaining the access authority of the executor to each category system call includes: obtaining the access authority of the performer according to the identity identification information of the performer.
  • the identity information includes: the credential information of the performer.
  • the identity information is obtained by acquiring the identity information from the running context information of the performer.
  • the setting the access rights of the performer to each category system call includes:
  • the executor's access rights to each category of system calls are set according to a preset authorization scheme; or the executor's access rights for each category of system calls are set to the executor's corresponding access rights.
  • the setting the access rights of the performer to each category of system calls further includes:
  • the executor's access rights to various categories of system calls are reduced in a preset manner.
  • the reducing the access rights of the performer to each category of system calls according to a preset manner including:
  • the setting the access rights of the performer to each category of system calls further includes:
  • the executor reduces its access rights to various types of system calls before running the untrusted code during the run.
  • the setting the access rights of the performer to each category of system calls further includes:
  • the setting the access rights of the performer to each category of system calls further includes:
  • the executor increases its access rights to various types of system calls before running the trusted code during the run.
  • the executor's access capability to each category of system call is also set correspondingly; the executor has access
  • a collection of system call categories for permissions is a subset of the set of system call categories for which access is available;
  • the improving the access right to each category system call includes: improving the access authority of the performer within the access capability of the performer to each category system call.
  • the method includes:
  • the step of determining whether the executor of the system call has access to the system call is performed.
  • the related information of the system call includes: a system call name and a parameter value.
  • the performer includes: a basic unit that can be independently operated; the independently operable basic unit includes: a thread or a process.
  • the application also provides an apparatus for executing a system call, including:
  • a request receiving unit configured to receive a request to execute a system call
  • a permission judging unit configured to determine whether an executor of the system call has an access right to the system call
  • An execution permission unit is configured to allow the performer to execute the system call when the output of the access authority determination unit is YES.
  • the permission determining unit includes:
  • a category obtaining subunit configured to acquire a category to which the system call belongs
  • An access permission obtaining subunit configured to obtain the access authority of the performer to each category system call
  • Determining an execution subunit configured to determine, according to the acquired information, whether the performer has an access right to a category to which the system call belongs.
  • the device further includes:
  • a category specifying unit configured to specify a category to which the system call belongs according to a pre-divided system call category before the request receiving unit works
  • the permission setting unit is configured to set the access authority of the performer to each category system call.
  • the determining execution subunit is specifically configured to bitwise perform a bitwise operation on a binary bit string describing the access authority and a binary bit string describing a category to which the system call belongs, and determine, according to the operation result, the bit Whether the executor has access to the category to which the system call belongs.
  • the determining execution subunit is specifically configured to perform a bitwise AND operation bit by bit by using a binary bit string describing the access authority and a binary bit string describing a category to which the system call belongs, and performing an incomplete result.
  • a bitwise AND operation bit by bit by using a binary bit string describing the access authority and a binary bit string describing a category to which the system call belongs, and performing an incomplete result.
  • the privilege setting unit is configured to store, by the executor, an access right of each executor system call and its identity identification information;
  • the access authority obtaining sub-unit is configured to acquire the access authority of the performer according to the identity identification information of the performer.
  • the access permission obtaining sub-unit is configured to obtain the identity identification information from the execution context information of the performer, and obtain the access authority of the performer according to the identity identification information.
  • the permission setting unit includes:
  • a permission inheritance subunit configured to: when the executor is created, set the executor's access rights to each category of system calls according to a preset authorization scheme; or, use the creator to set access rights for each category of system calls. The corresponding access rights of the performer.
  • the permission setting unit further includes:
  • the pre-run permission lowering subunit is configured to reduce the access rights of the performers to each category of system calls according to a preset manner after creating the performer and before running the performer.
  • the pre-run permission reduction subunit includes:
  • a first descending subunit configured to reduce access rights of the performer to each category of system calls according to an identity category of the performer and rights configuration information for the identity category in a system configuration file;
  • a second reduction subunit configured to reduce the access authority of the performer to each category of system calls according to the permission declaration information in the configuration file of the application to which the performer belongs.
  • the permission setting unit further includes:
  • Post-run privilege reduction sub-unit for the executor to run untrusted code during the running process Reduce its access to each category of system calls before.
  • the permission setting unit further includes:
  • the privilege recovery unit is configured to restore the executor's access rights to each category of system calls after the untrusted code is finished running.
  • the permission setting unit further includes:
  • the privilege reduction subunit and the pre-run privilege reduction subunit are respectively configured to respectively set the executor's access capability to each category of system calls;
  • the privilege escalation sub-unit is specifically configured to improve access rights of the executor within the access capability of the executor to each category system call.
  • the device further includes:
  • a virtual call determining unit configured to: after the request receiving unit receives the request for executing the system call, determine, according to the related information of the system call, whether it corresponds to the virtual system call, and trigger the permission judgment when not corresponding Unit work
  • a virtual call authority determining unit configured to determine, when the output of the virtual call determining unit is YES, whether an executor of the system call has an access right to the virtual system call, and when yes, allow the execution The virtual system call is executed.
  • the application also provides a method for executing a system call, including:
  • the performer is allowed to perform the target call.
  • the determining, according to the related information of the system call, the target call to be executed including:
  • the virtual system call is invoked as the target, otherwise the system call is invoked as the target.
  • the related information of the system call includes: a system call name and a parameter value.
  • the determining whether the executor of the system call has access rights to the target call includes:
  • the access category of the target call and the access rights of the performer to each category system call are preset.
  • the application also provides an apparatus for executing a system call, including:
  • a request receiving unit configured to receive a request to execute a system call
  • a target call determining unit configured to determine, according to the related information of the system call, a target call to be executed
  • An access authority determining unit configured to determine whether an executor of the system call has an access right to invoke the target
  • An execution permission unit is configured to allow the performer to perform the target call when the output of the access authority determination unit is YES.
  • the target call determining unit is specifically configured to: when the system call corresponds to a preset virtual system call, invoke the virtual system call as the target, otherwise use the system call as the Target call.
  • the access authority determining unit includes:
  • the target calling category acquisition subunit is configured to acquire a category to which the target call belongs
  • An access permission obtaining subunit configured to obtain the access authority of the performer to each category system call
  • the target call determining execution subunit is configured to determine, according to the acquired information, whether the performer has an access right to a category to which the target call belongs.
  • the device further includes:
  • a target calling category specifying unit configured to specify a category to which the target call belongs according to a pre-divided system call category before the request receiving unit works;
  • the permission setting unit is configured to set the access authority of the performer to each category system call.
  • the method of executing the system call of the present application after receiving the request for executing the system call, determining the system call Whether the executor has access to the system call and, when present, allows the executor to execute the system call.
  • the above method provided by the present application when determining whether a system call can be executed, is based on whether the executor has the corresponding access authority, that is, the purpose of restricting the system call is achieved by authorizing the executor. Differentiated control based on the identity of the performer, and does not limit which system calls are open, so it can flexibly meet the reasonable access requirements of the user space for system calls.
  • FIG. 1 is a flow diagram of an embodiment of a method of performing a system call of the present application
  • FIG. 2 is a flowchart of a process for determining whether an executor has an access right to a system call according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of an embodiment of an apparatus for performing a system call of the present application
  • FIG. 4 is a flow chart of another embodiment of a method of performing a system call of the present application.
  • FIG. 5 is a schematic diagram of another embodiment of an apparatus for performing system calls of the present application.
  • the method for executing a system call provides a sandbox mechanism for performing permission control on a system call, and the core thereof is: when determining whether a system call can be executed for a received system call request, Whether the executor has the corresponding access authority as the basis, that is, only the authorized executor can execute the system call, thereby achieving the purpose of limiting the execution of the system call, and implementing the differentiated control based on the executor identity.
  • there is no restriction on which system calls are opened so it is flexible to meet the reasonable access requirements of user space for system calls.
  • the function of the application can be implemented by a process.
  • the function of the application can also be implemented by multiple threads concurrently, and the process or thread can be executed as needed during the running process.
  • the executor described in this embodiment generally refers to a basic unit that can be independently operated, and is an independent instruction stream that can be scheduled to be run by an operating system.
  • It can be a process or a thread.
  • the implementation of the technical solution in the Linux system will be taken as an example.
  • the thread Since the process and the thread are unified in Linux, and there is no thread and process, the thread is generally considered to be a shared data space.
  • the lightweight process therefore, in the description of the following embodiments, without a clear distinction, mainly using the way of representation of threads.
  • the method for executing the system call provided by the present application may be implemented at a unified entrance of the kernel, that is, by an independent service provider in the kernel, and the request for executing the system call initiated by the user space may be submitted to the office first.
  • the service provider determines whether the performer is allowed to execute the system call, and if so, can distribute the system call request to the corresponding system call service routine, or directly trigger the corresponding system call service routine To achieve the corresponding system call function.
  • the method for executing a system call provided by the application includes the steps of: receiving a request to execute a system call; determining whether an executor of the system call has an access right to the system call; if yes, allowing the performer to execute The system call.
  • the executor's access rights to the system call can be set in advance, that is, the authorization is performed in advance, the access rights of the executor to which system calls are explicitly set, and the names or index numbers of these system calls are added to the In the authorization set of the executor; after receiving the system call request initiated by the executor, the executor may determine whether the executor has the access right to the system call according to the preset access authority, that is: Determining whether the executor's authorization set contains the name or index number of the requested system call, and if so, indicating that the executor has access to the system call, allowing the system call to be executed.
  • system calls can be classified in advance, and system calls are divided into preset number of categories.
  • the access authority is set for the executor by using the category as the basic unit, thereby reducing the workload of the authorization process and improving the execution efficiency of the technical solution.
  • Preferred embodiments based on classification will be highlighted in the examples provided below. The embodiments of the present application are described in detail below.
  • FIG. 1 is a flowchart of an embodiment of a method for executing a system call according to the present application.
  • the category of the system to be executed in this embodiment may be specified according to the pre-defined system call category, and the access rights of the executor to various system calls may be set.
  • the system calls provided by the kernel may be pre-divided into a preset number of categories.
  • the specific implementation may be classified according to different standards.
  • the functions may be classified according to the implemented functions: categories related to network operations, categories related to file operations, Categories related to permission settings, etc.
  • the preset number can be set as needed, for
  • the preset number N of 32-bit systems can be 32, and for a 64-bit system N can be 64.
  • the classified categories can be identified by 1 to N respectively. For example, 1 can be used to identify categories related to network operations, and 2 can be used to identify categories related to file operations.
  • each system call can be assigned its own category (in the process, naturally, the category of the system call to be executed in this embodiment is specified), usually each system call belongs to only one category.
  • the specified system call read() belongs to category 2, which is a category related to file operations.
  • each system call usually has an index number corresponding thereto, so after specifying a category for each system call, the name or index number of the system call may be stored corresponding to the identifier of the category to which it belongs.
  • the present embodiment provides a preferred embodiment for describing a category to which a system call belongs by using a binary bit string.
  • the length of the binary bit string used to describe the category to which the system call belongs is consistent with the number N of system calls, each bit corresponding to the system call class of the same sequence number, that is, the first bit corresponds to category 1.
  • the second bit corresponds to category 2, ..., the Nth bit corresponds to category N, and the value of each bit represents the relationship between the system call and the corresponding category: 1 indicates that it belongs to Category, 0 means not belonging.
  • a 32-bit binary bit string describing the category to which a system call belongs is: 0100000...0, which means that the system call belongs to category 2.
  • each system call that can be accessed by the user space can be described in the above manner. If there are a total of S system calls (the index number ranges from 0 to S-1), it corresponds to S. Binary bit string.
  • the S binary bit strings describing the classification of these system calls may be uniformly managed by using a two-dimensional bit array, which is recorded as category[N][S], where category[0][m] ⁇ category[ N-1][m] stores a binary bit string of length N, which corresponds to the class of the system call with index number m.
  • the category[N][S] can be preset, or the configuration information can be provided in the system configuration file on the basis of the configuration, and the configuration information in the configuration file is read at the system startup to adjust accordingly.
  • the configuration information can be in the form of "syscall.classify type name", where syscall.classify is the keyword, name is the syscall name, and type is the category identifier (1 to N), which can be read when the system starts.
  • the configuration information is converted into a corresponding binary bit string and the value of the corresponding bit in category[N][S] is updated. In this way, the classification of the system call can be adjusted based on the policy rules, which is flexible.
  • This embodiment provides a preferred embodiment based on classification, with which the executor can be authorized in the kernel in units of categories, the executor is set to each category system call at least one stage of the executor life cycle Access rights, the life cycle includes the following phases: the creation phase, the pre-run phase after creation, The operation phase, etc., that is, the executor's access rights to various types of system calls can be adjusted in different stages according to a preset manner, thereby realizing dynamic adjustment of the executor's access rights, and providing more flexible security for executing system calls.
  • the executor refers to a thread, that is, a thread is set to access rights for each category system call.
  • the permission setting process before running the thread is a process of gradually reducing the permissions to limit the access of the thread to the system call to a safe scope.
  • the credibility of the running code can be determined. , improve, reduce or restore access rights.
  • the embodiment in order to prevent the thread from excessively improving its own authority, the embodiment also introduces the concept of access capability and implements restrictions on adjusting access rights by setting its access capability before the thread runs.
  • the access capability indicates the range of capabilities that the thread has access to the system call.
  • the access rights of the thread to each category of system calls (hereinafter referred to as access rights), and the access capabilities to each type of system call (hereinafter referred to as accessibility) may be separately described by a set, and the access permission set includes a thread having The category ID of the access permission, in the range of 1 to N.
  • the access capability set contains the category ID of the access capability of the thread, ranging from 1 to N.
  • the access permission collection is a subset of the access capability set.
  • a set can be one of the following listed sets: ⁇ 1, 2, 3 ⁇ , ⁇ 1, 2 ⁇ , ⁇ 1, 3 ⁇ , ⁇ 2, 3 ⁇ , ⁇ 1 ⁇ , ⁇ 2 ⁇ , ⁇ 3 ⁇ .
  • the access rights of the thread and the access capability may also be described using a binary bit string.
  • the length of the binary bit string is consistent with the number of categories of system calls, and each bit corresponds to a system call category of the same sequence number, that is, the first bit corresponds to category 1, and the second bit corresponds to Category 2 corresponds, ..., the Nth bit corresponds to category N, and the value of each bit represents whether the thread has access to the corresponding category system call: 1, indicating that the thread has a pair
  • the access permission of the corresponding category system call, 0 means not.
  • the present embodiment will describe a binary bit string of a thread access authority for each class system call as an access right bit string, and a binary bit string describing a thread access capability for each class system call is simply referred to as an access capability bit string. .
  • the access authority of the thread is generally stored corresponding to the identifier information of the thread, where the identifier information may be a credential of the thread, or other information that may identify the identity of the thread.
  • the access authority of the thread is generally stored corresponding to the identifier information of the thread, where the identifier information may be a credential of the thread, or other information that may identify the identity of the thread.
  • to set the access capability of the thread it is also possible to store the access capability and the identity information of the thread.
  • the following is an example of setting access rights for threads in a 32-bit Linux system. From the creation of threads, before running after thread creation, and during the three phases of thread running, the setting of access rights is further described in detail. In the first two stages, the access capability of the thread can also be set.
  • the executor's access rights can be used to set the corresponding access rights of the performer.
  • the Init process When the init process of the Linux system starts, its access rights (permissoin) bit string and access capability (bitability) bit string are initialized to 0xfffffff, that is, all bits are 1 and thus have access rights and access to all class system calls. Capability; subsequently, the Init process runs the specific process responsible for creating the application process, such as the seed process; after the seed process is initialized, it reduces its access rights and access capabilities, such as: removing access and access to some of the default system call categories. To achieve the minimum permissions of the seed process. In a specific implementation, the access bit string of the seed process and the corresponding bit in the access capability bit string may be cleared to 0, and then the access bit and access capability of the seed process are set by the updated bit string.
  • the access authority and access capability of the thread to each category of system call may also be set according to a preset authorization scheme, that is, access by the thread.
  • the permissions and access capabilities are set to the values specified in the default authorization scheme.
  • the decentralization operation can be further performed in a preset manner to limit the access rights and access capabilities of threadA to system calls to a safe range.
  • the further performing the rights reduction operation includes: reducing the rights according to the system configuration file, and/or reducing the rights according to the configuration file of the application, which are respectively described below.
  • the system configuration file can display the permission configuration information for various identity categories.
  • the configuration format can be: setcap user capability, where user corresponds to various identity categories, such as: common application, system application, special For applications, etc., capability is the scope of access to each category of system calls.
  • the identity category information of the thread A can be generated according to the preset characteristics of the application A, such as the signature information or the application name, the path, and the like, according to the preset identity conversion rule, and then according to the system configuration file.
  • a rights reduction operation is performed for the rights configuration information of the identity class.
  • threadA After threadA is created, it has the access rights and access capabilities of the system call category related to the uid/gid setting. However, if the specified capability is not included in the system configuration file, the access point string of threadA can be In the access capability bit string, the bit corresponding to the class is cleared to 0, and then the access bit and access capability of the threadA are set with the updated bit string.
  • application A can declare the required function rights in its configuration file, for example, the function permission to send and receive text messages, the function permission to access the address book, etc., so before running threadA, you can select according to the function rights declared by the application.
  • Implement the system call of the corresponding function and determine the system call category corresponding to these system calls, that is, determine the system call category involved in the function authority declared by the application A, and then perform the corresponding power reduction operation, from the access point bit string of threadA In the access capability bit string, the bit corresponding to the unrecognized system call class is cleared to 0, and then the access bit and access capability of the threadA are set with the updated bit string.
  • threadA is the main thread of application A. When it leaves the Seed, it can also create other function sub-threads according to its functional requirements. On the one hand, the sub-threads created by it can inherit the access rights and access capabilities of threadA. On the one hand, before running the child thread, it can also reduce the access rights and access capabilities of the child thread, for example: delete the access rights and access capabilities of the system call category related to the thread creation.
  • the access bit string of the sub-thread and the corresponding bit in the access capability bit string may be cleared to 0, and then the access bit and access capability of the sub-thread are set with the updated bit string.
  • the thread mentioned here includes the main thread threadA of the application A, and also includes the sub-threads created by the thread A. These threads can adjust their respective access rights according to the needs during the running process.
  • the threadA is taken as an example for description.
  • the corresponding application code will be run.
  • untrusted code such as code provided by a third party, or call an interface in a library provided by a third party.
  • the security is usually not validated, so threadA can reduce the access rights before loading the untrusted code, but retain the access capability, that is, the system call category corresponding to the untrusted code execution in the access permission bit string.
  • the bit is cleared to 0, and the access capability bit string is not modified, and then the access permission of threadA is set with the updated access permission bit string.
  • threadA can restore its access to each category of system calls. ThreadA can restore its access rights to the access rights before loading the above untrusted code. If the access rights before the decentralization is not recorded before the access rights are reduced, the accessibility of threadA can be obtained after the untrusted code is run. As the upper limit, the access rights are restored, but the accessibility limit cannot be exceeded.
  • threadA can improve access rights itself during the running process before loading and running trusted code. For example, in order to ensure that the trusted code implements its function, the access authority of threadA can be improved according to the requirements of the trusted code, that is, the system call category with access rights can be increased to ensure that the trusted code realizes its function.
  • the access authority of threadA can be improved according to the requirements of the trusted code, that is, the system call category with access rights can be increased to ensure that the trusted code realizes its function.
  • threadA improves its access rights, it also needs to use its accessibility as the upper limit and enhance the privilege within the limits of access capabilities.
  • the thread can be provided with a setcap () permission setting interface.
  • the access permission information to be set for example, the access permission bit string
  • setcap() An interface by which the set function is implemented in the kernel. If the access capability needs to be set, the access capability information (for example, the access capability bit string) can also be passed as an entry parameter, and the corresponding setting function is implemented in the kernel by the setcap() function.
  • the manner of setting thread access rights at each stage given above may not be all adopted in the specific implementation, but may be correspondingly selected and combined according to requirements, for example, the thread may be set only at the time of creation. Access rights, or setting permissions at creation time, and adjusting permissions during thread running are all possible.
  • Steps 101-104 of the example determine whether the system call can be executed according to the access right of the thread, thereby implementing access restrictions on the system call. Each step will be described one by one below.
  • Step 101 Receive a request to execute a system call.
  • a thread After a thread executes a system call, it usually falls into the kernel.
  • the handler that implements the method at the kernel entry receives a request to execute the system call, and the request usually carries the to-be-executed system call. Index number or name, and related parameters for executing system calls.
  • Step 102 Determine whether the executor of the system call has access rights to the system call, and if yes, perform step 103; otherwise, perform step 104.
  • steps 102-1 to 102-3 may be included, which will be further described below in conjunction with FIG. 2.
  • Step 102-1 Acquire a category to which the system call belongs.
  • each system call has been specified in advance for the system call category to which it belongs, which naturally includes the system call to be executed received in step 101, and may be based on the name or index number of the system call to be executed. Get the system call category to which it belongs, for example, get the ID of the system call category to which it belongs.
  • the binary bit string is adopted when the system call category is specified in advance, and the two-dimensional bit array category[N][S] is used to store and manage the classification of the system call, then this step can be performed by the system to be executed.
  • the index number scno is called to query the array category[N][S], so as to obtain the category information category[N][scno] to which the system call to be executed belongs, and the N bits are combined to obtain the binary bits of the category to which the system call belongs.
  • String referred to as the category bit string. If the request received in step 101 carries the system call name, the name may be converted into an index number by a table lookup operation or the like.
  • Step 102-2 Acquire access rights of the performer to each category system call.
  • the executor is a thread, so this step can obtain the access rights that have been set for the thread, and can usually obtain the access rights according to the identity information of the thread.
  • the thread's credential information can be obtained through the thread context of the kernel, and its access rights can be obtained according to the credential, for example: access permission set.
  • this step acquires the access permission bit string of the thread.
  • Step 102-3 Determine, according to the obtained information, whether the performer has the access right to the category to which the system call belongs. If yes, execute step 103. Otherwise, perform step 104.
  • This step determines whether the thread can execute the system call according to the category of the system call to be executed acquired in step 102-1 and the access authority of the thread acquired in step 102-2.
  • step 102-1 is to obtain the identifier of the system call category to which the system call belongs, and the step 102-2 obtains the access permission set, that is, the set includes the category identifier of the thread having the access right, then this step may determine the Whether the collection includes the category identifier obtained in step 102-1, and if it is included, the thread has corresponding access authority.
  • this step may adopt a preferred implementation of bitwise AND: access permission bit string permission and category
  • the bit string category[N][scno] performs bitwise AND operation, ie, permission&category[N][scno].
  • 1 in the access permission bit string indicates that the thread has access rights to the corresponding class system call
  • 0 means no
  • 1 in the class bit string indicates that the system call belongs to
  • 0 means no
  • the bitwise and operation are used to judge.
  • the access permission bit string and the value of the bit in the class bit string may also be set in different manners, as long as the value indicating the access right to the corresponding class system call is indicated, and the system call is indicated.
  • the values belonging to the corresponding categories can be consistent, and the corresponding technical operation and judgment method can also implement the technical solution in the same step, and the high execution efficiency can also be achieved.
  • the permission bit string 0 can be used to indicate that the thread has access rights to the corresponding category system call, and 1 means no; correspondingly, for the category bit string, 0 can be used to indicate that the system call belongs to the corresponding category, and 1 means not belong to .
  • This step performs a bitwise OR operation on the access permission bit string permission and the category bit string category[N][scno], and determines that the performer has access to the category to which the system call belongs when the execution result is not all one. .
  • Step 103 Allow the performer to execute the system call.
  • the thread has access to the system call to be executed, and thus the thread can be allowed to execute the system call.
  • the access request may be distributed to a processing program corresponding to the system call (also called a system call service routine), or the corresponding system call service routine may be directly triggered to implement a corresponding system calling function.
  • Step 104 Reject the performer to execute the system call.
  • Execution to this step indicates that the thread does not have access to the system call to be executed, and therefore refuses to execute the system call.
  • a similar response such as "system call failure" or "no call permission" may be returned to the thread.
  • the method provided in this embodiment is proposed for system calls, it is not only suitable. Used for system calls, it can also be used for custom interface functions that need to be caught in the kernel. In order to distinguish from the former, the former can be called a native system call, and the custom interface function is called a virtual system call.
  • a virtual system call needs to be performed, a preset value may be used as an entry parameter value, and then a preset native system call is invoked, for example, the setcap() mentioned in this embodiment is used as a preset virtual system call.
  • the preset value 100 is used as the value of the entry parameter param1 and a native system call syscallA is invoked
  • the corresponding virtual system call setcap() is used, that is, the setcap is actually executed after being trapped in the kernel. ()transfer.
  • the method may first determine, according to the related information of the system call, whether it corresponds to a preset virtual system call, and if yes, determine whether the performer of the system call has the The access authority of the virtual system call, and the executor is allowed to execute the virtual system call when there is; if not, the process is performed according to step 102 in the above embodiment.
  • the related information of the system call includes: a system call name and a parameter value, and still adopts the example given before. If the system call name is syscallA and the parameter value is 100, it can be determined that it corresponds to a preset virtual system call. Setcap().
  • the category of each system call may be specified according to the pre-divided system call category, and the category to which the virtual system call belongs may also be specified, and the performer is also set. Threads in the embodiment, access rights to system calls of each category.
  • the system call can be executed as needed.
  • the system call is determined.
  • the bit-based bitwise and operation mode may be adopted, that is, the class bit string of setcap() and the access bit string of the performer are performed in a bitwise manner. Operation, if the result is not all zero, the executor has access to the category to which setcap() belongs, so setcap() can be executed, otherwise it cannot be executed.
  • the application of the sandbox mechanism provided by the embodiment can be extended by using the foregoing implementation manner that supports the virtual system call.
  • the method for executing a system call determines whether a system call can be executed based on whether the executor has the corresponding access authority, that is, by authorizing the executor. Restricting the purpose of system calls, thus implementing differentiated control based on the identity of the performer, and does not limit which system calls are open, so it can flexibly meet the reasonable access requirements of user space for system calls.
  • FIG. 3 is a schematic diagram of an apparatus embodiment for performing a system call according to the present application. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described below are merely illustrative.
  • An apparatus for executing a system call includes: a request receiving unit 301, configured to receive a request for executing a system call; and a permission determining unit 302, configured to determine whether an executor of the system call has a call to the system
  • the access permission unit 303 is configured to allow the performer to execute the system call when the output of the access authority determining unit is YES; and execute the rejecting unit 304 for when the access authority determining unit When the output is no, the performer is denied execution of the system call.
  • the permission determining unit includes:
  • a category obtaining subunit configured to acquire a category to which the system call belongs
  • An access permission obtaining subunit configured to obtain the access authority of the performer to each category system call
  • Determining an execution subunit configured to determine, according to the acquired information, whether the performer has an access right to a category to which the system call belongs.
  • the device further includes:
  • a category specifying unit configured to specify a category to which the system call belongs according to a pre-divided system call category before the request receiving unit works
  • the permission setting unit is configured to set the access authority of the performer to each category system call.
  • the determining execution subunit is specifically configured to bitwise perform a bitwise operation on a binary bit string describing the access authority and a binary bit string describing a category to which the system call belongs, and determine, according to the operation result, the bit Whether the executor has access to the category to which the system call belongs.
  • the determining execution subunit is specifically configured to describe a binary bit string and description of the access authority
  • the binary bit string of the category to which the system call belongs is performed, and the bitwise AND operation is performed bit by bit, and when the execution result is not all 0, it is determined that the performer has the access right to the category to which the system call belongs.
  • the privilege setting unit is configured to store, by the executor, an access right of each executor system call and its identity identification information;
  • the access authority obtaining sub-unit is configured to acquire the access authority of the performer according to the identity identification information of the performer.
  • the access permission obtaining sub-unit is configured to obtain the identity identification information from the execution context information of the performer, and obtain the access authority of the performer according to the identity identification information.
  • the permission setting unit includes:
  • a permission inheritance subunit configured to: when the executor is created, set the executor's access rights to each category of system calls according to a preset authorization scheme; or, use the creator to set access rights for each category of system calls. The corresponding access rights of the performer.
  • the permission setting unit further includes:
  • the pre-run permission lowering subunit is configured to reduce the access rights of the performers to each category of system calls according to a preset manner after creating the performer and before running the performer.
  • the pre-run permission reduction subunit includes:
  • a first descending subunit configured to reduce access rights of the performer to each category of system calls according to an identity category of the performer and rights configuration information for the identity category in a system configuration file;
  • a second reduction subunit configured to reduce the access authority of the performer to each category of system calls according to the permission declaration information in the configuration file of the application to which the performer belongs.
  • the permission setting unit further includes:
  • the post-run privilege reduction sub-unit is used by the executor to reduce its access rights to various types of system calls before running the untrusted code during the running process.
  • the permission setting unit further includes:
  • the privilege recovery unit is configured to restore the executor's access rights to each category of system calls after the untrusted code is finished running.
  • the permission setting unit further includes:
  • the privilege reduction subunit and the pre-run privilege reduction subunit are also respectively configured for corresponding The executor's access capability to each category of system calls;
  • the privilege escalation sub-unit is specifically configured to improve access rights of the executor within the access capability of the executor to each category system call.
  • the device further includes:
  • a virtual call determining unit configured to: after the request receiving unit receives the request for executing the system call, determine, according to the related information of the system call, whether it corresponds to the virtual system call, and trigger the permission judgment when not corresponding Unit work
  • a virtual call authority determining unit configured to determine, when the output of the virtual call determining unit is YES, whether an executor of the system call has an access right to the virtual system call, and when yes, allow the execution The virtual system call is executed.
  • FIG. 4 is a flowchart of another embodiment of a method for executing a system call provided by the present application.
  • the parts of the present embodiment that are identical to the steps of the foregoing method embodiment are not described again. The differences are mainly described below.
  • Another method for performing system calls provided by the present application includes:
  • Step 401 Receive a request to execute a system call.
  • each system call and the category of the preset virtual system call may be specified according to the pre-divided system call category, and the performer's access rights to each category system call may be set.
  • Step 402 Determine, according to the related information of the system call, a target call to be executed.
  • the related information of the system call includes: a system call name and a parameter value.
  • the system call name and the parameter value it is determined whether the system call corresponds to a preset virtual system call, and if so, the virtual system call is invoked as the target, otherwise the system call is used as the target. transfer.
  • Step 403 Determine whether the executor of the system call has access rights to the target call, and if yes, perform step 404; otherwise, perform step 405.
  • each system call and the preset virtual system call have been assigned a category, which naturally includes the target call, so this step can obtain the system call category to which the target call belongs, and can Obtaining the access authority of the executor to each category of system call, and then determining, according to the obtained information, whether the executor has the access right to the category to which the target call belongs, and if yes, executing step 404.
  • Step 404 Allow the performer to perform the target call.
  • Step 405 Reject the performer to perform the target call.
  • FIG. 5 is a schematic diagram of another embodiment of an apparatus for performing system calls. Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described below are merely illustrative.
  • An apparatus for executing a system call includes: a request receiving unit 501, configured to receive a request for executing a system call; and a target call determining unit 502, configured to determine a target to be executed according to related information of the system call Calling; an access authority determining unit 503, configured to determine whether an executor of the system call has an access right to invoke the target; and an execution permission unit 504, configured to allow when the output of the access authority determining unit is YES
  • the executor executes the target call; the execution refusal unit 505 is configured to reject the executor to perform the target call when the output of the access authority determining unit is negative.
  • the target call determining unit is specifically configured to: when the system call corresponds to a preset virtual system call, invoke the virtual system call as the target, otherwise use the system call as the Target call.
  • the access authority determining unit includes:
  • the target calling category acquisition subunit is configured to acquire a category to which the target call belongs
  • An access permission obtaining subunit configured to obtain the access authority of the performer to each category system call
  • the target call determining execution subunit is configured to determine, according to the acquired information, whether the performer has an access right to a category to which the target call belongs.
  • the device further includes:
  • a target calling category specifying unit configured to specify a category to which the target call belongs according to a pre-divided system call category before the request receiving unit works;
  • the permission setting unit is configured to set the access authority of the performer to each category system call.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is computer readable A qualitative example.
  • Computer readable media including both permanent and non-persistent, removable and non-removable media may be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-transitory computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种执行系统调用的方法及装置，以及另一种执行系统调用的方法及装置。第一种执行系统调用的方法包括：接收执行系统调用的请求（101）；判断所述系统调用的执行者是否具有对所述系统调用的访问权限（102）；若具有，则允许所述执行者执行所述系统调用（103）。上述方法，在判断某一系统调用能否被执行时，是以执行者是否具有相应的访问权限作为依据，即通过对执行者的授权达到限制系统调用的目的，从而实现了基于执行者身份的差异化控制，而且并没有对开放哪些系统调用加以限制，因此可以灵活地满足用户空间对系统调用的合理访问需求。

Description

执行系统调用的方法及装置
本申请要求2016年03月18日递交的申请号为201610159286.7、发明名称为“执行系统调用的方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及系统调用技术，具体涉及一种执行系统调用的方法及装置。本申请同时涉及另一种执行系统调用的方法及装置。
背景技术
为了保证安全性，操作系统(例如Linux)的运行空间通常可以被划分为内核空间与用户空间，它们各自运行在不同的级别中，逻辑上相互隔离。应用程序在通常情况下不允许访问内核数据，也无法使用内核函数，它们只能在用户空间操作用户数据，调用用户空间函数。当用户程序需要获得系统服务或者访问系统核心功能时，这时就需要执行系统调用(syscall)。
执行系统调用时通常通过软中断机制陷入内核，即进入内核空间，然后才能执行相应的系统服务例程。从逻辑上来说，系统调用可被看成是内核与用户空间交互的接口：把来自用户空间的请求传达给内核，待内核把请求处理完毕后再将处理结果送回给用户空间。
在具体应用中，操作系统通常提供大量的系统调用，这些系统调用都暴露在用户空间，一方面在大多数应用程序的整个生命周期内，很多系统调用并没有被调用，另一方面，暴露在用户空间的系统调用有可能存在各种安全漏洞，如果被恶意利用，则可能为整个系统带来安全隐患，因此有必要对应用程序执行系统调用加以限制。例如，Linux系统支持一种简洁的Seccomp(secure computing—安全计算模式)沙箱机制，提供了一种安全运行模式，在该模式下的应用程序进程只能调用4种系统调用，即read、write、exit和sigreturn，否则应用程序便会被终止。
Seccomp沙箱机制虽然实现了对系统调用的限制，但是由于其对所有被控制进程是一视同仁的，不能做到差异化控制；而且由于仅开放了read、write、exit、sigreturn这4个系统调用，不具有可扩展性，无法满足用户空间对系统调用的合理访问需求。
发明内容
本申请实施例提供一种执行系统调用的方法及装置，以解决现有技术在对系统调用进行限制时无法实现差异化控制、以及开放的系统调用数量无法满足访问需求的问题。本申请实施例还提供另一种执行系统调用的方法及装置。
本申请提供一种执行系统调用的方法，包括：
接收执行系统调用的请求；
判断所述系统调用的执行者是否具有对所述系统调用的访问权限；
若具有，则允许所述执行者执行所述系统调用。
可选的，所述判断所述系统调用的执行者是否具有对所述系统调用的访问权限，包括：
获取所述系统调用所属类别；
获取所述执行者对各类别系统调用的访问权限；
根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限；
其中，所述系统调用所属类别、以及所述执行者对各类别系统调用的访问权限是预先设定的。
可选的，在所述接收执行系统调用的请求之前，执行下述操作：
根据预先划分的系统调用类别，指定所述系统调用所属类别；
设置所述执行者对各类别系统调用的访问权限。
可选的，所述执行者对各类别系统调用的访问权限、以及所述系统调用所属类别分别采用二进制比特串描述，其长度分别与系统调用的类别数一致，所述两个二进制比特串中各比特位分别与相同序号的系统调用类别相对应；其中，描述所述访问权限的二进制比特串中的每个比特位的值表示所述执行者是否具有对相应类别系统调用的访问权限，描述所述系统调用所属类别的二进制比特串中的每个比特位的值表示所述系统调用是否属于相应类别，并且表示具有对相应类别系统调用的访问权限的值、与表示所述系统调用属于相应类别的值一致；
所述根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限，包括：
将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特 串，逐位进行位运算；
根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限。
可选的，描述所述访问权限的二进制比特串中的1，表示所述执行者具有对相应类别系统调用的访问权限，0表示不具有；描述所述系统调用所属类别的二进制比特串中的1，表示所述系统调用属于相应类别，0表示不属于；
所述逐位进行位运算，包括：逐位执行按位与操作；
所述根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限，包括：若执行结果不全为0，则判定所述执行者具有对所述系统调用所属类别的访问权限。
可选的，所述设置所述执行者对各类别系统调用的访问权限，采用如下方式实现：将所述执行者对各类别系统调用的访问权限与其身份标识信息对应存储；
所述获取所述执行者对各类别系统调用的访问权限，包括：根据所述执行者的身份标识信息获取所述执行者的所述访问权限。
可选的，所述身份标识信息包括：所述执行者的信任状信息。
可选的，采用如下方式获取所述身份标识信息：从所述执行者的运行上下文信息中获取其身份标识信息。
可选的，所述设置所述执行者对各类别系统调用的访问权限，包括：
在创建所述执行者时，按照预设授权方案设置所述执行者对各类别系统调用的访问权限；或者，用创建者对各类别系统调用的访问权限设置所述执行者的相应访问权限。
可选的，所述设置所述执行者对各类别系统调用的访问权限，还包括：
在创建所述执行者之后、在运行所述执行者之前，按照预设方式降低所述执行者对各类别系统调用的访问权限。
可选的，所述按照预设方式降低所述执行者对各类别系统调用的访问权限，包括：
根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限；和/或，
根据所述执行者所属应用程序的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
可选的，所述设置所述执行者对各类别系统调用的访问权限，还包括：
所述执行者在运行过程中，在加载运行不可信代码之前降低其对各类别系统调用的访问权限。
可选的，所述设置所述执行者对各类别系统调用的访问权限，还包括：
在所述不可信代码运行完毕后，恢复所述执行者对各类别系统调用的访问权限。
可选的，所述设置所述执行者对各类别系统调用的访问权限，还包括：
所述执行者在运行过程中，在加载运行可信代码之前提高其对各类别系统调用的访问权限。
可选的，在所述执行者运行之前，在设置所述执行者对各类别系统调用的访问权限时，还相应设置所述执行者对各类别系统调用的访问能力；所述执行者具有访问权限的系统调用类别集合是其具有访问能力的系统调用类别集合的子集；
所述提高其对各类别系统调用的访问权限，包括：在所述执行者对各类别系统调用的访问能力之内，提高所述执行者的访问权限。
可选的，在所述接收执行系统调用的请求之后，包括：
根据所述系统调用的相关信息，确定其是否对应于预设的虚拟系统调用；
若是，则判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时，允许所述执行者执行所述虚拟系统调用；
若否，则执行所述判断所述系统调用的执行者是否具有对所述系统调用的访问权限的步骤。
可选的，所述系统调用的相关信息，包括：系统调用名称及参数值。
可选的，所述执行者包括：可独立运行的基本单元；所述可独立运行的基本单元包括：线程或者进程。
相应的，本申请还提供一种执行系统调用的装置，包括：
请求接收单元，用于接收执行系统调用的请求；
权限判断单元，用于判断所述系统调用的执行者是否具有对所述系统调用的访问权限；
执行允许单元，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述系统调用。
可选的，所述权限判断单元，包括：
类别获取子单元，用于获取所述系统调用所属类别；
访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限。
可选的，所述装置还包括：
类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述系统调用所属类别；
权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
可选的，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位进行位运算，并根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限。
可选的，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位执行按位与操作，并当执行结果不全为0时判定所述执行者具有对所述系统调用所属类别的访问权限。
可选的，所述权限设置单元，具体用于将所述执行者对各类别系统调用的访问权限与其身份标识信息对应存储；
所述访问权限获取子单元，具体用于根据所述执行者的身份标识信息获取所述执行者的所述访问权限。
可选的，所述访问权限获取子单元，具体用于从所述执行者的运行上下文信息中获取其身份标识信息，并根据所述身份标识信息获取所述执行者的所述访问权限。
可选的，所述权限设置单元包括：
权限继承子单元，用于在创建所述执行者时，按照预设授权方案设置所述执行者对各类别系统调用的访问权限；或者，用创建者对各类别系统调用的访问权限设置所述执行者的相应访问权限。
可选的，所述权限设置单元还包括：
运行前权限降低子单元，用于在创建所述执行者之后、在运行所述执行者之前，按照预设方式降低所述执行者对各类别系统调用的访问权限。
可选的，所述运行前权限降低子单元包括：
第一降低子单元，用于根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限；和/或，
第二降低子单元，用于根据所述执行者所属应用程序的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
运行后权限降低子单元，用于所述执行者在运行过程中，在加载运行不可信代码之 前降低其对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
权限恢复单元，用于在所述不可信代码运行完毕后，恢复所述执行者对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
权限提高子单元，用于所述执行者在运行过程中，在加载运行可信代码之前提高其对各类别系统调用的访问权限。
可选的，所述权限降低子单元和所述运行前权限降低子单元，还分别用于相应设置所述执行者对各类别系统调用的访问能力；
所述权限提高子单元，具体用于在所述执行者对各类别系统调用的访问能力之内，提高所述执行者的访问权限。
可选的，所述装置还包括：
虚拟调用确定单元，用于在所述请求接收单元接收执行系统调用的请求后，根据所述系统调用的相关信息，确定其是否对应于虚拟系统调用，并在不对应时，触发所述权限判断单元工作；
虚拟调用权限判断单元，用于当所述虚拟调用确定单元的输出为是时，判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时，允许所述执行者执行所述虚拟系统调用。
此外，本申请还提供一种执行系统调用的方法，包括：
接收执行系统调用的请求；
根据所述系统调用的相关信息，确定待执行的目标调用；
判断所述系统调用的执行者是否具有对所述目标调用的访问权限；
若具有，则允许所述执行者执行所述目标调用。
可选的，所述根据所述系统调用的相关信息，确定待执行的目标调用，包括：
当所述系统调用对应于预设的虚拟系统调用时，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
可选的，所述系统调用的相关信息包括：系统调用名称及参数值。
可选的，所述判断所述系统调用的执行者是否具有对所述目标调用的访问权限，包括：
获取所述目标调用所属类别；
获取所述执行者对各类别系统调用的访问权限；
根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限；
其中，所述目标调用所属类别、以及所述执行者对各类别系统调用的访问权限是预先设定的。
可选的，在所述接收执行系统调用的请求之前，执行下述操作：
根据预先划分的系统调用类别，指定所述目标调用所属类别；
设置所述执行者对各类别系统调用的访问权限。
相应的，本申请还提供一种执行系统调用的装置，包括：
请求接收单元，用于接收执行系统调用的请求；
目标调用确定单元，用于根据所述系统调用的相关信息，确定待执行的目标调用；
访问权限判断单元，用于判断所述系统调用的执行者是否具有对所述目标调用的访问权限；
执行允许单元，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述目标调用。
可选的，所述目标调用确定单元，具体用于当所述系统调用对应于预设的虚拟系统调用时，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
可选的，所述访问权限判断单元，包括：
目标调用类别获取子单元，用于获取所述目标调用所属类别；
访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
目标调用判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限。
可选的，所述装置还包括：
目标调用类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述目标调用所属类别；
权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
与现有技术相比，本申请具有以下优点：
本申请的执行系统调用的方法，接收执行系统调用的请求后，判断所述系统调用的 执行者是否具有对所述系统调用的访问权限，并在具有时允许执行者执行所述系统调用。本申请提供的上述方法，在判断某一系统调用能否被执行时，是以执行者是否具有相应的访问权限作为依据，即，通过对执行者的授权达到限制系统调用的目的，从而实现了基于执行者身份的差异化控制，而且并没有对开放哪些系统调用加以限制，因此可以灵活地满足用户空间对系统调用的合理访问需求。
附图说明
图1是本申请的一种执行系统调用的方法的实施例的流程图；
图2是本申请实施例提供的判断执行者是否具有对系统调用的访问权限的处理流程图；
图3是本申请的一种执行系统调用的装置的实施例的示意图；
图4是本申请的另一种执行系统调用的方法的实施例的流程图；
图5是本申请的另一种执行系统调用的装置的实施例的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。
在本申请中，分别提供了一种执行系统调用的方法及装置，以及另一种执行系统调用的方法及装置。在下面的实施例中逐一进行详细说明。
本申请提供的执行系统调用的方法，提供了一种对执行系统调用进行权限控制的沙箱机制，其核心在于：在针对接收到的系统调用请求判断某一系统调用能否被执行时，是以执行者是否具有相应的访问权限作为依据，即，只有被授权的执行者才能执行所述系统调用，从而达到了对执行系统调用加以限制的目的，实现了基于执行者身份的差异化控制，而且并没有对开放哪些系统调用加以限制，因此可以灵活地满足用户空间对系统调用的合理访问需求。
需要说明的是，在具体应用中，应用程序的功能可以由进程实现，在支持多线程的系统中，应用程序的功能也可以由多线程并发实现，而进程或者线程在运行过程中可以根据需要执行系统调用(syscall)，即调用syscall。本实施例所述的执行者，通常是指能够独立运行的基本单元，是可以由操作系统调度运行的独立指令流，在具体实施中， 可以是进程，也可以是线程。在本文后续提供的实施例中，将以在Linux系统中实施本技术方案为例进行说明，由于在Linux中进程和线程是统一的，并没有线程和进程之分，通常认为线程是共用数据空间的轻量级进程，因此在以下实施例的描述中，不加以明确的区分，主要采用线程的表述方式。
本申请提供的执行系统调用的方法，在具体实施时，可以在内核的统一入口处实施，即由内核中的独立的服务提供方实施，用户空间发起的执行系统调用的请求可以先提交给所述服务提供方，由服务提供方判断是否允许执行者执行所述系统调用，如果允许则可以将所述系统调用请求分发给相应的系统调用服务例程，或者直接触发相应的系统调用服务例程，从而实现相应的系统调用功能。
本申请提供的执行系统调用的方法，包括以下步骤：接收执行系统调用的请求；判断所述系统调用的执行者是否具有对所述系统调用的访问权限；若具有，则允许所述执行者执行所述系统调用。
实施上述方法时，可以预先设置执行者对系统调用的访问权限，即：预先进行授权，明确设定执行者具有对哪些系统调用的访问权限，并将这些系统调用的名称或者索引号添加到所述执行者的授权集合中；那么在接收到所述执行者发起的系统调用请求后，可以根据预先设定的访问权限，判断所述执行者是否具有对所述系统调用的访问权限，即：判断所述执行者的授权集合中是否包含被请求的系统调用的名称或者索引号，若包含则说明所述执行者具有对所述系统调用的访问权限，允许其执行所述系统调用。
考虑到系统调用的数目通常比较多，而且大部分系统调用可以根据功能或者其他特征进行聚类，因此为了方便授权管理，可以预先对系统调用进行分类，将系统调用划分为预设数目的类别，并以类别为基本单位为执行者设置访问权限，从而可以减少授权过程的工作量，并提高本技术方案的执行效率。在以下提供的实施例中将重点描述基于分类的优选实施方式。下面对本申请的实施例进行详细说明。
请参考图1，其为本申请的一种执行系统调用的方法的实施例的流程图。在具体实施本方法之前，可以根据预先划分的系统调用类别，为本实施例中的待执行系统调用指定所属类别，并设置所述执行者对各类系统调用的访问权限。
(一)根据预先划分的系统调用类别，指定所述系统调用所属类别。
可以将内核提供的系统调用预先划分为预设数目的类别，具体实施时可以根据不同的标准进行分类，例如，可以根据实现的功能划分为：网络操作相关的类别、与文件操作相关的类别、与权限设置相关的类别等。所述预设数目可以根据需要进行设置，对于 32位系统预设数目N可以为32，对于64位系统N可以为64。划分好的类别可以分别用1～N加以标识，例如可以用1标识与网络操作相关的类别，用2标识与文件操作相关的类别。
进行类别划分后，可以为每个系统调用指定其所属类别(在该过程中，自然也为本实施例中的待执行系统调用指定了所属类别)，通常每个系统调用仅属于一个类别。例如：指定系统调用read()属于类别2，即属于与文件操作相关的类别。具体实施时，每个系统调用通常有与其对应的索引号，因此在为每个系统调用指定所属类别后，可以将系统调用的名称或者索引号与其所属类别的标识对应存储。
优选地，为了便于提高进行权限检查的执行效率，本实施例提供采用二进制比特串描述系统调用所属类别的优选实施方式。用于描述系统调用所属类别的二进制比特串的长度与系统调用的类别数N一致，每个比特位分别与相同序号的系统调用类别相对应，即：第1个比特位与类别1相对应，第2个比特位与类别2相对应，......，第N个比特位与类别N相对应，每个比特位的取值则代表系统调用与相应类别的关系：1表示属于该类别，0表示不属于。例如：描述某系统调用所属类别的32位二进制比特串为：0100000......0，则代表该系统调用属于类别2。
进一步地，可以对可供用户空间访问的每个系统调用都采用上述方式进行描述，如果总共有S个系统调用(索引号的取值范围为：0～S-1)，则对应于S个二进制比特串。在具体实施时，可以将描述这些系统调用所属分类的S个二进制比特串统一采用二维bit数组进行存储管理，记为category[N][S]，其中category[0][m]～category[N-1][m]存储的长度为N的二进制比特串，即对应于索引号为m的系统调用的所属类别。
在具体实施时，可以预先设定category[N][S]，也可以在此基础上在系统配置文件中提供配置信息，在系统启动时，通过读取配置文件中的配置信息进行相应的调整，例如：配置信息的形式可以为“syscall.classify type name”，其中syscall.classify为关键字，name为syscall名称，type代表所属类别标识(1～N)，在系统启动时可以将读取的配置信息转化成对应的二进制比特串、并更新category[N][S]中的相应比特位的值。采用这种方式，可以基于策略规则对系统调用所属分类进行调整，具有灵活性。
(二)设置所述执行者对各类别系统调用的访问权限。
本实施例提供基于分类的优选实施方式，采用这种优选实施方式，可以以类别为单位在内核中对执行者授权，在执行者生命周期的至少一个阶段设置所述执行者对各类别系统调用的访问权限，所述生命周期包括以下阶段：创建阶段、创建之后运行之前阶段、 运行阶段等，即：可以在不同阶段按照预设方式调整执行者对各类别系统调用的访问权限，从而实现对执行者访问权限的动态调节，能够为执行系统调用提供更为灵活的安全保障。
在本实施例中所述执行者是指线程，即：为线程设置对各类别系统调用的访问权限。总体说，在运行线程之前的权限设置过程是一个逐步降低权限的过程，以将线程对系统调用的访问权限限制在安全范围中，在线程的运行过程中，则可以根据运行代码的可信程度，自行提高、降低或者恢复访问权限。
作为一种优选实施方式，为了避免线程过度提升自身权限，本实施例还引入了访问能力的概念、并通过在线程运行之前设置其访问能力来实现对其调节访问权限的限制。所述访问能力，表示线程拥有的访问系统调用的能力范围。
具体实施时，线程对各类别系统调用的访问权限(以下简称访问权限)，以及对各类别系统调用的访问能力(以下简称访问能力)，可以分别用集合来描述，访问权限集合中包含线程具有访问权限的类别标识，取值范围1～N，访问能力集合中包含线程具有访问能力的类别标识，取值范围1～N。对于一个线程来说，访问权限集合是访问能力集合的子集。
例如：某线程具有对系统调用类别1、2、3的访问能力，那么该线程的访问能力集合为{1、2、3}，该线程的访问权限集合是{1、2、3}的子集，即可以为以下所列集合之一：{1、2、3}，{1、2}，{1、3}，{2、3}，{1}，{2}，{3}。
优选地，与采用二进制比特串描述系统调用所属类别的优选实施方式相对应，线程的访问权限、以及访问能力也可以采用二进制比特串进行描述。所述二进制比特串的长度与系统调用的类别数一致，每个比特位分别与相同序号的系统调用类别相对应，即：第1个比特位与类别1相对应，第2个比特位与类别2相对应，......，第N个比特位与类别N相对应，每个比特位的取值则代表线程是否具有对相应类别系统调用的访问权限：1，表示线程具有对相应类别系统调用的访问权限，0表示不具有。为了便于描述，本实施例将描述线程对各类别系统调用的访问权限的二进制比特串简称为访问权限比特串，将描述线程对各类别系统调用的访问能力的二进制比特串简称为访问能力比特串。
在具体实施时，所述线程的访问权限，通常与线程的身份标识信息对应存储，其中所述身份标识信息可以是线程的信任状信息(credential)，也可以是其他可以标识线程身份的信息。首次设置时可以将线程的访问权限与身份标识信息对应存储，后续设置时可以先根据线程的身份标识信息获取与其对应存储的访问权限，然后对访问权限进行更 新，再将更新后的访问权限与身份标识信息对应存储。同理，设置线程的访问能力，也可以采用将访问能力与线程的身份标识信息对应存储的方式。
下面以在32位Linux系统中为线程设置访问权限为例，从线程的创建、线程创建之后运行之前、以及线程运行过程中这三个阶段，对其访问权限的设置作进一步详细说明，其中，在前两个阶段，也可以对线程的访问能力进行设置。
1)创建线程时，线程可以继承创建者的访问权限。
在创建线程时，可以用创建者的访问权限设置所述执行者的相应访问权限。
在Linux系统的init进程启动时，其访问权限(permissoin)比特串和访问能力(capability)比特串都初始化为0xffffffff，即所有bit位都是1，从而拥有对所有类别系统调用的访问权限和访问能力；随后，Init进程运行负责创建应用进程的特定进程，例如：seed进程；seed进程初始化完毕后，降低其访问权限和访问能力，例如：删除对部分预设系统调用类别的访问权限和访问能力，以达到seed进程的最小权限。具体实施时，可以将seed进程的访问权限比特串和访问能力比特串中的相应比特位清除为0，然后用更新后的比特串设置seed进程的访问权限和访问能力。
Seed进程接收启动应用程序A的请求后，在内核中完成应用程序A的主线程threadA的实体创建，并根据seed的访问权限设置threadA的访问权限和访问能力，即：threadA可以继承创建者的访问权限和访问能力，设置threadA的访问权限比特串＝threadA的访问能力比特串＝Seed的访问权限比特串，那么threadA就拥有了从Seed继承的访问权限和访问能力。
此处给出了线程继承创建者的访问权限的实施方式，在具体实施中，也可以按照预设授权方案设置所述线程对各类别系统调用的访问权限和访问能力，即：将线程的访问权限和访问能力设置为预设授权方案中指定的值。
2)创建线程之后、运行线程之前，降低线程的访问权限。
由于threadA即将运行的应用代码，通常是不可信的，为了避免恶意执行系统调用带来的安全性问题，在创建threadA的实体后，在运行该线程之前，即：运行应用A的代码之前，还可以按照预设方式进一步执行降权操作，以将threadA对系统调用的访问权限和访问能力限制在安全范围中。所述进一步执行降权操作，包括：根据系统配置文件降权，和/或根据应用的配置文件降权，下面分别进行说明。
a)根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限。
系统配置文件中可以显示地设定针对各种身份类别的权限配置信息，例如，其配置格式可以为：setcap user capability，其中user即对应于各种身份类别，如：普通应用、系统应用、特殊应用等，capability是对各类别系统调用的访问范围。在创建threadA的实体后，可以根据应用A的预设特征，例如：签名信息或者应用名称、路径等信息，按照预设的身份转换规则，生成表征threadA的身份类别信息，然后根据系统配置文件中针对所述身份类别的权限配置信息执行降权操作。
例如，threadA被创建后，具有与uid/gid设置相关的系统调用类别的访问权限和访问能力，但是系统配置文件中显示指定的capability中不包含该类别，则可以将threadA的访问权限比特串和访问能力比特串中，与该类别对应的比特位清除为0，然后用更新后的比特串设置threadA的访问权限和访问能力。
b)根据所述执行者所属应用的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
通常应用程序A可以在其配置文件中申明其需要的功能权限，例如：需要收发短信的功能权限，需要访问通讯录的功能权限等，因此运行threadA之前，可以根据应用程序申明的功能权限，选择实现相应功能的系统调用，并确定这些系统调用对应的系统调用类别，即：确定应用程序A申明的功能权限所涉及的系统调用类别，然后执行相应的降权操作，从threadA的访问权限比特串和访问能力比特串中，将未涉及的系统调用类别对应的比特位清除为0，然后用更新后的比特串设置threadA的访问权限和访问能力。
需要说明的是，threadA作为应用程序A的主线程，当其脱离Seed后，还可以根据其功能需求创建其他功能子线程，一方面其创建的子线程可以继承threadA的访问权限和访问能力，另一方面在运行子线程之前，还可以降低子线程的访问权限和访问能力，例如：删除与创建线程相关的系统调用类别的访问权限和访问能力。具体实现时，可以将所述子线程的访问权限比特串和访问能力比特串中的相应比特位清除为0、然后用更新后的比特串设置子线程的访问权限和访问能力。
3)线程运行过程中，自行调节访问权限。
此处所述线程包括应用程序A的主线程threadA，也包括threadA创建的子线程，这些线程在运行过程中，都可以根据需要自行调节各自的访问权限，下面以threadA为例，进行说明。
threadA创建完毕后开始运行相应的应用代码，在运行过程中，可能需要加载运行不可信代码，例如：第三方提供的代码，或者调用第三方提供的库中的接口等，这些代码 的安全性通常未得到有效验证，因此在加载运行不可信代码之前，threadA可以自行降低访问权限，但是要保留访问能力，即：将访问权限比特串中禁止不可信代码执行的系统调用类别对应的比特位清除为0，并且不修改访问能力比特串，然后用更新后的访问权限比特串设置threadA的访问权限。
在所述不可信代码运行完毕后，threadA可以恢复其对各类别系统调用的访问权限。ThreadA可以将其访问权限恢复为在加载上述不可信代码之前的访问权限，如果之前降低访问权限时，未记录降权前的访问权限，那么可以在不可信代码运行完毕后，以threadA的访问能力为上限，对其访问权限进行恢复，但是不能超出访问能力的限制。
此外，threadA在运行过程中，在加载运行可信代码之前，可以自行提高访问权限。例如：为了确保可信代码实现其功能，可以根据可信代码的需求，提高threadA的访问权限，即可以增加其具有访问权限的系统调用类别，以保证可信代码实现其功能。但是threadA在提高其访问权限时，也需要以其访问能力为上限，在访问能力的限制之内进行权限提升。
在具体实施时，可以为线程提供一个setcap()权限设置接口，当需要设置线程的访问权限时，可以将待设置的访问权限信息(例如：访问权限比特串)作为入口参数并调用setcap()接口，由该接口函数在内核中实现所述设置功能。如果需要设置访问能力，则可以将访问能力信息(例如：访问能力比特串)也作为入口参数传入，由setcap()函数在内核中实现相应的设置功能。
需要说明的是，上述给出的在各阶段设置线程访问权限的方式，在具体实施时，可以不全部采用，而是根据需要进行相应的选择和组合，例如：可以仅在创建时设置线程的访问权限，或者在创建时设置权限、并在线程运行过程中进行权限调节等，都是可以的。
在创建线程及线程运行等各个阶段，可以通过以上描述的时机和方式设置线程的访问权限(和访问能力)，同时，在线程的运行过程中可能会执行系统调用，此时，可以执行本实施例的步骤101-步骤104，根据线程的访问权限判断其是否可以执行所述系统调用，从而实现对系统调用的访问限制。下面对各个步骤逐一进行说明。
步骤101、接收执行系统调用的请求。
线程执行某一系统调用后，通常会陷入内核，此时位于内核入口处的、实施了本方法的处理程序就会接收到执行所述系统调用的请求，所述请求中通常携带待执行系统调用的索引号或者名称，以及执行系统调用的相关参数。
步骤102、判断所述系统调用的执行者是否具有对所述系统调用的访问权限，若具有，则执行步骤103，否则，执行步骤104。
在具体实施时，可以包括步骤102-1至102-3，下面结合图2作进一步说明。
步骤102-1、获取所述系统调用所属类别。
根据前面的描述，已经预先为每个系统调用指定其所属的系统调用类别，其中自然也包括步骤101接收到的待执行的系统调用，此时可以根据待执行的系统调用的名称或者索引号，获取其所属的系统调用类别，例如：获取其所属的系统调用类别的标识。
如果在预先指定系统调用类别时，采取了用二进制比特串描述的优选实施方式，并且利用二维bit数组category[N][S]存储、管理系统调用所属分类，那么本步骤可以通过待执行系统调用的索引号scno查询数组category[N][S]，从而获取待执行系统调用所属的类别信息category[N][scno]，将这N个比特组合就得到了该系统调用所属类别的二进制比特串，简称类别比特串。如果步骤101接收到的请求中携带的是系统调用名称，则可以先通过查表等操作将名称转换为索引号。
步骤102-2、获取所述执行者对各类别系统调用的访问权限。
本实施例中，执行者为线程，因此本步骤可以获取已为所述线程设置的访问权限，通常可以根据线程的身份标识信息获取其访问权限。例如：可以通过内核的线程上下文得到线程的信任状信息(credential)，并根据信任状获取其访问权限，例如：访问权限集合。
对于采用二进制比特串描述的优选实施方式，本步骤获取的是所述线程的访问权限比特串。
步骤102-3、根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限，若具有，则执行步骤103，否则，执行步骤104。
本步骤根据步骤102-1获取的待执行系统调用所属类别，以及步骤102-2获取的线程的访问权限，判断所述线程是否能够执行所述系统调用。
如果步骤102-1获取的是所述系统调用所属的系统调用类别的标识、步骤102-2获取的是访问权限集合，即该集合中包含线程具有访问权限的类别标识，那么本步骤可以判断该集合中是否包含步骤102-1获取的类别标识，若包含则说明所述线程具有相应的访问权限。
优选地，如果线程的访问权限、以及系统调用所属类别都是采用二进制比特串描述的，那么本步骤可以采用按位与的优选实施方式：将访问权限比特串permission和类别 比特串category[N][scno]进行按位与操作，即permission&category[N][scno]，在N＝32时，即为一次整数位与操作，如果结果不全为0，则说明所述线程具有对待执行系统调用所属类别的访问权限，可以执行步骤103，否则说明所述线程不具有相应的访问权限，可以向所述线程返回代表“调用失败”或者“无调用权限”等类似的应答结果。采用基于比特位的按位与操作方式进行权限检查，可以快速地得到检查结果，具有较高的执行效率。
需要说明的是，上面给出的优选实施方式中，访问权限比特串中的1，表示线程具有对相应类别系统调用的访问权限，0表示不具有，类别比特串中的1，表示系统调用属于相应类别，0表示不属于，因此在本步骤中采用按位与操作进行判断。在其他实施方式中，所述访问权限比特串与所述类别比特串中的比特位的值也可以采用不同的方式设置，只要表示具有对相应类别系统调用的访问权限的值、与表示系统调用属于相应类别的值一致即可，并且在本步骤中采用相应的运算及判断方式也同样可以实现本技术方案，同样可以取得较高的执行效率。
例如：对于权限比特串，可以用0表示线程具有对相应类别系统调用的访问权限，用1表示不具有；相应的，对于类别比特串，可以用0表示系统调用属于相应类别，1表示不属于。本步骤将访问权限比特串permission和类别比特串category[N][scno]执行按位或操作，并当执行结果不全为1时，判定所述执行者具有对所述系统调用所属类别的访问权限。
步骤103、允许所述执行者执行所述系统调用。
执行到本步骤，说明所述线程具有对待执行系统调用的访问权限，因此可以允许线程执行所述系统调用。在具体实施时，可以将访问请求分发给与所述系统调用对应的处理程序(也称系统调用服务例程)，也可以直接触发相应的系统调用服务例程，从而实现相应的系统调用功能。
步骤104、拒绝所述执行者执行所述系统调用。
执行到本步骤，说明所述线程不具有对待执行系统调用的访问权限，因此拒绝执行所述系统调用。在具体实施时，可以向所述线程返回“系统调用失败”、或者“没有调用权限”等类似的应答。
至此，通过步骤101-步骤104，对本实施例提供的执行系统调用的方法的实施方式作了详细描述。
需要说明的是，本实施例提供的方法虽然是针对系统调用提出的，但是并不仅仅适 用于系统调用，也可以用于自定义的、需要陷入内核实现的接口函数，为了与前者相区分，可以将前者称为原生系统调用，而将自定义的接口函数称为虚拟系统调用。在需要执行虚拟系统调用时，可以用预先设定的数值作为入口参数值、然后调用某预设的原生系统调用，例如以本实施例中提及的setcap()作为预设的虚拟系统调用为例，可以预先设定如果采用预设数值100作为入口参数param1的值、并调用某原生系统调用syscallA，则其对应的是预设虚拟系统调用setcap()，即陷入内核后真正执行的是setcap()调用。在这种情况下，同样也可以针对setcap()调用进行权限检查，以对线程修改自身权限加以限制。下面对具体实施方式作进一步说明。
在步骤101接收执行系统调用的请求之后，可以先根据所述系统调用的相关信息，确定其是否对应于预设的虚拟系统调用，若是，则判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时允许所述执行者执行所述虚拟系统调用；若否，则按照上述实施例中的步骤102进行处理。其中，所述系统调用的相关信息包括：系统调用名称及参数值，仍采用之前给出的例子，如果系统调用名称为syscallA，参数值为100，则可以确定其对应于预设的虚拟系统调用setcap()。
如果采用基于分类的优选实施方式，在执行步骤101之前，可以根据预先划分的系统调用类别、指定每个系统调用所属类别，同时也可以指定虚拟系统调用所属类别，并同样设置执行者，即本实施例中的线程，对各类别系统调用的访问权限。
以虚拟系统调用setcap()为例，可以先为虚拟系统调用setcap()指定对应的系统调用索引号s1(不能和其他syscall的索引号冲突)，然后将category[N][S]表扩展为category[N][S1]，其中S1>＝s1，并通过系统配置文件中的配置信息指定虚拟系统调用setcap()所属类别，例如：“syscall.classify type setcap”，其中type代表类别标识(1～N)。那么category[0][s1]～category[N-1][s1]存储的长度为N的二进制比特串，即为虚拟系统调用setcap()的类别比特串。
线程在运行过程中，可以根据需要执行系统调用，在内核的统一入口处，如果根据待执行系统调用的相关信息确定其对应为预设的虚拟系统调用setcap()，那么在判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限时，可以采用基于比特位的按位与操作方式，即将setcap()的类别比特串与所述执行者的访问权限比特串执行按位与操作，如果结果不全为零，则说明所述执行者具有对setcap()所属类别的访问权限，因此可以执行setcap()，否则不能执行。
采用上述支持虚拟系统调用的实施方式，可以扩展本实施例提供的沙箱机制的应用 场景。对于需要陷入内核执行的非系统调用，通过将其虚拟为系统调用，可以简化代码编写的工作量，而且同样可以在内核入口处检查执行者是否具有对虚拟系统调用的访问权限，从而可以在对系统调用提供访问控制的基础上，对虚拟系统调用也提供访问控制机制，进一步保障系统的安全性。
综上所述，本实施例提供的执行系统调用的方法，在判断某一系统调用能否被执行时，是以执行者是否具有相应的访问权限作为依据，即，通过对执行者的授权达到限制系统调用的目的，从而实现了基于执行者身份的差异化控制，而且并没有对开放哪些系统调用加以限制，因此可以灵活地满足用户空间对系统调用的合理访问需求。
在上述的实施例中，提供了一种执行系统调用的方法，与之相对应的，本申请还提供一种执行系统调用的装置。请参看图3，其为本申请的一种执行系统调用的装置实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种执行系统调用的装置，包括：请求接收单元301，用于接收执行系统调用的请求；权限判断单元302，用于判断所述系统调用的执行者是否具有对所述系统调用的访问权限；执行允许单元303，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述系统调用；执行拒绝单元304，用于当所述访问权限判断单元的输出为否时，拒绝所述执行者执行所述系统调用。
可选的，所述权限判断单元，包括：
类别获取子单元，用于获取所述系统调用所属类别；
访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限。
可选的，所述装置还包括：
类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述系统调用所属类别；
权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
可选的，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位进行位运算，并根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限。
可选的，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描 述所述系统调用所属类别的二进制比特串，逐位执行按位与操作，并当执行结果不全为0时判定所述执行者具有对所述系统调用所属类别的访问权限。
可选的，所述权限设置单元，具体用于将所述执行者对各类别系统调用的访问权限与其身份标识信息对应存储；
所述访问权限获取子单元，具体用于根据所述执行者的身份标识信息获取所述执行者的所述访问权限。
可选的，所述访问权限获取子单元，具体用于从所述执行者的运行上下文信息中获取其身份标识信息，并根据所述身份标识信息获取所述执行者的所述访问权限。
可选的，所述权限设置单元包括：
权限继承子单元，用于在创建所述执行者时，按照预设授权方案设置所述执行者对各类别系统调用的访问权限；或者，用创建者对各类别系统调用的访问权限设置所述执行者的相应访问权限。
可选的，所述权限设置单元还包括：
运行前权限降低子单元，用于在创建所述执行者之后、在运行所述执行者之前，按照预设方式降低所述执行者对各类别系统调用的访问权限。
可选的，所述运行前权限降低子单元包括：
第一降低子单元，用于根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限；和/或，
第二降低子单元，用于根据所述执行者所属应用程序的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
运行后权限降低子单元，用于所述执行者在运行过程中，在加载运行不可信代码之前降低其对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
权限恢复单元，用于在所述不可信代码运行完毕后，恢复所述执行者对各类别系统调用的访问权限。
可选的，所述权限设置单元还包括：
权限提高子单元，用于所述执行者在运行过程中，在加载运行可信代码之前提高其对各类别系统调用的访问权限。
可选的，所述权限降低子单元和所述运行前权限降低子单元，还分别用于相应设置 所述执行者对各类别系统调用的访问能力；
所述权限提高子单元，具体用于在所述执行者对各类别系统调用的访问能力之内，提高所述执行者的访问权限。
可选的，所述装置还包括：
虚拟调用确定单元，用于在所述请求接收单元接收执行系统调用的请求后，根据所述系统调用的相关信息，确定其是否对应于虚拟系统调用，并在不对应时，触发所述权限判断单元工作；
虚拟调用权限判断单元，用于当所述虚拟调用确定单元的输出为是时，判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时，允许所述执行者执行所述虚拟系统调用。
此外，本申请还提供另一种执行系统调用的方法。请参考图4，其为本申请提供的另一种执行系统调用的方法的实施例的流程图，本实施例与上述方法实施例步骤相同的部分不再赘述，下面重点描述不同之处。本申请提供的另一种执行系统调用的方法包括：
步骤401、接收执行系统调用的请求。
在执行本步骤之前，可以根据预先划分的系统调用类别，指定每个系统调用以及预设的虚拟系统调用所属类别，并设置所述执行者对各类别系统调用的访问权限。
步骤402、根据所述系统调用的相关信息，确定待执行的目标调用。
所述系统调用的相关信息包括：系统调用名称及参数值。
本步骤可以根据系统调用名称及参数值，判断所述系统调用是否对应于预设的虚拟系统调用，若是，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
步骤403、判断所述系统调用的执行者是否具有对所述目标调用的访问权限，若具有，执行步骤404，否则，执行步骤405。
在执行步骤401之前，已经为每个系统调用以及预设的虚拟系统调用指定了所属类别，其中自然也包括所述目标调用，因此本步骤可以获取所述目标调用所属的系统调用类别，并可以获取所述执行者对各类别系统调用的访问权限，然后根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限，若具有，则执行步骤404。
步骤404、允许所述执行者执行所述目标调用。
步骤405、拒绝所述执行者执行所述目标调用。
在上述的实施例中，提供了另一种执行系统调用的方法，与之相对应的，本申请还提供另一种执行系统调用的装置。请参看图5，其为本申请的另一种执行系统调用的装置的实施例的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种执行系统调用的装置，包括：请求接收单元501，用于接收执行系统调用的请求；目标调用确定单元502，用于根据所述系统调用的相关信息，确定待执行的目标调用；访问权限判断单元503，用于判断所述系统调用的执行者是否具有对所述目标调用的访问权限；执行允许单元504，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述目标调用；执行拒绝单元505，用于当所述访问权限判断单元的输出为否时，拒绝所述执行者执行所述目标调用。
可选的，所述目标调用确定单元，具体用于当所述系统调用对应于预设的虚拟系统调用时，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
可选的，所述访问权限判断单元，包括：
目标调用类别获取子单元，用于获取所述目标调用所属类别；
访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
目标调用判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限。
可选的，所述装置还包括：
目标调用类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述目标调用所属类别；
权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介 质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (42)

  1. 一种执行系统调用的方法，其特征在于，包括：
    接收执行系统调用的请求；
    判断所述系统调用的执行者是否具有对所述系统调用的访问权限；
    若具有，则允许所述执行者执行所述系统调用。
  2. 根据权利要求1所述的执行系统调用的方法，其特征在于，所述判断所述系统调用的执行者是否具有对所述系统调用的访问权限，包括：
    获取所述系统调用所属类别；
    获取所述执行者对各类别系统调用的访问权限；
    根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限；
    其中，所述系统调用所属类别、以及所述执行者对各类别系统调用的访问权限是预先设定的。
  3. 根据权利要求2所述的执行系统调用的方法，其特征在于，在所述接收执行系统调用的请求之前，执行下述操作：
    根据预先划分的系统调用类别，指定所述系统调用所属类别；
    设置所述执行者对各类别系统调用的访问权限。
  4. 根据权利要求2所述的执行系统调用的方法，其特征在于，所述执行者对各类别系统调用的访问权限、以及所述系统调用所属类别分别采用二进制比特串描述，其长度分别与系统调用的类别数一致，所述两个二进制比特串中各比特位分别与相同序号的系统调用类别相对应；其中，描述所述访问权限的二进制比特串中的每个比特位的值表示所述执行者是否具有对相应类别系统调用的访问权限，描述所述系统调用所属类别的二进制比特串中的每个比特位的值表示所述系统调用是否属于相应类别，并且表示具有对相应类别系统调用的访问权限的值、与表示所述系统调用属于相应类别的值一致；
    所述根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限，包括：
    将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位进行位运算；
    根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限。
  5. 根据权利要求4所述的执行系统调用的方法，其特征在于，描述所述访问权限 的二进制比特串中的1，表示所述执行者具有对相应类别系统调用的访问权限，0表示不具有；描述所述系统调用所属类别的二进制比特串中的1，表示所述系统调用属于相应类别，0表示不属于；
    所述逐位进行位运算，包括：逐位执行按位与操作；
    所述根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限，包括：若执行结果不全为0，则判定所述执行者具有对所述系统调用所属类别的访问权限。
  6. 根据权利要求3所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，采用如下方式实现：将所述执行者对各类别系统调用的访问权限与其身份标识信息对应存储；
    所述获取所述执行者对各类别系统调用的访问权限，包括：根据所述执行者的身份标识信息获取所述执行者的所述访问权限。
  7. 根据权利要求6所述的执行系统调用的方法，其特征在于，所述身份标识信息包括：所述执行者的信任状信息。
  8. 根据权利要求6所述的执行系统调用的方法，其特征在于，采用如下方式获取所述身份标识信息：从所述执行者的运行上下文信息中获取其身份标识信息。
  9. 根据权利要求3所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，包括：
    在创建所述执行者时，按照预设授权方案设置所述执行者对各类别系统调用的访问权限；或者，用创建者对各类别系统调用的访问权限设置所述执行者的相应访问权限。
  10. 根据权利要求9所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，还包括：
    在创建所述执行者之后、在运行所述执行者之前，按照预设方式降低所述执行者对各类别系统调用的访问权限。
  11. 根据权利要求10所述的执行系统调用的方法，其特征在于，所述按照预设方式降低所述执行者对各类别系统调用的访问权限，包括：
    根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限；和/或，
    根据所述执行者所属应用程序的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
  12. 根据权利要求9所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，还包括：
    所述执行者在运行过程中，在加载运行不可信代码之前降低其对各类别系统调用的访问权限。
  13. 根据权利要求12所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，还包括：
    在所述不可信代码运行完毕后，恢复所述执行者对各类别系统调用的访问权限。
  14. 根据权利要求10所述的执行系统调用的方法，其特征在于，所述设置所述执行者对各类别系统调用的访问权限，还包括：
    所述执行者在运行过程中，在加载运行可信代码之前提高其对各类别系统调用的访问权限。
  15. 根据权利要求14所述的执行系统调用的方法，其特征在于，在所述执行者运行之前，在设置所述执行者对各类别系统调用的访问权限时，还相应设置所述执行者对各类别系统调用的访问能力；所述执行者具有访问权限的系统调用类别集合是其具有访问能力的系统调用类别集合的子集；
    所述提高其对各类别系统调用的访问权限，包括：在所述执行者对各类别系统调用的访问能力之内，提高所述执行者的访问权限。
  16. 根据权利要求1所述的执行系统调用的方法，其特征在于，在所述接收执行系统调用的请求之后，包括：
    根据所述系统调用的相关信息，确定其是否对应于预设的虚拟系统调用；
    若是，则判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时，允许所述执行者执行所述虚拟系统调用；
    若否，则执行所述判断所述系统调用的执行者是否具有对所述系统调用的访问权限的步骤。
  17. 根据权利要求16所述的执行系统调用的方法，其特征在于，所述系统调用的相关信息，包括：系统调用名称及参数值。
  18. 根据权利要求1-17任一项所述的执行系统调用的方法，其特征在于，所述执行者包括：可独立运行的基本单元；所述可独立运行的基本单元包括：线程或者进程。
  19. 一种执行系统调用的装置，其特征在于，包括：
    请求接收单元，用于接收执行系统调用的请求；
    权限判断单元，用于判断所述系统调用的执行者是否具有对所述系统调用的访问权限；
    执行允许单元，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述系统调用。
  20. 根据权利要求19所述的执行系统调用的装置，其特征在于，所述权限判断单元，包括：
    类别获取子单元，用于获取所述系统调用所属类别；
    访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
    判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述系统调用所属类别的访问权限。
  21. 根据权利要求20所述的执行系统调用的装置，其特征在于，还包括：
    类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述系统调用所属类别；
    权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
  22. 根据权利要求20所述的执行系统调用的装置，其特征在于，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位进行位运算，并根据运算结果判定所述执行者是否具有对所述系统调用所属类别的访问权限。
  23. 根据权利要求22所述的执行系统调用的装置，其特征在于，所述判断执行子单元，具体用于将描述所述访问权限的二进制比特串与描述所述系统调用所属类别的二进制比特串，逐位执行按位与操作，并当执行结果不全为0时判定所述执行者具有对所述系统调用所属类别的访问权限。
  24. 根据权利要求21所述的执行系统调用的装置，其特征在于，所述权限设置单元，具体用于将所述执行者对各类别系统调用的访问权限与其身份标识信息对应存储；
    所述访问权限获取子单元，具体用于根据所述执行者的身份标识信息获取所述执行者的所述访问权限。
  25. 根据权利要求24所述的执行系统调用的装置，其特征在于，所述访问权限获取子单元，具体用于从所述执行者的运行上下文信息中获取其身份标识信息，并根据所述身份标识信息获取所述执行者的所述访问权限。
  26. 根据权利要求21所述的执行系统调用的装置，其特征在于，所述权限设置单 元包括：
    权限继承子单元，用于在创建所述执行者时，按照预设授权方案设置所述执行者对各类别系统调用的访问权限；或者，用创建者对各类别系统调用的访问权限设置所述执行者的相应访问权限。
  27. 根据权利要求26所述的执行系统调用的装置，其特征在于，所述权限设置单元还包括：
    运行前权限降低子单元，用于在创建所述执行者之后、在运行所述执行者之前，按照预设方式降低所述执行者对各类别系统调用的访问权限。
  28. 根据权利要求27所述的执行系统调用的装置，其特征在于，所述运行前权限降低子单元包括：
    第一降低子单元，用于根据所述执行者的身份类别以及系统配置文件中针对所述身份类别的权限配置信息，降低所述执行者对各类别系统调用的访问权限；和/或，
    第二降低子单元，用于根据所述执行者所属应用程序的配置文件中的权限申明信息，降低所述执行者对各类别系统调用的访问权限。
  29. 根据权利要求26所述的执行系统调用的装置，其特征在于，所述权限设置单元还包括：
    运行后权限降低子单元，用于所述执行者在运行过程中，在加载运行不可信代码之前降低其对各类别系统调用的访问权限。
  30. 根据权利要求29所述的执行系统调用的装置，其特征在于，所述权限设置单元还包括：
    权限恢复单元，用于在所述不可信代码运行完毕后，恢复所述执行者对各类别系统调用的访问权限。
  31. 根据权利要求27所述的执行系统调用的装置，其特征在于，所述权限设置单元还包括：
    权限提高子单元，用于所述执行者在运行过程中，在加载运行可信代码之前提高其对各类别系统调用的访问权限。
  32. 根据权利要求31所述的执行系统调用的装置，其特征在于，所述权限降低子单元和所述运行前权限降低子单元，还分别用于相应设置所述执行者对各类别系统调用的访问能力；
    所述权限提高子单元，具体用于在所述执行者对各类别系统调用的访问能力之内， 提高所述执行者的访问权限。
  33. 根据权利要求19所述的执行系统调用的装置，其特征在于，所述装置还包括：
    虚拟调用确定单元，用于在所述请求接收单元接收执行系统调用的请求后，根据所述系统调用的相关信息，确定其是否对应于虚拟系统调用，并在不对应时，触发所述权限判断单元工作；
    虚拟调用权限判断单元，用于当所述虚拟调用确定单元的输出为是时，判断所述系统调用的执行者是否具有对所述虚拟系统调用的访问权限，并在具有时，允许所述执行者执行所述虚拟系统调用。
  34. 一种执行系统调用的方法，其特征在于，包括：
    接收执行系统调用的请求；
    根据所述系统调用的相关信息，确定待执行的目标调用；
    判断所述系统调用的执行者是否具有对所述目标调用的访问权限；
    若具有，则允许所述执行者执行所述目标调用。
  35. 根据权利要求34所述的执行系统调用的方法，其特征在于，所述根据所述系统调用的相关信息，确定待执行的目标调用，包括：
    当所述系统调用对应于预设的虚拟系统调用时，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
  36. 根据权利要求34所述的执行系统调用的方法，其特征在于，所述系统调用的相关信息包括：系统调用名称及参数值。
  37. 根据权利要求34所述的执行系统调用的方法，其特征在于，所述判断所述系统调用的执行者是否具有对所述目标调用的访问权限，包括：
    获取所述目标调用所属类别；
    获取所述执行者对各类别系统调用的访问权限；
    根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限；
    其中，所述目标调用所属类别、以及所述执行者对各类别系统调用的访问权限是预先设定的。
  38. 根据权利要求37所述的执行系统调用的方法，其特征在于，在所述接收执行系统调用的请求之前，执行下述操作：
    根据预先划分的系统调用类别，指定所述目标调用所属类别；
    设置所述执行者对各类别系统调用的访问权限。
  39. 一种执行系统调用的装置，其特征在于，包括：
    请求接收单元，用于接收执行系统调用的请求；
    目标调用确定单元，用于根据所述系统调用的相关信息，确定待执行的目标调用；
    访问权限判断单元，用于判断所述系统调用的执行者是否具有对所述目标调用的访问权限；
    执行允许单元，用于当所述访问权限判断单元的输出为是时，允许所述执行者执行所述目标调用。
  40. 根据权利要求39所述的执行系统调用的装置，其特征在于，所述目标调用确定单元，具体用于当所述系统调用对应于预设的虚拟系统调用时，将所述虚拟系统调用作为所述目标调用，否则将所述系统调用作为所述目标调用。
  41. 根据权利要求39所述的执行系统调用的装置，其特征在于，所述访问权限判断单元，包括：
    目标调用类别获取子单元，用于获取所述目标调用所属类别；
    访问权限获取子单元，用于获取所述执行者对各类别系统调用的访问权限；
    目标调用判断执行子单元，用于根据所述获取的信息，判断所述执行者是否具有对所述目标调用所属类别的访问权限。
  42. 根据权利要求41所述的执行系统调用的装置，其特征在于，还包括：
    目标调用类别指定单元，用于在所述请求接收单元工作之前，根据预先划分的系统调用类别，指定所述目标调用所属类别；
    权限设置单元，用于设置所述执行者对各类别系统调用的访问权限。
PCT/CN2017/075853 2016-03-18 2017-03-07 执行系统调用的方法及装置 Ceased WO2017157202A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/132,039 US11093647B2 (en) 2016-03-18 2018-09-14 Method and device for executing system scheduling

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610159286.7 2016-03-18
CN201610159286.7A CN107203715B (zh) 2016-03-18 2016-03-18 执行系统调用的方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/132,039 Continuation-In-Part US11093647B2 (en) 2016-03-18 2018-09-14 Method and device for executing system scheduling

Publications (1)

Publication Number Publication Date
WO2017157202A1 true WO2017157202A1 (zh) 2017-09-21

Family

ID=59850877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/075853 Ceased WO2017157202A1 (zh) 2016-03-18 2017-03-07 执行系统调用的方法及装置

Country Status (3)

Country Link
US (1) US11093647B2 (zh)
CN (1) CN107203715B (zh)
WO (1) WO2017157202A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220291972A1 (en) * 2018-06-14 2022-09-15 Qliktech International Ab Methods And Systems For Application Program Interface Management

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019053592A (ja) * 2017-09-15 2019-04-04 株式会社東芝 プログラマブル集積回路、計算システム及びビット列生成装置
CN108229189A (zh) * 2017-12-29 2018-06-29 北京元心科技有限公司 内核文件的自主访问控制方法及装置
CN109918895B (zh) * 2019-03-07 2023-07-14 上海掌门科技有限公司 用于输出数据的方法、电子设备和计算机可读介质
EP3945439A1 (de) * 2020-07-27 2022-02-02 Siemens Aktiengesellschaft Erweiterte integritätsüberwachung eines containerabbildes
CN112015494B (zh) * 2020-08-27 2024-09-17 中国平安财产保险股份有限公司 第三方api工具调用方法、系统及装置
CN113127208B (zh) * 2021-05-06 2023-08-04 杭州天宽科技有限公司 一种基于线程限制用户访问服务的方法
CN113285933A (zh) * 2021-05-13 2021-08-20 京东数字科技控股股份有限公司 用户访问控制方法、装置、电子设备与存储介质
CN112966257B (zh) * 2021-05-18 2022-02-08 腾讯科技（深圳）有限公司 一种应用程序的授权方法及装置
CN114579254A (zh) * 2022-03-02 2022-06-03 科东(广州)软件科技有限公司 一种微内核虚拟化操作系统的系统调用方法及装置
US20240020378A1 (en) * 2022-07-18 2024-01-18 Benoit Hudzia Secure just-in-time acceleration framework and method thereof

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101493873A (zh) * 2009-03-04 2009-07-29 浪潮电子信息产业股份有限公司 基于内核层技术实现对win平台文件读写操作访问控制方法
CN101739361A (zh) * 2008-11-12 2010-06-16 联想(北京)有限公司 访问控制方法、访问控制装置及终端设备
WO2012030551A1 (en) * 2010-08-31 2012-03-08 International Business Machines Corporation Resource management and security system
CN104112089A (zh) * 2014-07-17 2014-10-22 中国人民解放军国防科学技术大学 基于多策略融合的强制访问控制方法

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7360213B1 (en) 1994-01-26 2008-04-15 Emc Corporation Method for promotion and demotion between system calls and fast kernel calls
US6260057B1 (en) 1995-03-01 2001-07-10 Sun Microsystems, Inc. Apparatus and method for high performance implementation of system calls
US6735666B1 (en) 2000-02-22 2004-05-11 Wind River Systems, Inc. Method of providing direct user task access to operating system data structures
US20030005168A1 (en) 2001-06-29 2003-01-02 Leerssen Scott Alan System and method for auditing system call events with system call wrappers
TWI229817B (en) 2003-01-07 2005-03-21 Wistron Corp Kernel-mode operating system of application program and method thereof
WO2006059493A1 (ja) * 2004-11-30 2006-06-08 Nec Corporation 情報処理装置、デバイスアクセス制御方法、及びデバイスアクセス制御プログラム
US8132002B2 (en) 2006-08-17 2012-03-06 Shi-Wu Lo Fast system call method
CN100504792C (zh) * 2006-10-06 2009-06-24 国际商业机器公司 在用户空间中进行系统调用截取的方法和系统
GB0816556D0 (en) * 2008-09-10 2008-10-15 Univ Napier Improvements in or relating to digital forensics
US8286192B2 (en) 2009-12-04 2012-10-09 Red Hat, Inc. Kernel subsystem for handling performance counters and events
US20110213971A1 (en) * 2010-03-01 2011-09-01 Nokia Corporation Method and apparatus for providing rights management at file system level
US9378387B2 (en) * 2010-03-24 2016-06-28 Oracle International Corporation Multi-level security cluster
US8555377B2 (en) * 2010-04-29 2013-10-08 High Cloud Security Secure virtual machine
US8656465B1 (en) * 2011-05-09 2014-02-18 Google Inc. Userspace permissions service
US9558034B2 (en) * 2011-07-19 2017-01-31 Elwha Llc Entitlement vector for managing resource allocation
US20150128262A1 (en) * 2011-10-28 2015-05-07 Andrew F. Glew Taint vector locations and granularity
US9256552B2 (en) * 2011-11-21 2016-02-09 Cisco Technology, Inc. Selective access to executable memory
US9047463B2 (en) * 2012-06-29 2015-06-02 Sri International Method and system for protecting data flow at a mobile device
US9063721B2 (en) * 2012-09-14 2015-06-23 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
CN102930205A (zh) * 2012-10-10 2013-02-13 北京奇虎科技有限公司 一种监测单元及方法
CN104252380B (zh) * 2013-06-28 2017-11-17 百度在线网络技术（北京）有限公司 Linux系统下系统调用的控制方法及装置
US9680772B2 (en) * 2013-09-09 2017-06-13 Vmware, Inc. System and method for managing configuration of virtual switches in a virtual machine network
US9355262B2 (en) * 2013-12-27 2016-05-31 Intel Corporation Modifying memory permissions in a secure processing environment
US9292686B2 (en) * 2014-01-16 2016-03-22 Fireeye, Inc. Micro-virtualization architecture for threat-aware microvisor deployment in a node of a network environment
JP5711840B1 (ja) * 2014-06-06 2015-05-07 豊田通商株式会社 リレーショナルデータベースを内在するカーネルプログラム、方法及び装置
US20160048688A1 (en) * 2014-08-14 2016-02-18 Google Inc. Restricting System Calls using Protected Storage
US9710659B2 (en) * 2014-08-28 2017-07-18 Virtru Corporation Methods and systems for enforcing, by a kernel driver, a usage restriction associated with encrypted data
US9747438B2 (en) * 2015-11-02 2017-08-29 Red Hat, Inc. Enabling resource access for secure application containers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101739361A (zh) * 2008-11-12 2010-06-16 联想(北京)有限公司 访问控制方法、访问控制装置及终端设备
CN101493873A (zh) * 2009-03-04 2009-07-29 浪潮电子信息产业股份有限公司 基于内核层技术实现对win平台文件读写操作访问控制方法
WO2012030551A1 (en) * 2010-08-31 2012-03-08 International Business Machines Corporation Resource management and security system
CN104112089A (zh) * 2014-07-17 2014-10-22 中国人民解放军国防科学技术大学 基于多策略融合的强制访问控制方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220291972A1 (en) * 2018-06-14 2022-09-15 Qliktech International Ab Methods And Systems For Application Program Interface Management

Also Published As

Publication number Publication date
CN107203715B (zh) 2021-03-19
CN107203715A (zh) 2017-09-26
US11093647B2 (en) 2021-08-17
US20190180055A1 (en) 2019-06-13

Similar Documents

Publication Publication Date Title
WO2017157202A1 (zh) 执行系统调用的方法及装置
US12095912B2 (en) System and method for encrypted disk inspection utilizing disk cloning techniques
CN114730269B (zh) 基于用户提交代码的用于对象存储服务的用户特定数据操纵系统
CN107368259B (zh) 一种向区块链系统中写入业务数据的方法和装置
CN108363920B (zh) 用于容器的系统调用策略
US9594898B2 (en) Methods and systems for controlling access to resources and privileges per process
KR101928127B1 (ko) 애플리케이션용 선택적 파일 액세스 기법
US11343082B2 (en) Resource sharing for trusted execution environments
US20160036860A1 (en) Policy based data processing
US9183391B2 (en) Managing device driver cross ring accesses
CN107622211A (zh) 一种大数据集群权限访问控制方法及装置
US11748140B2 (en) Virtual machine security policy implementation
WO2017118330A1 (zh) 一种应用程序数据访问隔离方法及装置
WO2020233609A1 (zh) 结合代码标注与用户类型的有条件的收据存储方法和节点
CA2636261A1 (en) Virtual roles
TW200530921A (en) System for providing transitions between operating modes of a device
WO2020233640A1 (zh) 结合代码标注与判断条件的收据存储方法和节点
US20240265088A1 (en) Utilizing extended file attributes for working directory
WO2017023775A1 (en) Systems and methods of protecting data from malware processes
CN113239386A (zh) Api权限控制方法及装置
CN107566375B (zh) 访问控制方法和装置
US8621647B1 (en) Restricting privileges of first privileged process in operating system using second privileged process
US12495078B1 (en) Access control policy optimization
US12219048B1 (en) Techniques for encrypted disk cybersecurity inspection utilizing disk cloning
CN113282628A (zh) 大数据平台访问方法、装置及大数据平台、电子设备

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17765744

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17765744

Country of ref document: EP

Kind code of ref document: A1