Hybrid SharePoint With SElinux Theory of Operation

Multi-Level Security Domain SharePoint

To promote apposite security implementation of security centric SharePoint environments (those which are focused on sheltered implementations) it is necessary to build an environment that implements multi-security domain access along with diverse security mechanisms that will provide a basis to procure the concepts provided in the CIA triad. Like researched in previous articles, there is an overall concept in computing security architecture known as the CIA triad which procures the subjects of Confidentiality, Integrity, and Availability (CIA) which afford the underlying basis for security conceptualization. Within an environment that promotes multi-level security domain access, there are other minor objectives that are introduced to build the aggregate CIA concepts since the environment becomes more finely tuned and the overall level of security system awareness becomes more robust and detailed. Throughout this article, I will present the Theory of Operation of building a such environment, and the considerations and implementation concerns that are presented with such a solution.

Introduction to the Theory of Operation

The Theory of Operation behind a Hybrid SELinux / SharePoint scheme provides the basis for procuring a proper implementation that conforms to the CIA triad while providing the mechanisms that are necessary for data carry over, while maintaining globally maintainable security policies that conform to a classification (an environment that inherits sensitivity labels) based environmental standards. This initial introduction to the Theory of Operation presents solely the basis for developing the environment, and in subsequent sections the exact compilation and deployment will be presented and examined. Several portions of the Theory of Operation may prove theoretical and touch on concepts not immediately available within an arbitrary technology; however the aggregate presentation will procure a concrete, usable solution.

Introduction to Machine Virtualization, and the need for Machine Virtualization

Virtual machines are increasingly common throughout enterprise environments for obvious hardware consolidation benefits; however, one of the most overlooked benefits that virtual machines can provide is that of security considerations. The Hybrid environment presented is excursively based on such a concept, since virtualization will build the option to use Windows Server 2003 on SElinux hooked Redhat / Fedora Core 3 kernel.

The most obvious benefit that is received when implementing virtual machines is that of complete data isolation, since, in essence, all data stored within an arbitrary virtual machine is considered to be segregated from the other environmental assets unless otherwise bound. The isolation also extends out to services and processes on the machine, in that there can be specified running of the services that are contained, in which services can be manipulated at runtime without affecting other various services.

Whereas the most secure environments are those whose domains are segregated because of the physical separation of machines, these are also the most difficult to transverse data through. In essence, when separating the machines physically, we are establishing multiple security zones within an environment. In order to achieve this otherwise, it would require separate processing mechanisms for each domain. Using virtual machines however, a SharePoint administrator can instead setup various security zones based on requirements that exist on the same hardware, whereas various domain security zones can exist in complete isolation, although procured on the same physical machine. For each security zone that is implemented, a separate security policy can and should be implemented which provides overall control in relation to the security domain. The security policies that are implemented are structured around the concept of Mandatory Access Control principles, so that they are not only applied for the objects that exist on a specific virtual machine, but the processes that exist within a specific virtual machine. By implementing this concept of MAC, one can be assured that between two various SharePoint environments, data cannot be transverse between the two, unless stated within the MAC based global security policy.

Although this all sounds great for federal and highly regulated enterprise environments, a rather rudimentary, be at although important, question remains. The concept of MAC was invented a very long time ago, why hasn’t it been implemented in rudimentary Windows based environment previously? There are two major answers to this question. The first is that direct hooks that would otherwise override the DAC controls that predominantly dominate the Windows security architecture are forbidden and would be a legal problem (discussed more exhaustively in a subsequent section), and secondly, MAC can become increasingly difficult to implement and maintain, and security policies tend to can be complex for an administrator to understand with granular training in such.

SELinux, although considered somewhat complicated, can alleviate a majority of these issues, particularly with the use of virtual technology. This is the reason for this particular choice of technology. In a separate article, I will detail how another technology, AppArmor, can be used for somewhat of the same purpose.

Carrying Over the CIA Triad Concepts

The three subjects from the CIA triad are carried over when leveraging a MAC worthy technology such as SELinux. These are availability, where the SharePoint assets are accessible to the requesting parties in a timely manner, confidentiality where the information that is stored in SharePoint is available only to the properly authenticated SharePoint users, and integrity where SharePoint information can only be modified or altered by entities that are authorized are all still relevant goals to achieve. However within a multi-security environment a few more minor security concepts introduced, namely the following three, which although relate to the CIA triad, deserve individual mention:

Authentication ensuring that subjects are appropriately identified by the collaboration system and that their passed identity is not a fictious one

Authorization ensuring that subjects are authorized to perform their relevant requested actions on the system and that they have proper access rights to do so

Domain Separation For proper SharePoint information assurance, it is necessary to package SharePoint data into various domains that procure specific levels of security and assurance. Preventing leaking of information across these security domains is a very important concept to ensure, and all information that transverses between domains be scrubbed by appropriate mechanisms.

What Types of Exploitations Can Be Mitigated?

