Hybrid SELinux / SharePoint Environment
Before I get into how to architect a proper MAC environment using SELinux, there is one major misconception I would like to get out of the way. SELinux is not complicated. I am primarily a C# developer and I didn’t find it that complicated, and my talents with Linux technologies are less than ideal. If you find Linux as a product complicated, SELinux will appear daunting, you will solely be adding insult to injury, but in general, the security concepts that SELinux supplements the Linux platform with are in general very easy to understand once the general concepts of the platform are tackled.
The purpose behind implementing a hybrid Linux solution with SharePoint is to bring enhanced kernel level security as that provided by SELinux to the most comprehensive collaboration and communications solution, coupling several layers of technology. The overall concept can be seen in the diagram below. In aggregate, we will establish two separate SharePoint environments, one that is a general environment, and another that is slated for confidential SharePoint centric information. Although there are two separate environments, VMware will allow us to leverage a singular piece of hardware. The general environment will still be able to contact public networks via the internet, whereas the confidential environment since it is meant for sheltered content. Keeping the two environment separate allows the two environments to be truly segregated in order to prevent unauthorized data migration as well as malware propagation from various untrusted sources.
The purpose of using a Hybrid SELinux/ SharePoint solution is to build up a multi-level security SharePoint capable environment. Multi-Level Security is an important concept for several flavors of industry, but most importantly those that exist within the federal government. The concept of Multi-Level Security is built upon the model that were firstly built on the Bell-LaPueda model, which in general, simply laid the foundation for read/write access across logical boundaries. We can see the concept of multi-level security in the below diagram:
We can see that there are two main actions. The first of those are the requestors, those that are querying to access a specific asset that exists on the MOSS server at a high level, which is noted as the Sigma to keep the context of the diagram somewhat bland for applicability purposes. SharePoint has the capability to store user information, as well as access controls to the backend databases, and therefore provides the medium between the actual user requests and the serving of the requested object. The second is the receiver, which are the low level of requestors that can have an arbitrary numeric as well. Hence, we have High systems denoted as S, and low systems that are denoted as R. The communication between the two is all mitigated with SharePoint as the general medium between the two objects.
As with any security model, there are two important concepts that are typical involved, the object, or the asset that a requesting party wants access to, and the subject, which is the querying party for that specific asset. Regardless of how the request is routed, these two concepts are a constant within any security model proof.
The overall architecture of SELinux is composed of the kernel, which makes the decisions regarding allowed and denied access, the SELinux Shared Library, which provides the overall support library for process execution for SElinux, and the SELinux Security Policy, which provides the intelligent decision making process.
One can sum up the packages that are included with SELinux as:
- The standard Linux kernel
- The Linux Security Module (LSM) provided by SELinux
- SELinux kernel modules that provide native hookinh
- Kernel patches for SELinux that need to be applied (depending on distro)
- SELinux management programs (those used to build policy files etc.)
- A distribution that includes policy files (others can be easily created in policy language)
- Some variations on the standard linux programs. This is to make these applications aware of the SELinux existence. For example, mkdir will be replaced with a SE enhanced version provided by SELinux.
The architecture of a hybrid SharePoint /SELinux environment is depicated in the diagram below. There are several benefits that are gained from the separation of the two SharePoint environments.
- Information cannot be leaked from the confidential SharePoint environment to the general SharePoint environment (staying in line with MLS BP model standards that are common within federal and highly regulated sectors)
- Viruses and malware can’t be passed from the general environment to the confidential environment increasing availability and mitigating possible risk to the highly sensitive information stored on the confidential SharePoint environment
- The general environment can only pass information that meant certain sensitivity label requirements from the general environment to the confidential environment
- Subjects can only access the internet from the general environment, not from the confidential environment, preventing possible information exposure
What is SELinux?
SELinux is a NSA developed Linux distribution that implements finely tuned Mandatory Access Controls based on the Flask architecture which integrates directly into the Linux kernel. Because of its direct hooks into the kernel, it allows it the option of implementing system wide, administrator managed policies that will affect all objects that exist in the base operating system that SharePoint runs on. The security objects are based on the concept of sensitivity labels, which will deem whether the content fulfills a certain category of information, be it secret, top-secret, classified, unclassified, or any number of other labels. The overall purpose of SELinux is to minimize the possible breaches that could occur within a SharePoint environment.
SELinux provides a good parent environment for SharePoint when coupled with virtual machine technology because the security of SharePoint needs to not only be focused on the web application itself, but on the security basis of the root operating system. Providing administrative control using the SELinux policies which hook directly into the root kernel provides the highest level of security since otherwise it will be up to the users of what content would reside where, as opposed to en environmental, administrative decision that can assimilate organizational access policies that facilitate the use of sensitivity labels.
SELinux isn’t a separate OS, and can be used across multiple Linux platforms as a hooked architecture. It is called a Linux Security Module (LSM) in that it rides on top of an independent OS and inserts instructions into a kernel. As various processes are executed on the server, it can be checked against the SELinux policy database which can choose to execute or halt a process.
Within SELinux, there are two major types of objects that exist, transient and persistent objects. Transient objects are simply objects that exist within the system that are destructed once their purpose has been served. Therefore, they never are giving a persistent SID (Security Index) from a memory pool. Persistent objects are those that do have a persistent SID. The Security Index plays a vital role in the decision making process, the tuple of objects and subjects use it during the execution.
The permissions within SELinux are based on a tuple architecture that is similar to the architecture that we see with pluggable providers in SharePoint, there is an identity and a role that exists. For each subject and object, there is an identity that exists, regardless of context of either asset. Linux typically stores passwords at /etc/password, however in SELinux each subject has its own database promoting a powerful level of segregation that is highly administratively controlled. In this, the users are also assigned roles, which define the actions that a user can take, the actions that are consider legal by the system. In each role, there are privileges and actions assigned to it, which allows a many to many relationship to exist between users and roles, there can be multiple roles, that contain multiple users, or its singular counterpart.
SELinux has several roles that you get by default.
- staff_r – users permitted for sysadm_r
- sysadm_r – users permitted for system administrators
- system_r – System processing roles
- user_r – users role
A History of Flask
The Flask history is rich within the federal sector. Flask was originally developed in 1992 through 1993 by the National Security Agency and Secure Computing Corporation when design was kicked off for a controllable access control system that combined Distributed Trusted Mach and LOCK, which evolved into Distributed Trusted Operating System (DTOS), which spawned a viable system that become applicable for security sensitive military and university research projects. This development was later rolled into the Fluke project that was underway from the University of Utah, when the NSA and SCC bonded the DTOS project into Fluke, combining their concept of security policies the fluke OS, which in turn after some development spawn the SELinux Project.
Flask is a crucial portion of the overall execution because it allows a distinctive separation of the controlled, security policies, to the enforcement logic. There are two major components that build up the flask architecture, the security server which provides that enforcement logic that builds out the relevant security decisions, and the object manager that governs the attributes of security for objects, and feeds off the decision trees that are sponsored by the security server. These all build up to the concept of Mandatory Access Control which allow transparent policy enforcement when defining the default security behavior.
Mandatory Access Controls
In several articles on this site, the concept of Mandatory Access Control is heavily discussed, since it plays such a crucial role in systems that deal with environments that hold both highly sensitive information, as well as information that is fit for public consumption. For brevity, Mandatory Access Control spawns to main concepts, that of subjects, and objects. A subject is simply a user or system that would access an object, which is simply something that exists, such as a document, file, information, or process. For each subject that exists, they are grouped into domains. These domains are classifications, such as secure, or unsecure, classified, or unclassified, or sensitive, and insensitive. The domains can be any number of ambiguous terms that are typically only specific based on industry, however common within the federal sector as classified and unclassified. For each object, there is an assigned type, and like each subject is assigned a domain, each object is assigned a type that will say what domain of user can have access to it.
In this, all files that SharePoint will hold are still firstly bound to a Windows Identity, or custom user identity that is populated from a custom membership provider. The concept of item level security although will exist for each particular SharePoint instance. It is important to realize however that there is not one singular SharePoint instance however, there is one that is dedicated to unclassified, general information, and another dedicated to classified, sensitive information. Leveraging MAC, within a classified SharePoint environment, there is the option for a subject to access the classified file, however the sensitivity label will prevent users that don’t meet the type to not open or transfer the file. This is very different from typically OS permissions, such as in UNIX or Windows, where the permissions are instead controlled by the owner of the file.
Decision Trees In SELinux
Decision trees in SELinux are built on the concept of security attributes, which were discussed previously. The various security attributes are merged to generate the global security context for the aggregate SharePoint environment. As we have talked about thus far, there are three main properties that build out the security attribute, the user, the user’s role, and the type. When various server processes are executed on the server, a context will be assigned to it. This context is feed from the security server, and will define such things as what security rules should be applied, what process spawned the child processes, and what subject (userID) tripped the process, whether it is a system or a tangible user. In this, the security server is very important to the decision making process during the execution of SELinux controlled process. This may seem to be a lengthy process, however there is a cache mechanism that is implemented in order to circumvent this otherwise cumbersome process by using an Access Vector Cache (AVG). If the security context does change, then the AVC will be slated as invalid, and a new cache entry will be generated.
There are several flavors and types of SELinux that are available for downloading depending on your environmental requirements (Gentoo, Debian, SuSE, etc.), all available here http://selinux.sourceforge.net/distros/ . Here is a list of the available distributions: