Path-based access control for message-based operating systems | Patent Publication Number 20180144124
US 20180144124 A1Peter van der Veen
Danny Thomas Dodge
A system and method enforce file system path-based access controls in a message-based operating system. The system and method enforce a list of rules that provide a grant and an access restriction to file system paths to server applications. A path manager receives client messages marked by a kernel to indicate that the client is subject to the path-based access controls. The path manager control access to the file systems served by the server applications in response to the rules that provide grants and access restrictions. The path manager exercises that control by transmitting messages to the client that establishes privileges to systems paths through an authentication protocol.
\n 1. A system to enforce file system path-based access control in a message-based operating system, the system comprising:\n \na processor; and \na path manager executable by the processor to enforce a list of rules that provide an access restriction to file system paths to server applications; the server applications configured to receive client messages via a communication channel in the message-based operating system; where the path manager is further executable by the processor to receive client messages flagged by a kernel to indicate that the client messages are subject to the path-based access controls; where the path manager is further executable by the processor to access the rules governing access to the file system paths; where the path manager is further executable by the processor to control access to file systems served by the server applications in response to the rules that provide the access restriction to file system paths; and where the path manager is further executable by the processor to transmit reply messages to a sender of the client messages via the communication channel that establishes limited access to the file systems paths through an authentication protocol that assures the identity of the path manager and the integrity of the reply messages at the sender of the client messages. \n\n 14. A computer readable medium comprising instructions executable by a processor, the instructions comprising:\n \ninstructions executable to identify client messages that are subject to path-based access controls through a communication channel in a message-based operating system, where the commands to operating system elements are transmitted as client messages over a communication channel in the message-based operating systems; \ninstructions executable to determine access to file system paths in response to a kernel indicating that the client messages are subject to path-based access controls; \ninstructions executable to identify access to paths, based on a list of rules that provide a grant and an access restriction to file system paths to server applications; \ninstructions executable to control, in the message-based operating system, access to the file system paths; and \ninstructions to establish limited access to the file system paths through an authentication protocol that assures the identity of the path manager and the integrity of a reply message controlling the resources to a client process requesting access. \n\n 18. A method to enforce file system path-based access controls in a message-based operating system, the method comprising:\n \nidentifying client messages that are subject to path-based access controls through a communication channel in a message-based operating system, where the commands to operating system elements are transmitted as client messages over a communication channel in the message-based operating systems; \nidentifying client messages that are subject to path-based access controls at a path manager in response to a kernel; \nidentifying access to file system paths, based on a list of rules that provide a grant and an access restriction to file system paths to server applications; and \ncontrolling, in the message-based operating system, access to the file system paths; \nwhere controlling access to the file system paths occurs through an authentication protocol that assures the identity of the path manager and the integrity of a reply message controlling the resources provided to a client process requesting access. \n
This application claims priority to U.S. Provisional Patent Application No. 62/425,928 filed Nov. 23, 2016, titled “Path-Based Access Control for Message-Based Operating Systems,” which is herein incorporated by reference.
This disclosure relates to operating systems and specifically to securing message-based distributed operating systems that enable processes to run in isolation.
This disclosure can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the disclosure. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.
Message based operating systems are exposed to static and dynamic threats. These threats come from local or remote sources that have access to file system paths that serve the sending client and the receiving server. Eavesdroppers that are sometimes called intruders, interceptors, or simply attackers seek to discover or access the privileges that are granted during a file system exchange without proper authorization. Present approaches to securing systems fail to adequately secure such communication at the operating system level.
The disclosed distributed message-based operating system ensures authentication, integrity, and nonrepudiation at the operating system level. By keeping messages secure at the operating system level, the system assures that the receiver of the message can determine its origin and access privileges. This means that an unauthorized intruding process cannot disguise itself as an authorized process. The security behind the path-based access control protocol used in this distributed message-based operating system also makes it possible for the receiver to verify message integrity. The protocol ensures that messages have not been modified or replaced. The protocol also ensures that a sending client cannot deny its transmission to a receiving server.
The disclosed systems and processes secure communication and access in the file system's path namespace. Path-based access control is used to isolate system behavior from one application to another. Implemented through a sandbox or a library of access rules communicatively and tightly coupled to a path manager, the path-based access controls restrict access to the file system's path space as established for an application or groups of application clients. Here, the path-based access control applies to the path namespace and not to the communication channels. In other words, the control is path-based, rather than channel-based even when communication channels are mapped to the file system's path names.
In
The path manager 104 resolves the path request by replying with a canonical, absolute, version of the file system path, as well as a list of servers (shown as 118 and 120) that can service that path. Before replying, the path manager 104 matches the canonical path against each rule in the client's-access controls (that is, the path manager 104 is enforcing the grants and access restrictions associated with the requesting client), which specify grant permissions and access restrictions. If the path matches a forbidden rule, the path manager 104 rejects the path request. If the path request matches an allowed rule, the path manager 104 signs the reply by providing and transmitting a digital signature or a signing key along with each server entry that is not restricted. Some systems implement digital signatures with a one-way hash function. In one such system, the path manager 104 signs the hash of the reply message, which is encrypted with the client thread's private key—one of two types of keys in a public key encryption. In this implementation, the client thread's key is only available through the kernel 102; the client 112 or 114, or 116 has no knowledge or access to its own thread keys.
Upon receipt of the reply message, the client 112 or 114, or 116 transmits messages to each server 118 and/or 120 on its reply list in turn. The client messages include the digital signature or signing key provided by the path manager 104. Upon receipt, each server 118 and/or 120 produces a one-way hash of the reply. Using the digital signature or signing key received with the path manager's message, each server 118 and/or 120 requests the kernel 102 to validate the public key assigned to the message it received. If the signed hash matches the generated hash value, the signature or signing key is validated and the grant permissions and access restrictions are enforced. In this system, the one-way hash function and signature algorithm are agreed upon before the file exchange or path messaging occurs.
Encrypting the hash value of the path manager's reply message to maintain security and access privileges has many benefits. Besides the unlikely scenario of two different replies having the same hash value, signing a hash value of the reply message instead of an entire reply message saves a significant amount of time. Second, while transmitted with the reply, the digital signature (e.g., the encryption of the hash value with the client thread's key) or the signing key can be separated from the reply without affecting message integrity. Third, the digital signature of a hash and signing key can be, and usually is, much smaller than the digital signature of the entire message reducing the systems and processes bandwidth and storage requirements. Fourth, the inclusion of a digital signature or signing key in the messaging scheme assures the identity of the sender (the path manager 104) and the integrity of the file system messages. Here, the clients 112-116 cannot bypass the path manager 104 by communicating directly with the servers (118 and 120) via the communication channel 110 if its access privileges are restricted. If a message does not include a digital signature or signing key or if the digital signature or signing keys fail to match the generated or stored signatures or signing keys at the servers 118 and 120, the messages are rejected and file access is denied when the client request is subject to access restrictions.
While an example signing scheme is described, other signing schemes are used in alternate distributed message-based operating systems. These schemes ensure authentication and that the path-based access controls are enforced at the path or file system level. Some signing and verifying schemes use secret information to sign and public information to verify the signature that are not a public or a private key. Some use different algorithms that can be used to establish proof of authorship or agreement with the content of the message, but not encryption. And, some add steps or information to the signing and verifying processes, such as adding timestamps to the signatures or signing keys, for example.
The path-based access controls described may be created by an application launcher or provided by a collection of non-volatile resources that are pre-written and stored in a non-volatile memory or dynamically generated and accessible through the access rules library 106 or database. In
The path and security policy enforced in the distributed message-based operating system and further shown in
[version=1]
/foo/bar/j*.txt!/foo/bar*
Each line, except for the version header, is a global command or GLOB pattern (a GLOB pattern specifies sets of filenames with wildcard characters) against which client requests are matched. The exclamation point “!” prefix indicates that the pattern represents a rule that rejects the request, while non-prefix patterns represent allowed file paths. The last pattern is a single star “*”, optionally prefixed with an exclamation point “!”, which is a default rule (i.e., either accept or reject all non-matching paths).
A path-based access control structure may define the control objects that are closely coupled to the kernel 102. In some systems, the control object can consist of a header followed by a variable-length list of grants and access restriction rules. A rule comprises an action, which returns an acceptance or a rejection. The rule structure also holds the length of the pattern to facilitate quick traversal of a rule list.
In
When a process is associated with a restricted operating system environment, any open messages it sends are flagged by the kernel 102. This flag is processed by the path manager 104 in view of the library access rules 106.
In
Upon receipt of the signed message, the client transmits _IO_CONNECT messages to each server on its reply list in succession. If the client is subject to access restrictions, the message is flagged by the kernel 102; here, the message includes the signing key provided by the path manager 104. Upon verification of the signing key, the server 118 provides resources that are compliant with the permission grants and access restrictions. If a flagged message is not signed or if the signing key is not verified, the server 118 returns a rejection.
Upon receiving the reply from path manager 104, the client proceeds to send I/O messages to each server 118 and 120 on the reply list in succession. Before receipt at the servers 118 and 120, the kernel 102 determines if the application making the successive open requests is sandboxed at 310, and if it is, sets a flag to bring the condition to the attention of each server 118 and 120. The I/O messages may now contain a flag and a digital signature or signing key provided by the path manager 104 if subject to a sandbox restriction. In response to the I/O message, the server 118 and 120 will verify the signing key or digital signature as described above at 312 and reject any messages that are not correctly signed by replying to the I/O messages sent to the servers 118 and 120 at 314.
The logic illustrated in
Similarly, the systems and process may be implemented with additional, different, or fewer components than illustrated. For instance, the disclosure describes processes that provide proof of authorship or at least agreement with the content of the messages by referring to signing keys and digital signatures separately and distinctly. This is intended to explain that the disclosure encompasses many different processes to establish authentication (allowing a receiver to ascertain its origin) including the use of alternate algorithms for showing proof that may not necessarily include encryption. In any application, the algorithms establish that the message is authentic and the message has not been altered.
The signing protocol provides a series of steps that enable two or more modules or processes to exchange information through other cryptographic security too. When using cryptographic parameters, the secure protocol is interoperable with independent programs and libraries (e.g., a collection of software and data files that perform different tasks) and allows migration from one cryptographic primitive to the next. By allowing migration from one cryptographic primitive to the next, the secure protocol is extensible, efficient, and updatable allowing it to defend against new threats and keep up with improvements that come with technological efficiencies.
The series of steps that describe the secure protocol, involve two or more modules or processes that are designed to accomplish the task of securing the communication between a client application and server application via an open bus. A “series of steps” means that the protocol has a sequence from start to finish. Unless noted, each step is completed in turn, with no step taken before the previous step is completed with some steps being optional. The order of steps may be varied; meaning, that they are not limited to a particular order. “Involve two or more modules or processes” means that at least two or more modules or processes are required to sign or verify the message (e.g., a client and a path manager, a client and a server, etc.). Finally, “designed to accomplish the task of securing the communication between a client application and a server application” means that the protocol must secure the communication across the message-based operating bus. Something that looks like the protocol but does not accomplish the task of ensuring that the sender is authentic and that only the file or path-based open request (or selected other commands) subject to restrictions that it sends was not altered in the message-based operating system and does not enable designated client processes to run in isolation does not disclose the path-based secure protocol described.
In another alternative implementation the path manager 104 is implemented in a tree structure comprising one or more nodes that are linked together in a hierarchical fashion. A node generally refers to a location on a tree structure that can have links to one or more nodes above or below it. The tree structure represents the path space in which various file systems attach to the path manager 104 in the operating system 108. File systems can attach at a root (or origin—whatever file system is first on the list) and at various locations along the paths (trunk and branches) that comprise the tree. For example, the node “/documents/elad” may be implemented in one file system at a later node before the earlier node “/documents” that is implemented by a different local or distributed file system. There is a hierarchy as to what node serves what element and the name path that may service multiple file systems.
In this alternative implementation the system and process generate one or more shadow trees of the path manager 104 that may take various forms from a multi-dimensional tree to a chain representing two or more interconnected file systems. The shadow trees may replicate nearly all of the tree structure that comprises the path manager 104, the shadow tree may comprise a subset of the tree structure that comprises the path manager 104, or the shadow tree may comprise only a single root node depending on the grants or access restrictions placed upon a client. In other words, the height and depth a shadow tree takes may depend on the level of grants and access restrictions assigned to or associated with a client. When restricted, a shadow tree prevents a client from viewing the entire path space of the system and process. The partial copy of the path space represented by the shadow tree provides only limited access rights to the file systems that are available to the path manager 104. If a client requests a file that is not part of the shadow tree associated with or assigned to it, some alternative implementation fail to acknowledge its existence (keeping that portion of the path space hidden from view and hidden from a possible attack). In other words, when accessing files through a shadow tree, users are not made aware of the actual files on the system. In another alternative implementation, the system and process may acknowledge the file's existence and transmit a reply by indicating that that the file is not accessible.
Because clients are under no obligation to access servers 118 and/or 120 that serve the files through the path manager 104, yet another alternative implementation enforces the path-based access controls described with respect to
In yet another alternative implementation, each of the path-based control systems and tree structures described above may further enforce access rights at the file systems themselves. In this further alternative implementation, multiple lines of security are enforced. For example, a system may restrict access via the path-based messaging transactions (or sandbox), shadow tree structures, and at the file systems themselves or via any combination of these technologies.
The disclosed system and process provide a secure protocol for computing devices, portable computing devices, mobile devices, and vehicles for example, that ensure secure processing even when connected to an insecure infrastructure such a physical and/or a virtual bus or a vehicle bus. A vehicle bus, such as a CAN bus, may communicate across remote wireless and/or landline channels. A vehicle may comprise, without limitation, a car, bus, truck, tractor, motorcycle, bicycle, tricycle, quadricycle, or other cycle, ship, submarine, boat or other watercraft, helicopter, drone, airplane or other aircraft, train, tram or other railed vehicle, spaceplane or other spacecraft, and any other type of vehicle whether currently existing or after-arising this disclosure. In other words, a vehicle comprises a device or structure for transporting persons or things.
The processor 404 may be in communication with the memory 406. In one example, the processor 406 may also be in communication with additional elements, such as a network interface (not shown). Examples of the processor 404 may include a general processor, a central processing unit, a microcontroller, a server, an application specific integrated circuit (ASIC), a digital signal processor, a field programmable gate array (FPGA), and/or a digital circuit, analog circuit.
The processor 406 may be one or more devices operable to execute logic. The logic may include computer executable instructions or computer code embodied in the memory 406 or in other memory that when executed by the processor 404, cause the processor 404 to perform the features implemented by the logic of the path manager 104 and/or the system. The computer code may include instructions executable with the processor 404.
The memory 406 may be any device for storing and retrieving data or any combination thereof. The memory 406 may include non-volatile and/or volatile memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or flash memory. Alternatively, or in addition, the memory 406 may include an optical, magnetic (hard-drive) or any other form of data storage device.
The memory 406 may include at least one or more sandbox 408, a memory management module, bus 110, the channel policy 132, message-based operating system 104, the message 110 or the kernel 120, the library of access rules 106, the kernel space 102, the path configurations, the clients 112-116, and the servers 118-120.
The system may be implemented in many different ways. Each element, such as the path manager 104, the sandbox, the library of access rules 106, may be hardware or a combination of hardware and software. For example, each element may include an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), a circuit, a digital logic circuit, an analog circuit, a combination of discrete circuits, gates, or any other type of hardware or combination thereof. Alternatively, or in addition, each element may include memory hardware, such as a portion of the memory 406, for example, that comprises instructions executable with the processor 404 or other processor to implement one or more of the features of the elements. When any one of the elements includes the portion of the memory that comprises instructions executable with the processor, the element may or may not include the processor 404. In some examples, each element may just be the portion of the memory 406 or other physical memory that comprises instructions executable with the processor 404 or other processor to implement the features of the corresponding elements without the element including any other hardware. Because each element includes at least some hardware even when the included hardware comprises software, each element may be interchangeably referred to as a module or hardware module.
Some features are shown stored in a computer readable storage medium (for example, as logic implemented as computer executable instructions or as data structures in memory). All or part of the system and its logic and data structures may be stored on, distributed across, or read from one or more types of computer readable storage media. Examples of the computer readable storage medium may include a hard disk, a flash drive, a cache, volatile memory, non-volatile memory, RAM, flash memory, or any other type of computer readable storage medium or storage media. The computer readable storage medium may include any type of non-transitory computer readable medium, such as a CD-ROM, a volatile memory, a non-volatile memory, ROM, RAM, or any other suitable storage device.
The processing capability of the system may be distributed among multiple entities, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, memories presented as databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented with different types of data structures such as linked lists, hash tables, or implicit storage mechanisms. Logic, such as programs or circuitry, may be combined or split among multiple programs, distributed across several memories and processors, and may be implemented in a library, such as a shared library (for example, a dynamic link library (DLL)).
All of the descriptions, regardless of the particular implementation described, are illustrative in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in memories, all or part of the system or systems may be stored on, distributed across, or read from other computer readable storage media, for example, secondary storage devices such as hard disks, flash memory drives, floppy disks, and CD-ROMs. Moreover, the various elements are but one example of such functionality and any other configurations encompassing similar functionality are possible.
The respective logic, software or instructions for implementing the processes, methods and/or techniques discussed above may be provided on computer readable storage media. The functions, acts or tasks illustrated in the figures or described herein may be executed in response to one or more sets of logic or instructions stored in or on computer readable media. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like. In one example, the instructions are stored on a removable media device for reading by local or remote systems. In other examples, the logic or instructions are stored in a remote location for transfer through a computer network or over data lines. In yet other examples, the logic or instructions are stored within a given computer, central processing unit (“CPU”), graphics processing unit (“GPU”), or system.
Furthermore, although specific components are described above, methods, systems, and articles of manufacture described herein may include additional, fewer, or different components. For example, a processor may be implemented as a microprocessor, microcontroller, application specific integrated circuit (ASIC), discrete logic, or a combination of other type of circuits or logic. Similarly, memories may be DRAM, SRAM, Flash or any other type of memory. Flags, data, databases, tables, entities, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be distributed, or may be logically and physically organized in many different ways. The components may operate independently or be part of a same program or apparatus. The components may be resident on separate hardware, such as separate removable circuit boards, or share common hardware, such as a same memory and processor for implementing instructions from the memory. Programs may be parts of a single program, separate programs, or distributed across several memories and processors.
A second action may be said to be “in response to” a first action independent of whether the second action results directly or indirectly from the first action. However, the second action must occur as “a result of” the first action. The second action may occur at a substantially later time than the first action and still be in response to the first action. Similarly, the second action may be said to be in response to the first action even if intervening actions take place between the first action and the second action, and even if one or more of the intervening actions contribute to the second action to be performed. For example, a second action may be in response to a first action if the first action sets a flag and a third action later initiates the second action whenever the flag is set.
To clarify the use of and to hereby provide notice to the public, the phrases “at least one of <A>, <B>, . . . and <N>” or “at least one of <A>, <B>, <N>, or combinations thereof” are defined by the Applicant in the broadest sense, superseding any other implied definitions hereinbefore or hereinafter unless expressly asserted by the Applicant to the contrary, to mean one or more elements selected from the group comprising A, B, . . . and N. In other words, the phrases mean any combination of one or more of the elements A, B, . . . or N including any one element alone or the one element in combination with one or more of the other elements which may also include, in combination, additional elements not listed.
While various embodiments have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible. Accordingly, the embodiments described herein are examples, not the only possible embodiments and implementations.
The subject-matter of the disclosure may also relate, among others, to the following aspects:
1. A system to enforce file system path-based access control in a message-based operating system, the system comprising:
a processor; and
a path manager executable by the processor to enforce a list of rules that provide an access restriction to file system paths to server applications; the server applications configured to receive client messages via a communication channel in the message-based operating system; where the path manager is further executable by the processor to receive client messages flagged by a kernel to indicate that the client messages are subject to the path-based access controls; where the path manager is further executable by the processor to access the rules governing access to the file system paths; where the path manager is further executable by the processor to control access to file systems served by the server applications in response to the rules that provide the access restriction to file system paths; and where the path manager is further executable by the processor to transmit reply messages to a sender of the client messages via the communication channel that establishes limited access to the file systems paths through an authentication protocol that assures the identity of the path manager and the integrity of the reply messages at the sender of the client messages.
2. The system of claim 1, where the authentication protocol comprises a one-way hash function.
3. The system of claim 1, where the authentication protocol comprises signing each of the reply messages with a public-key cryptography and a one-way hash function.
4. The system of claim 1, where the authentication protocol comprises signing each of the reply messages with a public-key cryptography and a one-way hash function and a time stamp.
5. The system of any of claims 1 to 4, where the message-based operating system comprises a distributed operating system where a file system control is not part of the kernel.
6. The system of any of claims 1 to 5, kernel indicate that the client messages are subject to the path-based access control only in response to a client request.
7. The system of any of claims 1 to 6, where the kernel is executable by the processor to indicate that the messages are not subject to the path-based access control and the path manager is further executable by the processor to transmit reply messages to a sender of the messages via the communication channel that establishes access to the file systems paths without an authentication protocol.
8. The system of any of claims 1 to 6, where the path manager is further executable by the processor to determine that the client messages are not subject to the list of rules that provide the access restriction to file system paths and provides access to the file system paths in response to the kernel indicating that the client messages are subject to the path-based access control.
9. The system of any of claims 1 to 6, where the list of rules that the access restriction to file system paths comprises a sandbox.
10. The system of any of claims 1 to 6, where the sandbox comprises a library of access rules.
11. The system of any of claims 1 to 6, where the kernel comprises a micro-kernel.
12. The system of any of claims 1 to 6, where a configuration file generates the list of rules that provide the access restriction to file system paths.
13. The system of any of claims 1 to 6, where the server application is executable by the processor to refuse to provide limited access to the file systems paths authorized by the path manager it serves in response to the server application determining that the integrity of the reply messages was compromised by executing the authentication protocol.
14. A computer readable medium comprising instructions executable by a processor, the instructions comprising:
instructions executable to identify client messages that are subject to path-based access controls through a communication channel in a message-based operating system, where the commands to operating system elements are transmitted as client messages over a communication channel in the message-based operating systems;
instructions executable to determine access to file system paths in response to a kernel indicating that the client messages are subject to path-based access controls;
instructions executable to identify access to paths, based on a list of rules that provide a grant and an access restriction to file system paths to server applications;
instructions executable to control, in the message-based operating system, access to the file system paths; and
instructions to establish limited access to the file system paths through an authentication protocol that assures the identity of the path manager and the integrity of a reply message controlling the resources to a client process requesting access.
15. The computer readable medium of claim 14, where the kernel comprises a micro-kernel and the list of rules that provide the grant and access restriction is provisioned through a configuration file.
16. The computer readable medium of claim 14, where the authentication protocol comprises a public-key cryptography and a one-way hash function.
17. The computer readable medium of any of claims 14 to 16 where at least one of the rules of the list of rules that provide the grant and access restriction to file system paths comprises a rule that grants access to at least one of the file system paths and at least one of the rules of the list of rules that provide the grant and the access restrictions to file system paths comprises a rule that denies access to at least one of the file system paths.
18. A method to enforce file system path-based access controls in a message-based operating system, the method comprising:
identifying client messages that are subject to path-based access controls through a communication channel in a message-based operating system, where the commands to operating system elements are transmitted as client messages over a communication channel in the message-based operating systems;
identifying client messages that are subject to path-based access controls at a path manager in response to a kernel;
identifying access to file system paths, based on a list of rules that provide a grant and an access restriction to file system paths to server applications; and
controlling, in the message-based operating system, access to the file system paths;
where controlling access to the file system paths occurs through an authentication protocol that assures the identity of the path manager and the integrity of a reply message controlling the resources provided to a client process requesting access.
19. The method of claim 18, further comprising transmitting a request message from a client application to one or more of the server applications such that the message is routed based on the reply message.
20. The method of any of any of claims 18 and 19 where the where the kernel comprises a micro-kernel, control of the file system in the message-based operating system is not part of the kernel.
21. The method of any of claims 18 and 19 where the path-based access controls comprise a shadow tree corresponding to the grant and the access restriction placed on the client messages.
22. The method of any of claims 18 and 19 where the act of controlling access to the file system paths further comprises not identifying file system paths when access is denied.
23. The system of any of claims 1 to 6 where the path-based access control comprises a shadow tree corresponding to the grant and the access restrictions placed on the client messages.
24. The system of any of claims 1 to 6 where the path manager is further executable by the processor to not transmit reply messages to the sender of the client messages via the communication channel when access to the file systems paths is denied.
The disclosed distributed message-based operating systems and methods ensure authentication, integrity, and nonrepudiation at the operating system level. By keeping selected messages secure at the operating system level, the system and methods assure that the receiver of the message can determine its origin and path privileges. This means that an unauthorized intruding process cannot disguise itself as an authorized process when attempting to access a path. The security behind the path-based access controls protocol used in this distributed message-based operating system also makes it possible for the receiver to verify message integrity. The protocol ensures that messages have not been modified or replaced. The protocol also ensures that a sending client cannot deny its transmission to a receiving server.
The disclosed systems and processes secure communication and access in the file system's path namespace. Path-based access control is used to isolate system behavior from one application to another. Implemented through a sandbox or a library of access rules 106 communicatively and tightly coupled to a path manager 104, the path-based access controls restrict access to the file system's path space as established for an application or groups of application clients.
Other systems, methods, features and advantages will be, or will become, apparent to one with skill in the art upon examination of the figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the disclosure, and be protected by the following claims.