There are several types of exploitations that can be mitigated when implementing a multi-level domain access architecture. The first of these is a global privilege escalation, by which a user will execute an application that will run under privileges that it normally wouldn’t have the option of running under. The second is the Assumption of Atomicity, in which a security check is basically bypassed. Typically this is during a sliding window when the check is executed, when the exploit is called directly during that sliding window down time which would otherwise cause that check to detect the user interaction. Programs can also be trusting of the execution environment, so that all children application of a parent application will immediately inherit the permissions of their parent. These programs could also be accessing resources that are leveraging shared libraries which could in turn infect users across a variety of parent applications.

As stated in several other articles, the main purpose in a multi-level security environment is to procure an environment where there can be properly structured Mandatory Access Control.

Why Mandatory Access Control and The Mandatory Access Control Theory of Operation

The entire theory of operation for using a hybrid environment of SharePoint and SELinux is based upon the concept of procuring an environment that allows the birthing of Mandatory Access Control. The reason that Mandatory Access Control is at the heart of the theory of operation for the SELinux / SharePoint architecture is that conventional methods of DAC have proved to provide lower levels of unusable levels of object security. For a collaborative environment to be truly secure, it is necessary for it instead to have the option of not binding an identity to a system object but in effect provide segregation of various pieces of information in order to highlight the Confidentiality present within the CIA triad. This in turn would al the birthing of more effective measures that would promote the concept of integrity of the overall, aggregate system. The failure in DAC that ensues is due to the fact that DAC allows system decisions to be executed with the presence of simply an identity of a user, as well as the ownership of arbitrary files and objects that exist within the system. The concept of DAC is easily built up conceptually within the Windows Server architecture, the root account, typically a system account which has in essence the permissions that are granted to the local administrators security group, owns the system, whereas there are subsequent child users that can mimic this role, as well as sub users that are assigned arbitrarily to other roles within the server system. This is a faulty concept in that it allows various users to execute an N number of arbitrary programs and applications that might prove malicious to the collaboration environment, as well as it empowers various users (which can become somewhat impossible to track the granted permissions) power to give an N number of users access to the environment, and in this access to the objects and files that are housed within that system and all subsequent chains. Beyond this, there can always exist a power user, or a malicious root user, whom may corrupt a system needlessly for whatever intents and purposes. The concept of CAS (Code Access Security) also begins to take a small role because in code access security where are examining what foreign assemblies a specific binary may touch during run time execution, and within a DAC sponsored environment it is typical that the execution of relevant processes will simply inherit the permissions that are sponsored by the user (or, in effect, how the arbitrary process is tripped). This leads to inherit flaws within the environment since once the malicious process is tripped it can manipulate other objects permissions, its own permissions, or other subjects within the system’s permissions. This can easily lead to corruption of permissions within the environment, and in effect circumvent the granular permissions that are typically set within a network regarding the user of processes and objects. The inherent flow of DAC is that because of the sponsorship that is given to users they are allowed free reign within the enforcement of a possible corporate policy (not taking into consideration DRM such as IRM which can enforce somewhat global policy enforcement through a system but typically targeted for offline client access).

The largest goal that we seek to implement with a MAC based system is an overall security policy implementation that will enforce global rules across an environment. By using a detailed security policy that conforms to corporate goals and security requirements that assimilate regulatory and legal compliance requirements, we can ensure:

  • Secured Applications Are Protected
  • Separation of Privileges That Promote Sandboxed, Untrusted Application Execution
  • Vital and Essential Processes Are Assured Processing Space
  • Partitioning of Permissions Between Various Applications
  • Controlling Processing Limits
  • Control Privileges and Prevent Various Types of Privileges Escalation

