http.sys Kernel Driver and aspnet_filter.dll

Before getting started into creating the most secure MOSS or WSSv3 site that we can, it is prudent to firstly understand how SharePoint processes the relevant requests that it is handling and serving to external clients with an internet facing, as well as an internal site.

When an initial request is made to SharePoint, it is possible that the request actual never makes it to have been parsed by the ASP.NET handler that will push out the relevant SharePoint page. The first layer of permissions processing that SharePoint will handle are those that are given by the Windows kernel, gaining support from that substance of the HTTP driver that will ultimately serve the request through the relevant pipe. This HTTP driver is known as http.sys which is the primary handler for the SharePoint request, and has some mechanisms that deal with information handling and serving that help to protect the overall server environment.

The first of these is minimizing the request throughput in regards to URL length that can exist within a SharePoint URL. Although it is relatively common within a SharePoint URL for the URL name to become lengthy, the overall URL and its associated request assets size may never exceed 16k, the path segments can never be above 255 segments, and the length of a specific segment should not exceed the length of 260 characters, although this is a rather generous size in any respect, particularly if you have taken the time to carefully name your SharePoint sub sites correctly. The actual body of the request is not handled at this point, rather it is handled by ASP.NET. In any respect, hitting this type of restrictions is atypical within a common SharePoint environment, however keeping them in mind will ensure that your uses have the most fluid and consistent user experience and your application architecture doesn’t subjugate itself to undo service downtime. This comes primarily into play when developing custom applications and WebParts that leverage the SharePoint framework that may implement query string values. When developing the specific WebPart, is important to keep in mind that the amount of characters that exist in the WebPart query string do not exceed 260 characters otherwise the kernel mode restrictions will come into play.

There is a good purpose behind this restriction type. Several types of attacks that may happen against a SharePoint environment take on the role of appending various characters against the overall URL structure, by which it would allow arbitrary commands or code to be executed on the server. As well, if a malicious user where attempt to try various types of these attacks against the SharePoint server, it would result in possible service disruption as SharePoint struggles to serve the malformed user request. In order to track these malicious requests as they happen against a SharePoint environment, it is best to maintain active study of the HTTP logs so that pertinent addresses can be blocked if necessary (i.e. booted attempts). This log exists with all the rest of the IIS logs in the system 32 log directory, and will give you all the GET requests that may have been malicious towards your SharePoint environment.

Once the kernel level checks are done on the request from the client, it is time for ASP.NET 2.0 to begin handling the request, since this is the underlying basis that SharePoint is built on. This is handled by aspnet_filter.dll, which is also known as the ASP.NET worker process routine. This is kicked in following the whatever other ISAPI filters are placed on the IIS virtual server outside of the ASP.NET runtime ISAPI extension, which, in the current version of SharePoint as opposed to previous versions is fortunately none. The important concept to grasp however is that the kernel mode HTTP driver is the first level that is subjected to the request.

aspnet_filter.dll is the following section that is implemented after the request has passed through the kernel mode driver. This happens before managed code is executed. The aspnet_filter is responsible for two main actions, protecting those directories that are under ASP.NET supervision, and translating cookie less tickets into HTTP headers. The last of these is very important, since cookies less tickets are imperative for session state functionality. The other is protecting the directories that are managed under ASP.NET, which is related to the cookie less tickets since it happens after the ISAPI filter processes those tickets. The URL that a user request will be processed, and if it stats a certain directory that ASP.NET deems as protected, such as: /bin, /app_code, /app_data, /app_globalresources, /app_localresources, /app_webreferences, or/app_browsers, IIS will take over and return an error to the user.


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 . Here is a list of the available distributions: