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:

Share

SharePoint Intrusion Detection Policy Template

Introduction – SharePoint Intrusion Detection Policy Intrusion detection plays an important role in implementing and enforcing a SharePoint organizational security policy. As SharePoint grows in complexity, effective security measures must evolve.
Purpose SharePoint-aware intrusion detection provides two important functions in protecting the SharePoint environment:

  • Feedback: Information as to the effectiveness of the IDS and associated components. If a robust and effective IDS is in place, the lack of detected intrusions is an indication that other defenses are working.
  • Trigger: a mechanism that determines when to activate planned responses to an intrusion incident.
Audience The [Organization] SharePoint Intrusion Detection Policy applies to all individuals that are responsible for the installation of new SharePoint resources, the operations of existing SharePoint resources, and individuals charged with SharePoint resources security.
SharePoint Intrusion Detection Policy
  • Operating system, user accounting, and application software audit logging processes should be enabled on all host and server systems for internal customers.
  • Alarm and IDS alert functions of backbone firewalls and other network perimeter access control systems must be enabled, and monitored by the SharePoint administrator.
  • Audit logging of any firewalls and other network perimeter access control that may lead or display business data from the SharePoint environment must be enabled.
  • Audit logs from the perimeter access control systems must be monitored/reviewed daily by the SharePoint administrator.
  • System integrity checks of the firewalls and other network perimeter access control systems must be performed on a routine basis.
    Audit logs for servers and hosts on the internal, protected, network must be reviewed on a weekly basis. The SharePoint administrator will furnish any audit logs as requested by [Organization] management.
  • Host based intrusion tools will be checked on a routine.
  • All trouble reports should be reviewed for symptoms that might indicate intrusive activity.
  • All suspected and/or confirmed instances of successful and/or attempted intrusions into the SharePoint environment must be immediately reported according to the Incident Management Policy.
  • Users shall be trained to report any anomalies in system performance and signs of wrongdoing to the [Organization] Help Desk.
SharePoint Intrusion Detection Policy Supporting Information
  • Any and all [Organization] SharePoint security controls must not be bypassed or disabled.
  • All [Organization] SharePoint users are responsible for managing their use of SharePoint and are accountable for their actions relating to SharePoint security. Users are also equally responsible for reporting any suspected or confirmed violations of this policy to the appropriate management responsible for SharePoint security incident handling.
  • The integrity of [Organization] SharePoint software, utilities, operating systems, networks, and respective data files are the responsibility of the server custodian department. Data for test and research purposes must be de-personalized prior to release to testers unless each individual involved in the testing has authorized access to the SharePoint data.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All [Organization] departments must carefully assess the risk of unauthorized alteration, unauthorized disclosure, or loss of the data within the [Organization] SharePoint environment for which they are responsible and ensure, through the use of monitoring mechanisms such that [Organization] is protected from damage, monetary or otherwise. SharePoint owners and server custodian departments must have appropriate backup and contingency plans for disaster recovery based on risk assessment and business requirements.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share

SharePoint Backup/DRP Policy Template

Introduction – SharePoint Backup/DRP Policy SharePoint backups are a business requirement to enable the recovery of SharePoint data and applications in the case of events such as natural disasters, system disk drive failures, espionage, data entry errors, or system operations errors.
Purpose The purpose of the [Organization] SharePoint Backup/DRP Policy is to establish the rules for the backup and storage of electronic [Organization] information.
Audience The [Organization] Backup/DRP Policy Policy applies to all individuals that are responsible for the installation of new SharePoint property, the operations of existing SharePoint property, and individuals charged with SharePoint security.
SharePoint Backup/DRP Policy
  • The frequency and extent of SharePoint backups must be in accordance with the importance of the information and the acceptable risk as determined by the data owner.
  • The [Organization] SharePoint backup and recovery process for SharePoint must be documented and periodically reviewed.
  • The vendor(s) providing offsite SharePoint backup storage for [Organization] must be cleared to handle the highest level of information stored.
  • Physical access controls implemented at offsite backup storage locations must meet or exceed the physical access controls of the source systems. Additionally backup media must be protected in accordance with the highest [Organization] sensitivity level of information stored.
  • A process must be implemented to verify the success of the [Organization] SharePoint backup.
  • Backups must be periodically tested to ensure that they are recoverable.
  • Signature cards held by the offsite backup storage vendor(s) for access to [Organization] backup media must be reviewed annually or when an authorized individual leaves [Organization].
  • Procedures between [Organization] and the offsite SharePoint backup storage vendor(s) must be reviewed at least annually.
  • Backup tapes must have at a minimum the following identifying criteria that can be readily identified by labels and/or a bar-coding system:

1. System name

2. Creation Date

3. Sensitivity Classification [Based on applicable electronic record retention regulations.]

4. [Organization] Contact Information

SharePoint Backup/DRP Policy Supporting Information
  • Any data housed within SharePoint must be kept confidential and secure by the respectful [Organization] SharePoint user. The fact that the business data may be stored electronically (i.e. document library or SharePoint list) does not change the requirement to keep the information confidential and secure. The type of information or the information itself is the basis for determining whether the data must be kept confidential and secure. Furthermore if this data is stored in a paper or electronic format, or if the data is copied, printed, or electronically transmitted the data must still be protected as confidential and secured.
  • On termination of the relationship with the Sharepoint user all security policies for [Organization] apply and remain in force surviving the terminated relationship.
  • The department which requests and authorizes a SharePoint application (the site / application owner) must take the appropriate steps to ensure the integrity and security of all SharePoint Web Parts and application logic, as well as data files created by, or acquired for, SharePoint applications. To ensure a proper segregation of duties, owner responsibilities cannot be delegated to the SharePoint server custodian.
  • The integrity of [Organization] SharePoint software, utilities, operating systems, networks, and respective data files are the responsibility of the server custodian department. Data for test and research purposes must be de-personalized prior to release to testers unless each individual involved in the testing has authorized access to the SharePoint data.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All [Organization] departments must carefully assess the risk of unauthorized alteration, unauthorized disclosure, or loss of the data within the [Organization] SharePoint environment for which they are responsible and ensure, through the use of monitoring mechanisms such that [Organization] is protected from damage, monetary or otherwise. SharePoint owners and server custodian departments must have appropriate backup and contingency plans for disaster recovery based on risk assessment and business requirements.
  • All SharePoint contracts, leases, licenses, consulting arrangements or other agreements must be authorized and signed by an authorized [Organization] officer and must contain terms approved as to form by the Legal Department, advising vendors of [Organization] ‘s retained proprietary rights and acquired rights with respect to its information systems, programs, and data requirements for SharePoint security, including SQL data maintenance and return.
  • [Organization] SharePoint implementation(s) and/or associated equipment used for [Organization] SharePoint implementations that are conducted and managed outside of [Organization] control must meet contractual requirements and be subject to monitoring by appropriate SharePoint administrators as well as other parties.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share