Patent Application
20080126800
The present disclosure generally relates to inter-process communication, and relates in particular to securing of inter-process communication based on trust.
The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Inter-Process Communication (IPC) is used by processes to communicate with each other while running on the same computer. It is an important part in the operating system as synchronizing and data exchange occurs frequently throughout the system operation. However, without protection, as in conventional operating systems, IPC can be used for attacks. Typical examples include sending malicious payload to a privileged process or overloading the IPC to cause denial of service attacks. System V IPC objects includes message queue, semaphore set and share memory segment. These objects are identified by a unique identifier. To access an IPC object, this ID is the only thing needed. Even though a key is needed to obtain the ID, there are scenarios in which other processes can connect to the IPC object without the key. Standard Discretionary Access control (DAC) can be enforced on the IPC objects. However, DAC does not provide sufficient protection. In summary, secure IPC is needed within the OS.
Before launching into discussion of the present teachings, one security mechanism in particular deserves some discussion. Umbrella is a security mechanism for Linux implementing Process-Based Access Control (PBAC). The PBAC scheme moves the responsibility of restricting capabilities of programs from the system administrators to the developers. The reasoning behind this, is that the developers have a deeper knowledge on which restrictions are necessary for their own software. A restriction on a subject, means that it have access to all objects except those objects which is in the restriction list. In difference to other security schemes, PBAC only defines one global security policy.
Global Policy 1. Given that p1 and p2 are nodes in the process tree P and p1 has the restriction set r1 and p2 has the restriction set r2. r1 and r2 being subsets of R which is the set of all possible restrictions. If p1 is a descendant of p2 then r1 is a superset of r2.
This policy ensures that processes are at least as restricted as their parent, regardless of their ownership. Thereby restrictions respect the partial order in the process tree. Umbrella extends this policy by providing a restricted fork system call and signed binaries. The restricted fork system call allows the software developer to apply further restrictions on child processes. The signed binaries enables the developer to embed restrictions in the binary of a program. Furthermore, the signed binaries allows the system administrator to verify the origin and integrity of a program, and to apply restrictions accordingly.
Currently Umbrella only includes restrictions for a limited set of IPC methods, i.e. files, signals, sockets, and named pipes. It is not possible to restrict programs from using the System V IPC methods, that is shared memory, semaphores, and message queues, using Umbrella. As the following example shows, this limitation has some problems, and in the worst case it will actually enable programs to circumvent the restrictions enforced by Umbrella.
Assume, for example, that an e-mail client is using a System V IPC method to communicate with the address book. Whether message queues or shared memory is used is not that important, however, assume that message queues are used in this example. Also, assume the e-mail client and the address book are running as the same user, then the least possible standard Unix permissions for the IPC will be 0600. The attachment is still restricted from using the network and from accessing /boot, /etc, and ˜/.abook on the local file system. However, since the attachment is running as the same user as both the e-mail client and the address book, and no restrictions are enforced on message queues by Umbrella, it will have read/write permissions on the IPC.
The aforementioned permissions enable the attachment to mount at least four attacks: (1) eavesdropping: the attachment will be able to read all, or at least a large part of, the messages exchanged between the e-mail client and the address book; hence, the attachment will be able to see data it was not supposed to (remember the attachment was restricted from ˜/.abook.); (2) substitution: the attachment will be able to alter messages exchanged between the e-mail client and the address book; (3) denial of service: the attachment will be able to exchange all messages with empty messages, and thus, effectively creating a Denial of Service attack; and (4) stack smashing: assuming either the e-mail client or the address book has a stack smashing vulnerability, the attachment will be able to execute arbitrary code with the privileges of the e-mail client or the address book, respectively; in this case it allows the attachment to escalate its privileges and circumvent the Umbrella restrictions on the network and ˜/.abook; however, it will still not be able to access /boot nor /etc.
It should be readily understood that the eavesdropping, substitution, and Denial of Service attacks are very similar, and they are in fact all man-in-the-middle attacks.
A system securing inter-process communication (IPC) based on trust includes a user quota mechanism to provide resource management of IPC's. A single user is allowed to allocate a fixed amount of objects less than a system maximum. A trusted IPC mechanism mediates access to IPC objects by employing signed executables signed by a key and containing a list of trusted keys. A trust relationship is used among a set of subjects connected to an IPC to determine whether communication can be carried out between processes. In order for the processes to communicate via an IPC, either they have to trust each other, or a kernel must trust one process and that process must also trust the other process.
Further areas of applicability will become apparent from the description provided herein. It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.
The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses.
The problems associated with the lack of secure IPC in standard operating systems can be summarized into two categories: lack of resource management and lack of access control on accessing IPC object. The first problem can cause Denial of Service (DoS) attacks while the other makes it possible for malicious processes to send malicious payloads to privileged processes. By sending the malicious payload, the process can potentially cause buffer overflow and escalate its permission to cause damage to the system.
To address these problems, a quota mechanism is first used to provide resource management of IPC's. This prevents a single subject from exhausting the resource pool. A single user is allowed to allocate a fixed amount of objects within the system maximum, but not reaching the maximum.
In addition, we propose a trusted IPC mechanism to mediate access to the IPC objects. Trusted IPC is based on signed executables which are signed by a key and contain a list of trusted keys. The trust relationship among the set of subjects that connected to an IPC determines if the communication can be carried out. In order for the processes to communicate via an IPC, either they have to trust each other, or the kernel must trust one process and that process must also trust the other process.
As discussed above, IPC security is a relatively unexplored area in computer security. However, IPC can be used as a means to attack the system by sending malicious payload to a privileged process or using DoS attacks. Using the solution proposed above, such vulnerabilities in the system can be remedied. The solution provides a resource management scheme as well as a fine-grained access control on system V IPC. The disclosed secure IPC scheme can also be used with some other Mandatory Access Control (MAC) scheme to provided additional security to the operating systems. Some embodiments can be implemented as a Linux Security Module for the Linux kernel. By doing so, no modification on the kernel source is needed. The design also causes minimal overhead.
One technique that can be employed in some embodiments is a use of a quota mechanism. For example, to prevent a single subject from depleting the resource pool of shared memory segments and thus preventing other subjects from creating shared memory segments, a quota mechanism can be used. In this case, a subject should only be allowed to create a predefined number of shared memory segments. This number must be smaller than the system wide number of shared memory segments, as defined by SHMMNI.
Regarding a subject's Quota, in current kernels, each user has a memory dependent, system wide, number of subjects which he is allowed to start, RLIMIT_NPROC. This system wide restriction only depends on the amount of memory installed. Each subject also has a maximum number of allowed shared memory segment, SHMSEG. This restriction is, however, not implemented in current kernels.
One might think that a quota mechanism should be based on RLIMIT_NPROC and SHMSEG, so that the following should hold:
SHMSEG×RLIMIT
—
NPROC<SHMMNI (1)
But this mechanism yields a problem in that a subject is able to create a shared memory segment and terminate without deleting the shared memory segment again. Therefore, the shared memory segment would still be in the system even though the subject is no longer alive. This result makes it possible for a malicious user to create as many shared memory segments on the system as the system wide limit defines. So Equation 1 cannot be used for implementing a safe quota mechanism. Instead, a limit per user should be used.
In some embodiments, an alternative to subject quota is user quota as illustrated in Equation 2. USER_SHM_MAX denotes the total number of shared memory segments a user is allowed to create.
USER_SHM_MAX<SHMMNI (2)
The quota mechanism is not a solution to all the problems described above. The reason it is only a partial solution is that non-malicious users could, through normal use, end up having used some of the system wide number of shared memory segments, and a malicious user or subject can, while still abiding the restriction mentioned earlier, take up the rest of the shared memory segments, preventing the other users from allocating any further shared memory segments.
To avoid this problem, we consider a solution which is shown in Equation 3. In this solution, the amount of shared memory segments each user can get, USER_SHM_MAX, depends on the total number of users in the system, #users. The drawback of this solution is, on systems with many users, each user will not get enough shared memory segments for the system to be usable. Therefore, the system administrator has to raise the total amount of shared memory segments SHMMNI as the number of users grows.
With Equation 3 the system administrator could also set #users to a number below the system wide number of users. This limitation implies that each user gets a fixed number of shared memory segments. Thus, the system administrator should not worry about users getting to few shared memory segments. However, this introduces a possibility to DoS the system.
It is also possible that each user in the system will get his own limit of shared memory segments, but this will put a lot of work on the system administrator. The reason for this is that the system administrator needs to know what applications each user uses and how many shared memory segments these applications uses.
While the description of quotas centered around shared memory segments, it can also be possible to implement this solution component for semaphores and message queues as well. The only application we found to crash when depleting the pool of available semaphores was ALSA, while we could find no applications that have problems caused by depleting the available resources of message queues. Furthermore, a quota mechanism is orthogonal to the existing security and access control mechanisms available, and they can be used in conjunction with the proposed quota mechanism.
Resource scheduling algorithms are another way implementing quotas. In these algorithms, a user may have to wait on objects being released by another user, before they are able to require the object. It should be noted, however, that it is not currently feasible to use resource scheduling algorithms on a modern platform. Users have expectations of responsive systems, and resource scheduling algorithms are most convenient on batch systems. Furthermore, resource scheduling makes it possible for a malicious user to carry out a DoS attack on the system by never releasing the objects which he has required.
To sum up, subject quota is not feasible at all as one user can carry out a DoS attack against the system. Therefore, a user quota can be employed such as a user quota from one of three categories: (1) a single user is able to allocate a number of objects below the system maximum but never allowed to allocate all objects, as shown in Equation 2; (2) a single user is able to create a fixed amount of objects as shown in Equation 3; or (3) a resource scheduling algorithm.
Turning now to
Access control can be described as the set of permissions a subject has on an object. A subject is an active entity and, in Unix, it is always a process. An object is a passive entity which typically is a file, IPC, etc. We define S to be the finite set of subjects in a system and O to be the finite set of objects. We denote the finite set of permissions by R. In general terms access control can be described with an access control matrix as in
Read is permission for reading the contents of an object, write is permission to alter an object, and the execute permission is used to indicate whether or not a subject may execute methods of the object.
In the access control matrix model, the state of the system is defined by a triple, (S, O, A), where A is the access control matrix, where A:S×O→P(R)
Thus A(s,o) specifies the set of permissions that a subject s has on an object o.
Even in small systems if the matrix in Table 1 becomes very large, it will require in the order of |S|•|O|•|R| bits to be represented. So for practical reasons, including performance, this matrix is not used directly for access control. What we need is a trade off between performance and the level of granularity in which we wish to represent the access control matrix.
To reduce the size of this matrix, the subjects can be grouped into a finite set of domains. In Unix, there are two standard set of domains: users, Dusers, and groups, Dgroups. Furthermore, there exists a special set with a domain containing all subjects. This domain is called the others domain, that is Dothers={dothers},wheredothers=S. All subjects, started by the user u, are executed in the domain of the user duεDusers The user domains are mutually disjoint and classify the subjects, thus du∩du′≠φu=u′ and ∪dεD
We define the function
userDomain:S→Dusers
as the function that returns userDomain(s)=d where dεDuserŝsεd, and the function
groupDomains:S→P(Dgroups)
as the function that returns groupDomains(s)={d|dεDgroupŝsεd}.
Tuning next to
In some embodiments, an administrator domain separation scheme is used as a solution component. As an example of how to use domain separation to ensure secure IPC, we propose a scheme which allows the system administrator to classify subjects into a range of domains, and objects into two types, trusted and untrusted.
Regarding domains, each domain D consists of an arbitrary number of subjects S. Which subjects belongs to which domains are controlled by the system administrator. Furthermore each subject is only allowed to be in one domain at a time. An example of such domains 104 and 106 is shown in
Regarding trusted and untrusted objects, the system administrator labels the objects in the system as either trusted or untrusted; the default should be untrusted. Referring to
Administrator domain separation offers a fine granularity. However, it relies heavily on how well the system administrator makes the domains and what objects are marked as trusted and untrusted. Furthermore, he has to choose which domains the objects should be used with, as shown in Table 2. Therefore, the burden placed on the system administrator is too large for this solution to work securely on some computer systems. Accordingly, some embodiments at least in part automatically classify domains and objects.
An additional or alternative approach to securing IPC in some embodiments can be to verify that executables are signed with a vendor key. A vendor key is an certificate that uniquely identifies the software vendor that created the executable, and which is chosen by the vendor typically such that it is in practice unforgeable. Upon execution, the vendor key is linked with the resulting subject, so the vendor key can always be found. Using this mechanism, we have identified four different strategies that can be used, which we describe next.
Turning to
With the kernel trusting specific vendor keys, there are two solutions that can be used. One possible solution is to only allow subjects signed with the same vendor key to communicate with each other, as shown in
Turning now to
Turning next to
By having the vendors decide whether or not the keys of other vendors should be trusted, the system administrator does not have to specify the relation between subjects and objects. Regular DAC takes care of basic access control as usual, with the extra access control in place that signing executables with vendor keys represents. Thus, if a vendor knows that his software depends on another vendor's software, this can be specified and will continue to work. This implies that he trusts the other vendor's software. A drawback, with all other solutions than the one where the kernel must trust the vendor keys, the system administrator cannot prevent subjects, signed with vendor keys that trust each other, from communicating together, if they want to.
Another solution component in some embodiments involves extending Umbrella restrictions. As discussed above, Umbrella uses PBAC for access control as a supplemental to DAC. This approach can also be taken when a solution to securing IPC needs to be found.
Like the Umbrella design, Umbrella extension requires that the programmers (or vendors) of the various software programs specify execute restrictions, i.e NFSR restrictions. The software vendor embeds these restrictions in a signature which is used to sign the binary.
Like with the original Umbrella layout, non-signed or non-trusted signed binaries can be sandboxed, in this case meaning they will get no access to IPC. By using the 32-bit restriction vector already present in Umbrella, this is a simple extension of the Umbrella access control scheme. As there are 3 System V IPC mechanisms, one could use a bit for each kind, or even make it even more fine grained, with a per IPC-channel flag, possibly combined with read/write access to these. Various embodiments can therefore have varying implementations as the access control can be made arbitrarily fine-grained.
This extended bitvector can restrict IPC access for a process, in the same way a process can restrict the children it forks, so that they are further restricted than it was. A useful scenario for this restriction process can be a mail client that is not restricted from IPC access, while opened attachments should be.
Summing up our discussion of applications using System V IPC, two categories of flaws with System V IPC were identified. Having discussed a number of possible solutions, we can now identify what solution components can be applied to each of the flaws. For example, no resource management per user or process can be addressed by the user quota mechanism. Also, low granularity of permissions can be addressed by domain separation, signed executables with vendor keys, and extending Umbrella restrictions.
Before going into the details of a particular design for implementing the above solutions, we first discuss some high-level considerations.
It is unfeasible to use any of the solutions outlined above to solve both problems, as they are quite different in nature. Instead, we choose to split the design into two parts, each focusing only on one of the problems.
For the problem of no resource management per user or subject, we found only one viable mechanism that could solve this, user quota. We outlined a number of strategies that could be used with this mechanism, and choose one in particular for this particular design. For the problem of low granularity of permissions, we found there to be several mechanisms that could be used. Likewise, we choose a particular solution component in view of its merits for this particular design.
Furthermore, using the design should, in some embodiments, require minimal work by the users. That is, software vendors are not expected to modify the source code of their software, however, they still have the primary responsibility for using the security mechanism. In addition to this, the system administrators are expected to do minimal work.
Before digging into the design itself, it is necessary to outline the assumptions on which the design is based. The design builds on top of these assumptions, thus leaving them out would have the design look incomplete or missing in some areas.
One type of assumption that we can make for some embodiments, is that root must be trusted. The root user has tremendous power over and capabilities on a system. Thus, most attempts to secure parts of the system against the root user will most likely fail. The root user can modify many parts of the system, including: (1) modify files on disk; (2) modify the memory; (3) modify the kernel; and (4) load and unload modules.
While root can be restricted from modifying files in certain areas of the disk, for instance with the help of Umbrella, root can merely access the raw device in/dev. Root can also modify the memory directly, for instance by loading modules that access and modifies the memory. Likewise, root can also modify the kernel and change its behaviour, so security mechanisms can be circumvented, and the behaviour of the kernel can be changed.
A way to prevent some of these attacks can be to load a module preventing the loading and unloading of modules. However, one needs to be root to load modules, and root can reboot the machine and thus circumvent it in this way. The above synopsis explains why root might need to be trusted when the Secure IPC module is used by itself. However, if another security mechanism is used to properly restrict the root user, this assumption is not needed. Such a mechanism will probably require dedicated hardware support.
Buffer overflow vulnerabilities present a serious threat to any system, and as can be seen from any vulnerability list, they are inevitable. The solution components discussed above are not aimed at preventing buffer overflow attacks.
Before describing the properties of our module, we need to describe the properties of the system security mechanism for System V IPC. We name the system properties for the operations create( ), destroy ( ), send ( ), receive( ), wait ( ), signal ( ), attach ( ), and detach ( ). To describe these functions, we need to introduce two helper functions first. We define owner: O→S∩{
Using our newly defined helper functions, we define the system properties that hold for functions, we define the system properties that hold for functions relating to message queues, semaphore sets, and shared memory segments respectively.
However, when defining the system properties, we need to emphasize the distinction between message queues, and the messages that they can hold. Similarly, we also need to emphasize the distinction between semaphore sets and semaphores that they can hold. Finally, for shared memory segments we need to make it clear that multiple subjects can have several mappings each of a shared memory segment.
Let Omq, Osma, and Oshm be mutually disjoint subsets of O that define the sets of message queue objects, semaphore set objects, and shared memory objects respectively.
We now define Omsg as the set of messages. The message queues are mutually disjoint and classify the messages, thus omq∩o′mq≠φomq=o′mq and ∪omqεOmqomq=Omsg.
We define Osem as the set of semaphores. The semaphore sets are mutually disjoint and classify the semaphores, thus osma∩o′sma≠φosma=o′sma and ∪osmaεOsma=Osem.
Three system constants help to control the sizes of message queues. MSGMNI defines the system wide maximum number of message queues that can be allocated. MSGMAX defines the system wide maximum size, in byte, for individual messages, while MSGMNB defines the maximum combined size, also in bytes, of all messages that can be queued simultaneously in a message queue.
o′mq =
o′mq ∈ O′mq
o′mq ∉ Omq
owner(o′mq)=s
size(omsg)≦ MSGMAX
Σo′
omsg
omsg ∉ omq
omsg ∈ O′msg
omsg ∉ Omsg
omsg
−o′mq)
omsg ∉ o′mq
omsg ∉ O′msg
owner(omq)=s
|O′msg|=|Omsq|−|omq|
O′msg = Omsg \omq
omq ∈ Omq
omq ∉ O′mq
As with message queues, semaphores sets has system constants that helps control them. SEMNI defines the system wide maximum number of semaphore sets that can be allocated. SEMVMX defines the maximum value that any semaphore in a semaphore set can have, SEMMNS defines the maximum number of semaphores on the system, while SEMMSL defines the maximum number of semaphores that can be in any semaphore set at one time. Upon creation of a semaphore set, the number of semaphore that the semaphore set must hold is specified.
|osma| ≦ SEMMSL
|osma|+|Osem| ≦ SEMMNS
∀osem ∈ osma:osem ≦ SEMVMX
|O′sem|=|Osem|+|o′sma|
o′sma ∈ O′sma
O′sem ∉ Osma
O′sem =Osem ∪osma
owner(o′sma)=s
osem ∈ osma
osem > 0
osem ∈ osma
osen < SEMVMX
|O′sem|=|Osem|−|osma|
O′sem = Osem\osma
osma ∈ Osma
osma ∉ O′sma
Similarly, shared memory segments also have system wide limits on a number of things. SHMNI defines the system wide maximum number of shared memory segments that can be allocated. SHMMAX and SHMMIN is the maximum and minimum size in bytes for a shared memory segment.
SHMMIN ≦ size(oshm) ≦ SHMMAX
o′shm ∈ O′shm
o′shm ∉ Oshm
owner(o′shm)=s
permissions(s,oshm)
oshm is mapped int o the address space of s
oshm is removed from the address space of s
attached(oshm)=0
oshm ∈ Oshm
oshm ∉ O′shm
These variants are weak, and they only guarantee that the system is consistent. There are no guarantees for a single user that he has enough resources.
Based on the discussion above regarding user quota, we found that a quota mechanism based on the number of users in the system is the best solution, i.e. Equation 3. However as the number of users grows in the system, each user will have very limited resources. This is especially true for message queues, as there is a system wide maximum of 16 message queues in the default setting. Therefore, in order to be sure that each user has some minimum number of objects available in the system, we have chosen constants which ensures this availability.
As we have chosen this solution, it should be possible for the system administrator to change the denominator constant in Equation 3. Then the system administrator can configure the security on his machine by setting this constant to his own wishes. If desired he can set the constants to the current number of users, and hence it is impossible to carry out a DoS attack against the system. The default values which we have chosen, for the system to be usable, and, at the same time, relatively secure, follows in the next subsections.
Regarding message queues, the system wide default maximum of message queues, MSGMNI, is 16, so we have chosen the denominator constant to be 4, as shown in Equation 4. This choice allows 4 message queues to be created by each user, and it ensures that at least 4 users are required to carry out a DoS attack against the system. The use of System V message queues seems to be very limited, so this seems like a good limit. The only program we have seen using them is Adobe Reader.
Regarding the semaphore set, the system wide default maximum of semaphore sets, SEMMNI, is 128, so we have chosen the denominator constant to be 16, as shown in Equation 5. This choice allows each user to create 8 semaphore sets. System V semaphore sets are, as message queues, rarely seen on our system, making this limit a suitable limit. Furthermore it ensures that at least 16 users are required to carry out a DoS attack against the system by creating all semaphore sets.
Regarding shared memory segments, the system wide default maximum of shared memory segments, SHMMNI, is 4096, so we have chosen the denominator constant to be 8, as shown in Equation 6. This choice allows each user to create 512 shared memory segments. The typical number of shared memory segments on our machines, under normal use, is around 20. However, when running Counter Strike under Wine, Wine uses approximately 300 shared memory segments. So, to be on the safe side, we have chosen to allow each user to create 512 shared memory segments. This choice also ensures that at least 8 users are required in order to carry out a DoS attack against the system, which is twice as many as attacking the message queues.
Regarding the quota module, the user quota mechanism will need to use six LSM hooks, two for shared memory segments, two for semaphore set, and two for message queues. These six hooks can be implemented as follows:
The number of allocated objects (shared memory segments, semaphore set, and message queues) should be stored per user. Unfortunately, the user struct structure does not have a security field usually used in LSM modules. Thus, the quota module must store the number of allocated resources. The UID of the subject is determined through the task_struct and user_struct with current->user->uid.
As the quota module should define default quotas for each object, it should also be possible to change these defaults at run-time using sysctl or the /proc interface. To provide this functionality the module should use register_sysctl_table( ) to register a sysctl table with the kernel. If the quota is lowered no user should lose already allocated objects.
Regarding trusted IPC, trusted IPC is based on signed executables. Each executable is signed with a vendor certificate. To provide trusted IPC, the signed executables are extended with a set of trusted vendor certificate fingerprints. This set is used to determine which subjects are allowed to communicate via IPC.
Regarding vendor certificates, for the purpose of providing unforgeable certificates, we have chosen to use X.509 certificates, a commonly used standard in certificates. Among other things, it is used for signing software for use on a multitude of systems, including mobile platforms. We define C to be the set of all X.509 certificates.
As X.509 certificates can have varying sizes due to, among other factors, key size, we have chosen to use the fingerprint of the certificate. The fingerprint of a certificate can be obtained by running it through a hash function. The hash function we have selected is the SHA-1 secure hash function. This yields 20 bytes large fingerprints for each certificate. We thus have F which is the set of all fingerprints, defined as F={SHA−1(c)|cεC}.
In general cA is the X.509 certificate of vendor A, and fA is the fingerprint of cA, that is aA=SHA−1(cA).
Regarding trust, before defining the core concept of our trusted IPC, we need to get some basic definitions in place first.
First we define vendor: S→F as the function that returns the vendor certificate fingerprint of the signed executable. Next, we define trustedVendors: S→P(F) as the function that returns the set of fingerprints trusted by the signed executable associated with subject s. If the executable associated with s has no executable vendor metadata, then vendor(s)=NULL and trustedVendors(s)={NULL}. Signed executables cannot trust the NULL vendor key.
As the solution component mentioned above had a notion of the kernel trusting vendor keys, we need to define these two sets as well. Tkernel⊂F is the set of trusted vendor certificate fingerprints, and Ukernel⊂F is the set of explicitly untrusted vendor certificate fingerprints. Note that Ukernel=
In our solution there exist two possibilities for subjects s1 and s2 to communicate, either the vendors of s1 and s2 must trust each other, or the kernel must trust the vendor of s1 and s1 must trust s2 to communicate. The exact definition of when subjects are allowed to communicate follows.
Definition 1. Given Tkernel,Ukernel we define the binary relation trusts ⊂S×S such that s1 trusts s2 iff vendor(s2)∉Ukernel and one of the following conditions are satisfied
1. vendor(s2)εtrusted(s1)
2. vendor(s2)εTkernel
Using Definition 1, we can now define mutual trust.
Turning now to
Definitions 1, 2, and 3 form the main part of the secure IPC mechanism. That two subjects are allowed to communicate when they trust each other is reasonable. However, also allowed is for the kernel to trust vendor certificate fingerprints, found in Tkernel. Subjects associated with executables signed with vendor certificates whose fingerprint is in Tkernel, are in turn allowed to communicate with all other subjects which they trust. Thus it does not matter if other subjects trusts the subjects in Tkernel or not.
For example, referring to
If the X server 150 is not trusted by the kernel, the other applications (e.g., Opera) could still communicate with the X server 150, if Opera 152 is trusted by the kernel and Opera 152 trusts the X server 150. This is probably the smartest solution for the X server 150, because of the problem mentioned above.
Another example that this solution is a good solution, is that it minimizes the work that the system administrator has to do, to setup the system, compared to the Administrator Domain Separation discussed above. In fact, in the best case where all applications need to trust each other, the administrator does not have to do anything.
Regarding vendors, the executables can be signed with a vendor certificate specifying the software vendor which developed the software. The certificate vendor could be anyone, ranging from large corporations like Microsoft™ and Sun™, to one-man software vendors. However, a corporation like Microsoft™ should not just have one vendor certificate for the entire corporation. Instead, it would be desirable to split it into smaller vendor certificates like “Microsoft™ Office™ Team”, “Microsoft™ Windows™ Standard Application Team”, “Microsoft™ Internet Explorer™ Team”, etc. Then it is not necessary to trust the entire Microsoft™ corporation, but only parts hereof.
However it could sometimes also be desirable to trust large vendors like GNOME™. This is the case when the system administrator wishes that all GNOME™ applications should be able to use IPC. All that he administrator has to do in this case is to make the kernel trust the GNOME™vendor certificate fingerprint.
The drawback is that the system administrator is bound by the granularity of the vendor certificates. As an example, if Microsoft™ only publishes one certificate for the entire corporation, then one must trust all applications from Microsoft™ even though one only wants to trust a part of Microsoft's™ software suite, like Office™.
Regarding trusted executables, in order to provide trusted IPC, the trust has to begin with the executables themselves. The executables need to be trusted, or else the system cannot know that the executable is from the vendor it says, nor that it trusts the vendor certificates it specifies. In the following, for brevity, we refer to the vendor certificate fingerprint of an executable, and the list of vendor certificate fingerprints that an executable trusts, as executable vendor metadata. Depending on how one selects to distribute the executable vendor metadata, different problems arise.
Regarding storing and distributing executable vendor metadata, for some embodiments, one of the central elements in secure IPC is the integrity of the executables and the vendor certificate fingerprints the executables trust. In some embodiments, the requirements identified for secure IPC are: (1) it should be possible to uniquely identify the vendor of the executable; (2) it should be possible to identify the vendor certificate fingerprints which the executable trusts; and executable vendor metadata needs a persistent and secure storage.
In the process of investigating solutions for this problem, two possible solutions are discussed below. Referring to
The advantage of using this solution is that the executable vendor metadata always stays together with the executable, and it is impossible to alter the executable. This advantage is due to the fact that the executable is hashed and signed with the private certificate of the vendor. However, this solution imposes overhead to the system as the signature has to be checked each time the executable is executed. Furthermore, the executable has to be changed as the executable vendor metadata and hash needs to be appended. When appending this metadata and hash to the end of the executable, there must be a tag which makes it easy to separate the appended executable vendor metadata and hash from the original executable. This tag could be a problem regarding scripts, since the tag must be enclosed in something that makes all scripting languages ignore it.
The second solution is to use extended attributes. Extended attributes are name:value pairs associated permanently with files and directories. The executable vendor metadata is stored in the security attribute namespace. When no security module is loaded, the write access is limited to subjects that have the CAP_SYS_ADMIN capability. If a security module is loaded, the read and write access permissions to security attributes depend on the policy implemented by the security module.
With this second solution, the executable vendor metadata has to be distributed with the executable, as a package. This packaging can be performed by a package manager used by a target Linux distribution. A package is a file in a distribution specific format. It contains the files for a particular application you want to install, which can be several executables, libraries and other files. Known package managers are dpkg, rpm, and portage. With portage, the packages are small shell scripts, and all that is required is making of special packages that install the executable vendor metadata along with the executable itself. While not entirely the same with dpkg, packages handled by this package manager include scripts, which dpkg calls during the installation of a package, so much the same applies here. The same goes for rpm packages. Upon installing the package, the package manager copies the executable vendor metadata to the file system extended attributes. The integrity of the package needs to be verified so that it is known that the package has not been compromised. The package is hashed and then signed with the private certificate of the vendor. To verify the integrity of the package the public certificate of the vendor is needed.
The advantage of this second solution compared to the first solution is that the signature only needs to be checked when the package is installed on the system. As a result, the signature does not need to be stored. Furthermore, no changes to the executable are required and, regarding scripts, no changes are required. The disadvantage of this solution is that the file system needs to support extended attributes. When the extended attributes are needed, they have to be fetched from the file system; this fetching imposes overhead.
For some embodiments, the latter solution is selected for secure IPC, the reason being that it is not necessary to verify the signature every time the executable is executed. Furthermore, it also works with scripts, since there is no need to append anything to the executable. Lastly, the extended attributes are intended for storing data, such as our executable vendor metadata.
Turning our attention now to attacks, using per subject security mechanisms in Unix introduces some vulnerabilities normally not present. This introduction is due to the fact that almost any access control is performed per user. A mechanism with similar vulnerabilities to our trusted IPC solution is the set-user-ID/set-group-ID (setuid/setgid) mechanism. This mechanism allows a subject to run with a different user ID/group ID than its parent, based on the ownership of the corresponding executable. The known vulnerabilities against setuid/setgid include: (1) LD_* environment variables; (2) buffer overflows; and (3) insecure file creation.
Regarding LD_* environment variables, the environment variable LD_LIBRARY_PATH is a list of directories in which the dynamic linker/loader searches for shared libraries, these directories are first searched before the standard search directories are searched. The environment variable LD_PRELOAD is a list of additional shared ELF libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries.
These two environment variables could be a security problem for setuid/setgid executables, as it could be possible to set one of these environment variables to point to some malicious shared libraries. It would then be possible to execute arbitrary code with the permission of another user, such as root. This problem is solved by the dynamic linker/loader as it ignores the LD_LIBRARY_PATH variable if the executable is setuid/setgid. For the LD_PRELOAD variable the following applies: For setuid/setgid ELF binaries, only libraries in the standard search directories that are also setuid will be loaded. For other LD_* variables a description can be found in.
A similar problem with shared libraries exists in trusted IPC. If a subject is authorized to use a trusted IPC object, but LD_LIBRARY_PATH or LD_PRELOAD points to some malicious shared libraries, then the authorized subject will use these libraries. This is due to the fact that the dynamic linker/loader will use the environment variables LD_LIBRARY_PATH and LD_PRELOAD, as the subject not necessarily is setuid/setgid. It would then be possible to get unauthorized access to a trusted IPC object through the shared libraries.
The hooks file_mmap( ) and bprm_secureexec( ) can be used to solve the problem. The first hook is used to check permissions for a mmap operation, that is, map files or devices into memory. It will then be possible to only allow trusted libraries to be mapped into the memory space of an authorized subject.
The latter hook indicates whether libc should enable secure mode. If this is enabled then it is impossible to specify what shared libraries to use through the environment variables LD_LIBRARY_PATH or LD_PRELOAD. Then for every authorized subject the secure mode will be enabled. If a user uses his own dynamic linker/loader, which ignores the secure mode to start an authorized subject, by giving the executable as an argument, then it is not a problem, as it is the dynamic linker/loader that will be seen as the executable by the kernel. The subject will for this reason not get access to a trusted IPC object. For some embodiments, we use the latter hook, as it is only the executable that need to have vendor metadata associated and not also the libraries that the executable uses.
Regarding buffer overflows, if a setuid/setgid executable has a buffer overflow vulnerability it would be possible to run arbitrary code with the permission of another user. Trusted IPC also has a problem with buffer overflows as it would be possible to get unauthorized access to a trusted IPC object. We are not trying to prevent buffer overflows with trusted IPC as buffer overflows are out of the scope of an IPC security mechanism.
Regarding insecure file creation, insecure file creation can occur, for instance, when a subject creates a temporary file in /tmp. This file can be exploited via symlink attacks to overwrite arbitrary files with the privileges of the user running the subject. As trusted IPC will not change the access to files, we will not do anything about this problem in some embodiments.
Regarding some embodiments of the trusted IPC module, the Trusted IPC mechanism will need to use the following LSM hooks. These hooks should be implemented as follows:
With various solution components identified, and a particular combination of certain ones of these components selected during a design of a secure IPC module, it is now possible to describe a particular implementation as an embodiment of the secure IPC module. In this embodiment, and referring particularly to
Regarding the quota mechanism, the quota mechanism is implemented in the file quota.c, and is implemented as described above. The struct user_security, which can be seen in the computer code presented below, keeps track of the users in the system, and a hash table is used to quickly find a user security with uid as hash key.
The first time a user creates an IPC object a new user_security is allocated, and when the user has deleted all the IPC objects the user_security is deallocated.
The security_struct, presented in computer code below, keeps track of how many messages queues, semaphore sets, and shared memory segments a user has allocated.
The six hooks, as described above, are implemented as follows:
Turning now to
IPC object has a list of vendor metadata from processes which has been attached to the object. Note that the vendor metadata from a process will not be removed when the process is terminated. A hash table is used to quickly find an IPC object and it is the ipc field that is used as hash key.
The xattr_struct 304, shown in computer code below, is used to hold executable vendor metadata. The vendor array is used to store the vendor key of the process. The vendor keys the process trusts are stored in the trusts array, and count reflects the number of vendor keys stored in the trusts array. The count connected field indicates when the xattr_struct can be deallocated. When a xattr_struct is allocated the field is initialized to one, and is incremented by one every time the process either creates a new IPC object or attaches to an already existing IPC object. The field is decremented by one when the process terminates or when an IPC object which the process has been attached to is destroyed.
The last struct is the process_struct 306 provided in computer code below. This struct is used to find the vendor metadata for the current process. A hash table is used to find the process_struct for the current process, and the tgid is used as hash key. *xattr points at the process vendor metadata and tgid is used to identify the process. The tgid (thread group id) is used and not pid (process id), because the tgid is the same for all threads in a multi threaded program, whereas the pid is unique for all threads.
Regarding the permission check, we have divided the implementation of Definition 3 into three functions, trusts( ), kerneltrust( ), and check_definition( ). The functions are in alloc_ipc.c. The vendor keys, which the administrator does not trust, are stored in /etc/sipc/untrusted, and the vendor keys he does trust are stored in /etc/sipc/trusted. Note that the vendor keys are loaded into the hash tables kernel_untrusted and kernel_trusted when the module is loaded. This happens in the sipc_init( ) function in secure-ipc.c. The function trusts( ) checks the condition vendor(s1)εtrusted(s2)̂vendor(s2)εtrusted(s1).
Regarding trust, the trusts( ) function is shown in computer code below. It takes two xattr_struct structs as parameters and returns 1 if the vendors in these structs trust each other, otherwise it returns 0.
vendor(s2) ∈ trusted(s1)
Lines 6-7 check if the same vendor key is in both structs and returns 1 if they are, as vendor(s)εtrusted(s). Definition 2 states that the processes must trust each other. One way for the processes to trust each other is for them to satisfy Definition 1 condition 2. This condition is tested in lines 9-29, so both vendor(s1) E trusted(s2), and that vendor(s2)εtrusted(s1). If they are not, 0 is returned in lines 18 and 29 respectively. If both checks pass, 1 is returned, and both vendors trust each other.
Regarding kernel trust, the function kerneltrust( ) checks the condition:
vendor(s2 ) ∈ Tkernel
vendor(s2 ) ∈ trusted(s1)
vendor(s1 ) ∈ Tkernel
vendor(s1 ), vendor(s2) ∈ Tkernel
Part of the function is shown below. The kerneltrust( ) function takes two xattr_struct structs as parameters, and an integer that indicates whether the second xattr_struct struct is trusted by the kernel. The function returns 1, if the vendors trust each other, otherwise it returns 0.
In lines 4-9 the function checks if vendor(s1)εtrusted(s2)̂vendor(s2)εTkernel. If this is not the case, it checks if vendor(s2)εtrusted(s1)̂vendor(s1)εTkernel. It does this by first performing a lookup in the kernel_trusted hash table for the vendor key stored in s—1. If the vendor key is found in the hash table, it continues to check if the vendor of s—1 trusts the vendor of s—2, if it does, the value 1 is returned. This happens in lines 11-23.
Finally we check to see if vendor(s1),vendor(s2)εTkernel. This is done in lines 14-15. It simply checks if the vendor keys stored in s—1 and s—2 are in the kernel_trusted hash table and returns 1, if they are.
The function check_definition ( ) is the function that decides, if access can be granted to an IPC object with help from the functions trusts (and kerneltrust( ). Part of the function can be seen below. It takes two parameters, an xattar_struct struct from the process that wishes to access the IPC object and a list of xattr_struct structs that have already accessed the IPC object. It returns −1, if permission is not granted, 0 if permission is granted, and 1 if permission is granted and an identical xattr_struct struct already exists in the list of xattr_struct structs that has accessed the IPC object previously.
In lines 4-8 the function checks if vendor(s1)ε∪kernel. It is done by looking for the vendor key of the process in the hash table kernel_untrusted. The process will be denied access to an IPC object, if the vendor is untrusted.
The check vendor(s1)εTkernel is done in lines 9-15, by looking for the vendor key of the process in the hash table kernel_trusted, and the result of this check is used in the function kerneltrust( ).
Lines 16-26 check that each of the vendors, in the list of xattr_struct structs who have accessed the IPC object, trusts the vendor of the process that wishes to access the IPC object. Also, it is checked that the vendor of the process trying to access the IPC objects trusts all vendors of processes that have accessed the same IPC object. This is done by first checking if an identical xattr_struct struct has already accessed the IPC object, in which case permission is granted.
If permission is not granted, kerneltrust( ) is called, and if it returns 0 trusts ( ) is called. If the vendors does not trust each other then permission cannot be granted, and −1 is returned in line 25.
If all the vendors trusts each other permission is granted in line 27.
Note that when we compare two xattr_struct struct in lines 18-20, we do not compare the count_connected field. The reason for this is that count_connected is only used to indicate when the xattr_struct struct can be deallocated, and do not have any effect on the vendor keys stored in the xattr_struct struct. If we compare the count_connected field, then two xattr_struct struct with identical vendor keys could be in the list of xattr_struct struct that had accessed the IPC object, but that will not make any difference in deciding whether access should be granted to the IPC object.
Regarding hooks, the hooks for Trusted IPC are implemented in the file alloc_ipc.c except the hooks bprm_secureexec( ) and task_free_security( ) which are implemented in the file load_exec.c. The hooks are implemented as follows:
Now that an implementation has been provided, we turn our attention to discussing some alternative and additional embodiments of the module.
Some embodiments can have executable vendor metadata. For example, two or more identical sets of executable vendor metadata can be stored in memory, e.g. if the same executable is launched more than once. The implementation described above has no checks for this. Preventing executable vendor metadata from being stored more than once would save memory, but will incur runtime overhead every time a process is started. A decision about implementing such a check can be based on whether time or memory are more valuable.
Regarding kernel trust, in the implementation described above, the files /etc/sipc/trusted and /etc/sipc/untrusted are only read when the module is loaded; it is not possible to reload the files when the module has been loaded. In some embodiments, it is possible for the system administrator to change which keys are trusted and untrusted, while the module is loaded. The resulting advantage is that it is possible to alter which vendors are trusted or not, without having to reload the module.
This ability is obviously a disadvantage as the system is left in an insecure state in between the unloading and loading of the module. However if it is possible to alter the trusted and untrusted vendors when the module is loaded, it raises a number of questions:
We do not believe that the module should do any of the above actions if it is possible to alter the files when the module is loaded. Actions one and four are not feasible as subjects risk failing when we detach them from the IPC object. Actions two and three are not without problems either, because we do not know if the vendors asking for access earlier still want access now.
