Inter-process access control

A kernel receives a request to execute a first process instance from an agent. The first process instance is an instance of a first program. The kernel obtains one or more access control rules related to the agent. The kernel permits execution of the first process instances based on the access control rules. The kernel detects the first process instance attempting to access a second process instance during execution of the first process instance. The second process instance is an instance of a second program currently being executed. The kernel determines whether to grant the first process instance permission to access the second process instances based on the access control rules.

BACKGROUND

The present disclosure relates to inter-process communication, and more specifically, to granting and denying access between process instances.

Inter-process communication may enable higher performance computing by allowing operations to be performed on multi-core processors. Inter-process communication may enable more scalable computing by allowing distributed computing systems and hardware from multiple computers to perform operations cooperatively. Inter-process communication may enable more efficient computing by separating larger programs into smaller programs. Inter-process communication may be used by computers in various fields such as business, medicine, and science.

SUMMARY

Disclosed herein are embodiments of a method and a computer program product for process access control in an operating system. A kernel receives a request to execute a first process instance from an agent. The first process instance is an instance of a first program. The kernel obtains one or more access control rules related to the agent. The kernel permits execution of the first process instances based on the access control rules. The kernel detects the first process instance attempting to access a second process instance during execution of the first process instance. The second process instance is an instance of a second program currently being executed. The kernel determines whether to grant the first process instance permission to access the second process instances based on the access control rules.

Also disclosed herein are embodiments of a system for process access control. A memory stores an operating system, one or more instances of program processes, and one or more access control rules. An input receives one or more process requests from one or more agents. A processor, which is in communication with the memory and the input, executes a kernel of the operating system. The kernel receives a first process-execution request from the input. The first request is to execute a first process instance of a first program. The kernel obtains a first access control rule from the memory. The first access control rule is related to an agent. The kernel permits execution of the first process instance based on the first access control rule. The kernel detects the first process instance attempting to access a second process instance. The second process instance is an instance of a second program currently being executed by the processor. The kernel obtains a second access control rule from the memory. The second access control rule is related to the second process instance. The kernel determines whether to grant the first process instance permission to access the second process instance based on the second access control rule.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to inter-process communication, and more specifically, to granting and denying access between process instances by validating access controls during runtime. While the present disclosure is not necessarily limited to such applications, various aspects of the disclosure may be appreciated through a discussion of various examples using this context.

Access control mechanisms (ACMs) may be used to grant and deny access to various resources of computer systems. ACMs may grant and deny access to computer hardware (e.g., network devices, segments of random access memory, computer processing cycles, etc.). ACMs may also grant and deny access to various software objects, such as text documents or image files. An ACM may be useful for large organizations because it enables granular control over the users within the organizations that wish to perform operations (herein, subjects). An ACM also enables granular control over the variety of software and hardware resources (herein, objects). Administrators of computing systems in large organizations may utilize ACMs to create rules or permissions relating to operations that subjects wish to perform upon objects (e.g., a first user may read a specific directory, a group of users may read and write to an entire network disk, a second group of users may not access certain programs, etc.).

Computer systems have advanced in complexity and capability. Computers are increasingly parallel in nature both in the hardware as well as in the software methodologies that run on that hardware. One cause of this increase in parallelism is the advent of multithreading or multiprocessing where a computing task is broken into multiple smaller tasks (processes) to be spread across multiple processing cores of a central processing unit (e.g., a processor). Multiprocessing is facilitated through the use of one or more software components (e.g., an operating system, a kernel component of the operating system, etc.). Along with parallelism, processes may need the ability to directly share information or operate upon each other. To provide this functionality the operating system may permit inter-process communication (IPC).

An inter-process communication (IPC) controller may enable an ACM implementation of security during execution of programs in a multiprocessing environment. In some embodiments, the IPC controller may be one or more existing software programs that facilitate operation of and resource allocation of computing resources (e.g., an operating system, a kernel, a hypervisor, a microkernel, etc.). In some embodiments, the IPC controller may be one or more existing software programs designed to facilitate ACM between non-process objects, such as a security or access manager. The IPC controller may be a segment of software that facilitates communications between existing programs, such as an IPC controller communicating between a kernel and an access control module.