The last of these are a significant security enhancement as opposed to DAC which is prime for an attack that would otherwise allow the concept of privilege escalation. DAC may immediately prove the first line of defense against attacks (in that objects and the system will still be bound to an identity.

This is not typically present within the OS’s that are provided by Microsoft since Windows Server is a closed kernel product, and to procure this type of security would require that there be direct hooks into the kernel, in effect negating the option for a developer to provide a hardened version of Windows that would otherwise be MAC compliant. Active support from the kernel is required at run-time for proper MAC to operate, since application layer mechanisms would could easily be circumvented because they are just that, assets that exist at the application level. However, by using Trusted Computing Mechanisms that are rather hooked into the hardware interface, one can provide the goals that we seek the building out a classified SharePoint environment, that of confidentiality most importantly, integrity of the data that is being stored within SharePoint, and the necessary separation of domains that will complete the CIA triad to provide assurance.

Transfer Data between SharePoint Security Domains

Within an arbitrary SELinux/SharePoint environment, there will eventually be the need for the option of traversing of data between various security domains, such as those that are classified and those that are unclassified. These is especially true when establishing an environment in SharePoint where a certain instance on a virtual machine that is deemed classified is transferring data to another that is deemed unclassified by definition. Since the overall Theory of Operation of a Hybrid SharePoint environment is that which utilizes various virtual machines in order to procure an environment that allows true classification of data, this is a present and substantial argument. This domain crossing can at times prove to be a hardware device, such as a perimeter based security device, perhaps something like a rudimentary firewall, however regardless of mechanisms of transfer, it is necessary to establish a data transfer functionality that will allow data to flow through defined, finely tuned, processing stages. This highly relates in the CIA triad to the concept of confidentiality, whereby the need for information to be secured throughout the entire information flow process is assured from start to finish. This is a built in concept within SELinux, which helps us to easily facilitate this.

Example of Security Based Enhancements Real World Application

A tangible example is often helpful when attempting to conceptualize the security benefits that SELinux provides. Assume that there is user A, which intends to trip a certain process, let’s assume a copy of a binary from unclassified SharePoint environment A to classified SharePoint environment B. The copy process, should, in essence, only have access to the specific binary it needs, not all binaries that exist within a computer, a typically problem that exists when leveraging a service account. In effect, the ownership of the assemblies should be properly separated, as opposed to universal access to what may be potentially unsafe information to share. By leveraging the concept of MAC, the copy process that is executed would provide a sandbox that allows the copy process to only touch and execute within its limits and permissions, it will only be allowed to perform the actions as defined with a security policy. Therefore, the copy process would become exploited by a malicious user, the only process that the malicious user could perform would be those that are deemed necessary be the service, regardless of the user account that the process is running under. This is regardless of as well if it is a service account that is offered root privileges on the environment. All objects are given a security policy defined sensitivity label that will determine how the process will interact with the system and the actions that are allowed on those arbitrary objects, allowing a tuned mechanism of control. The security context as presented with the copy argument can as well be presented to the networking concepts that may be related to a collaboration environment such as relevant ports, which can be bound to a security context as defined by a security policy. One of the largest reasons that an overall web server becomes compromised is that they are exploited initially through a port that is considered benign, whereas later the attacker once comprising the initial port will following open another port on the web server to execute further attacks on the SharePoint environment. In regards to the UNIX permissions that are existent within the SELinux environment, those permission still exist (the UNIX read/write, etc. permissions), however they are instead subject to the same security policies as discussed in the above section. The flow of access/denial is relatively straightforward and simple to follow the standard access / deny concepts exist. Since the deny UNIX will not allow any interaction, this does not require the consultation of the SELinux security policy, whatever it may be. However, if a successful access attempt is made, then the SELinux policy is consulted before access is granted.


Introduction To Hybrid SharePoint Using SELinux

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.

  1. 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)
  2. 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
  3. The general environment can only pass information that meant certain sensitivity label requirements from the general environment to the confidential environment
  4. 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.

Downloading SELinux
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:


Things I Can’t Live Without

Well, I have been looped into the chain tag by Joel Oleson going around in regards to things I wouldn’t want to live without. This is going to be kind of tough, I am a pretty simple person (as most people know), and even less caring about technology. Hmmm… this is going to take a little bit of thinking, and most of these probably aren’t going to be even about technology, but I will try to start with that at least, and see what dumps out of my head.

1) VI / Vim 7 / MonoDevelop – I can’t live without this editor, since I came from a UNIX background, I am just used to it. It might not have all the bells and whistles of Visual Studio, but I really like it when starting off a new project. I also do a lot of development against the Mono framework, so I tend to use the MonoDevelop environment, or a combination of the two. For business deliverables I often use VS.NET because they expect me to deliver a project file for internal developersto use, however, I often start just playing around with the wire framework of the application in VI and just bring it over to Windows from SuSE.

2) QSetup Installation Suite – Building setup projects to me is bleeding boring. I want to hang myself about half way through it, and it is something that I am just plain inefficent at, and generally I find the integrated tools lacking. Qsetup I like a lot because it is simple to use, has a ton of features, and takes what I would normally slit my wrists about half way through away. I use it to build all my SharePoint Solution deployment packages, since it is so easy to add the required commands through the interface.

3) FXCop – What can I say, we have a love / hate relationship with eachother. Nuff said.

4) Glock 34 – It’s my conceal and carry weapon, and easily the favorites pistol that I own. I code by it, sleep by it, and feel lonely when it is not in the small of my back. I carry it everywhere, and rarely carry any other pistol out of the house that I own.

5) RhinoMocks – I love RhinoMocks, I really wasn’t that familiar with using mock objects for my SharePoint development, however now I can’t imagine not using them. I looked through several mock object frameworks, played with pretty much all of them, and RhinoMocks was definitely my favorite. I like being able to just start a mock repository by just doing a MockRepository repository = new MockRepository().

6) My Peanut – Lisa, she is my peanut, and if it wasn’t for her I would be sitting in some random gutter smoking crack. She means everything to me, and I would gladly lay in traffic, then take a bat to the back for her. I can’t imagine living without her, and I am excited to marry her.

Um, thats about it I guess. Mine is a lot shorter than everyone else’s, oh well.