Processes may need to access one another and the IPC controller may facilitate these accesses by applying one or more rules. The ACM implemented by an IPC controller may be based on one or more methodologies (e.g., discretionary access control, role based access control, rule based access control, mandatory action control, action control lists, and domain control role based access control, etc.). The aforementioned access control methodologies should be appreciated to be non-limiting and are listed for example purposes. The IPC controller may implement rules controlling the ability of a subject process, executed by an agent, to access an object process. The agent may be a human user of a computing system, such as an email subsystem administrator and the rules may be in part based on the permissions given to the human user. The agent may be another process. For example, in a situation where an image editor process calls an image viewer process, the image editor process could be an agent and the image viewer process could be the subject process. Continuing the example, if the image viewer process tries to access a file system process (an object process), the rules may be in part based on the privileges of and the permissions given to the image editor process.

In some embodiments, the IPC controller may implement rules for a subject process to access an object process that are similar to existing rules (e.g., read, write, full control, etc.) for access to non-process objects. For example, the IPC controller may control what a first process may access by selectively granting or denying the first process's a request to read a second process based on a rule that sets the bounds of the first process's read access permissions. The IPC controller may implement rules for a subject process to access an object process that are unique to IPC between two processes. (e.g., launch, execute, kill, terminate, request status, update status, etc.). The IPC controller may implement multiple levels of rules from separate ACMs for a subject process to access an object process (e.g., granting or denying access of a first process to a second process based on a role based access control mechanism and a domain access control mechanism).

In some embodiments, a kernel may implement runtime privileges (domains) validation for a process. For example, when an object (process A) is started by a first user (user A), the object (process A) inherits the domains which are assigned to the first user (user A). When subject (process B) is started by a second user (user B), the subject (process B) inherits the domains of the second user (user B). User and process privileges are stored in the kernel by a security sub system. If the second user (user B) has the same domains as the first user (user A), the subject process (process B) may be granted permission to access the object (process A). Run time validation is done by the security subsystem before allowing subject process (process B) to access the object process (process A).

Continuing the example, if the object (process A) is started by a third user (user C), the object (process A) will have different set of domains—the object (process A) inherits domains of the third user (user C). If the second user (user B) has different domains from the third user (user C), the subject process (process B) may be denied permission to access the object (process A).

FIG. 1depicts a system100to enable access control between processes running on a computer consistent with embodiments of the present disclosure. Though not depicted the computer may include various hardware, such as a processor, memory, and input output devices. An example computer that may be consistent with embodiments is depicted inFIG. 3. The system100may include an operating system110, a system storage112, a first secure storage114, and a second secure storage116. The operating system110may include the following: a kernel120for directing operation of the other components of the system100; a security subsystem130for implementing ACMs for non-process objects; a system runtime memory140for executing instances of operating system related programs.

The operating system110may also control a user runtime memory150for executing instances of user programs. The system runtime memory140may be a logical or virtual partition of a hardware memory of a computer being controlled by the operating system110. The user runtime memory150may be a second logical or virtual partition of the hardware memory of the computer. The separation between the user runtime memory150and the system runtime memory140may provide increased security of the operating system110and associated components (e.g., preventing access between user and system runtime memories without a specific grant of permission). It should be appreciated that the memory separation of system100ofFIG. 1is depicted for example purposes, and that another configuration of various memory separations may be consistent with embodiments of the present disclosure (e.g., user applications, user mode, kernel mode, standard libraries, system extensions, etc.).

The kernel120may be configured to provide access to one or more resources of the system100(e.g., processors, memory, input devices, output devices, network devices, etc.). The kernel120may include one or more associated low levels components (not depicted) to help facilitate running process instances of one or more programs. The kernel120may control the system storage112, the first secure storage114, and the second secure storage116. In some embodiments, the security subsystem130may control the second secure storage116. The system storage112may include program code122and static files124. The program code122may be stored in the static files124. Program code122may be a collection of various programs, such as binaries or libraries. The static files124may be a file system containing various static (e.g., non-process) objects, including, for example, files and folders, such as documents, images, program executables, and the like. The first secure storage114may include runtime access controls126. The runtime access controls126may be a collection of one or more entries that describe process to process access control rules (e.g., any instance of a music player process may submit requests to any file system process instance for music files). The second secure storage116may include static access controls132. The static access controls132may be a collection of one or more entries that describe process to object access control rules (e.g., an instance of a file viewer process running from a first agent may only access a folder with ownership rights of the first agent). In some embodiments, the first secure storage114and the second secure storage116may be the same storage and the runtime access controls126and the static access controls132may be kept together in the same storage. In some embodiments, the first secure storage114may be separate from the second secure storage116. The secure storages may be separate because the format of the entries of the runtime access controls126may be different from the format of the entries of the static access controls132.

The system runtime memory140may host process instances142A,142B, and142C (collectively,142). For example process instance142A may be a network card process that controls a network card, process instance142B may be a file system process that controls reads and writes to a file system, and process instance142C may be a graphics card process that controls image manipulation calls. The user runtime memory150may host process instances152A,152B, and152C (collectively,152). For example process instance152A may be an image editor process that a user uses to manipulate pictures, process instance152B may be a file viewer process that a user uses to open and save various types of documents, and process instance152C may be a web browser that a user uses to connect to the internet. It should be appreciated that the operating system110may be able to host more or less process instances than are depicted herein. The process instances may be processes based on code stored in the program code122.

The kernel120may provide access to hardware and software resources of a computer (not depicted) hosting the system100. The kernel120may provide access directly by utilizing the security subsystem130of the kernel. In detail, the kernel120may receive a request from an agent to retrieve a file from the static files124. The kernel120may coordinate with the security subsystem130to verify if the agent has permission to retrieve the file. The kernel120may send information related to the agent to the security subsystem130, such as username, real name, location, or role. The security subsystem130may transmit to the kernel120one or more entries from the static access controls132. The entries may include a list of objects that the agent has permission to access and what level of access the agent is permitted (e.g., agent may read a file, agent may make a request to a network device, agent may create or modify files on a disk drive, an agent may launch a program at a specified timeframe, etc.). The kernel120may compare the entries to the request from the agent to determine whether the agent should be granted permission to access the requested file. In response to the comparison, the kernel120may either grant or deny the agent access to the file from the static files124.

The kernel120may also permit a first process to access a second process during execution of the first and second processes. As described herein, execution means at any time during which one or more processes are currently running on one or more processing circuits of a computer system. A process may be running on one or more processing circuits in a wait state or an active state. A process may include one or more instances of running code segments from a program executable (e.g., such as a program binary, a subroutine in a library file, etc.) and may be a process instance in any of the following program lifecycle phases: link time, load time, and run time. In some embodiments a process may be consider as being executed, executing, or running even though a processor may not be performing operations upon the process at a specific instant (e.g., where the process instance is in a wait state).

For example, a single-threaded single-processor central processing unit may be tasked, by an operating system, to perform process A and process B. The central processing unit may be begin by performing operations of process A. The central processing unit, or the operating system may place process B in a queued state. At this point, both process A and process B may be considered to be executing or running on the central processing unit. The central processing unit may pause the performance of operations of process A and may place process A in a wait or paused state. Still, process A and process B may be considered to be executing or running on the central processing unit. The central processing unit may begin performing operations of process B, and after an appreciable time, may place process A in an idle or hibernating state. Further still, process A and process B may be considered to be executing or running on the central processing unit.

The kernel120may control process to process access by one or more rules. The control may be exerted between two processes in the user runtime memory150. The control may be exerted between a process in the system runtime memory140and a process in the user runtime memory150. The control may be exerted between two processes in the system runtime memory140. For example, process142A (the subject) may attempt to access process142B (the object) (e.g., process142A may request to terminate process142B). Upon detecting the activity of process142A, the kernel120may identify an agent associated with process142A. The kernel120may retrieve from the runtime access controls126entries associated with process142A, process142B, or both process142A and process142B. The kernel120may determine based on the entries whether process142A has permission to access process142B (e.g., rules indicating permission to terminate process142B). The kernel120may grant process142A access to process142B if an entry that contains the permission for the type of access requested is found in the entries (e.g., process142A may terminate process142B if the kernel120finds a rule granting termination permission of process142B to process142A).

If the kernel120does not find any entries related specifically to process142A and142B, the kernel may determine rules related to process142A and process142B based on the programs from which they were invoked. For example, in one situation process142A is a first process instance based on a first binary from program code122. Process142B is a second process instance based on a second binary from program code122. Process142B may be stored in a first directory of the static files124. The kernel120may retrieve from the static access controls132entries associated with the second binary. The kernel120may retrieve the entries from an intermediary such as the security subsystem130. If the kernel120finds entries related to the second binary in the static access controls132, the kernel120may try to grant or deny access based on those entries. For example, if the agent that invoked process142A has full control over the first directory in the static files124, then kernel120may grant process142A access to process142B. If the kernel120finds entries related to the second binary in the static access controls132, the kernel120may try to create corresponding entries regarding process142B in the runtime access controls126.

FIG. 2depicts an example method200for performing granular access control between processes consistent with embodiments of the present disclosure. Method200may be executed by an operating system charged with facilitating execution of multiple processes on computer hardware detailed in the present embodiments. Method200may perform operation in addition to or different than those depicted inFIG. 2. In some embodiments, operations depicted inFIG. 2may be combined or separated into a different configuration of method200.

From start205, an operating system may detect a process request, at210, to execute a first process. The process request, at210, may come from a first user of the operating system. In response to detecting the process request, at210, the operating system may retrieve, at220, one or more process access rules relating to the first process and the first user. The process access rules may include rules regarding what files and folders the first user may read, modify, and delete. The process access rules may also include rules regarding what programs a user may launch (or execute).

If the first user is permitted, at230, to execute the first process, then the operating system may run an instance of the first process at240. Whether the first user is permitted to run the first process may be based upon the process access rules retrieved at220. During execution of the first process instance, at240, the operating system may monitor the execution of the first process instance. The operating system may detect an inter-process request, at250, from the first process instance to a second process instance. For example, the first process may be thought of as a subject process and the second process an object process that the subject process wants to interact with in some manner, such as a read request. The operating system may retrieve, at260, one or more inter-process access rules relating to the inter-process request. The rules relating to the inter-process request may include rules related to the first user, the first process, the first process instance, the second process, and/or the second process instance. The inter-process access rules may also include rules regarding whether one program, while executing as a process instance, may access other program process instances. In some embodiments, the operating system may fail to retrieve, at260, rules relating to the inter-process request (e.g., no rules exist).

If the first process instance is permitted, at270, to access the second process instance, then the operating system may grant the inter-process access at280. Whether the first process instance is permitted to access the second process instance may be based upon the inter-process access rules retrieved (or failed to be retrieved) at260. If the first process instance is not permitted, at270, to access the second process instance, then the operating system may generate, at290, a warning regarding the unauthorized inter-process access attempt. In an optional operation (not depicted and after the operation at290) the operating system may transmit the warning to an administrative user. In another optional operation (not depicted) if the first process instance is not permitted, at270, to access the second process instance, then the operating system may limit the first process from accessing any other process or static object of the system (e.g., sandboxing). After the inter-process access has been granted at280(or after process execution is not permitted at230, or after warning generation at290) method200ends at295.

FIG. 3depicts the representative major components of an example computer system301that may be used, in accordance with embodiments of the present disclosure. It is appreciated that individual components may vary in complexity, number, type, and\or configuration. The particular examples disclosed are for example purposes only and are not necessarily the only such variations. The computer system301may comprise a processor310, memory320, an input/output interface (herein I/O or I/O interface)330, and a main bus340. The main bus340may provide communication pathways for the other components of the computer system301. In some embodiments, the main bus340may connect to other components such as a specialized digital signal processor (not depicted).

The processor310of the computer system301may be comprised of one or more cores312A,312B,312C,312D (collectively312). The processor310may additionally include one or more memory buffers or caches (not depicted) that provide temporary storage of instructions and data for the cores312. The cores312may perform instructions on input provided from the caches or from the memory320and output the result to caches or the memory. The cores312may be comprised of one or more circuits configured to perform one or methods consistent with embodiments of the present disclosure. In some embodiments, the computer system301may contain multiple processors310. In some embodiments, the computer system301may be a single processor310with a singular core312.

The memory320of the computer system301may include a memory controller322. In some embodiments, the memory320may comprise a random-access semiconductor memory, storage device, or storage medium (either volatile or non-volatile) for storing data and programs. In some embodiments, the memory may be in the form of modules (e.g., dual in-line memory modules). The memory controller322may communicate with the processor310, facilitating storage and retrieval of information in the memory320. The memory controller322may communicate with the I/O interface330, facilitating storage and retrieval of input or output in the memory320.

The I/O interface330may comprise an I/O bus350, a terminal interface352, a storage interface354, an I/O device interface356, and a network interface358. The I/O interface330may connect the main bus340to the I/O bus350. The I/O interface330may direct instructions and data from the processor310and memory320to the various interfaces of the I/O bus350. The I/O interface330may also direct instructions and data from the various interfaces of the I/O bus350to the processor310and memory320. The various interfaces may include the terminal interface352, the storage interface354, the I/O device interface356, and the network interface358. In some embodiments, the various interfaces may include a subset of the aforementioned interfaces (e.g., an embedded computer system in an industrial application may not include the terminal interface352and the storage interface354).

Logic modules throughout the computer system301—including but not limited to the memory320, the processor310, and the I/O interface330—may communicate failures and changes to one or more components to a hypervisor or operating system (not depicted). The hypervisor or the operating system may allocate the various resources available in the computer system301and track the location of data in memory320and of processes assigned to various cores312. In embodiments that combine or rearrange elements, aspects and capabilities of the logic modules may be combined or redistributed. These variations would be apparent to one skilled in the art.