SELinux Permissions Management and Creation

SELinux Permission Management and Creation

As stated in other articles, there are two main concepts that exist in MAC architectures, subjects and objects, both of which are intrinsic to understanding the aggregate concept of SELinux architecture. Objects are simply assets that exist on the system, such as files. For each of these objects, there are permission sets that are associated with them that control the access and actions that subjects have in relation to those specific objects.

In SELinux, objects are grouped into the concept of object classes, and all objects that exist in an object class are of a type. Just like in OOP programming in the .NET framework that SharePoint builds on, an object class allows the instantiation of objects, and each instantiation represents an individual object. For administrators of SharePoint, it is easiest to think of this in terms of the file system as opposed to that of a programmatic object model, where you might have a folder of related files, which is the object class, for each file in that folder that you can individually instantiate, is an object. For access to the various objects, there are rules that are applied when access to the object is demanded to subjects, and these rules are constructed by the overall security policy. Although, it is important to understand that the concept of object classes extends to networking assets such as sockets, any type of communication that would in turn expose resources that exist at the OS kernel level. Ergo, the important thing to grasp is that for each object, it is typically grouped into a relevant object class, and for each of the object classes there are rules that are applied which build into the parent concept of SELinux security policies.

Permissions to objects are in an easy to read and create syntax. First we have to define whether the process is allowed or denied, the subject that the rule applies too, the object class file, and the permission rules that will generate the rules that define the access control in the object / subject relationship (this relates to the concept of type enforcement access control). With type enforcement access control, you define the source, target, object, and the permissions, which we can see translate to the above concept nicely.

Making new object classes in SELinux is fairly straightforward, and similar to how one constructs classes within .NET compliant languages. As stated previously, it is important to realize that several of the OOP rules that we see within such languages as C# still exists in SELinux since the concept of classes and objects is somewhat, if not, identical.

To declare a new object class names (which is known as a class declaration statement), for example declaring an object class sharepointsecurity, we can simply execute:

Class sharepointsecurity

We can see that the declaring a new class for consumption entails using the keyword class and then stating what the class name is, keeping in mind that the class name must be of ASCII characters and numerical standards. Unlike C# though, there is no terminating character to the class creation statement. But like C# and .NET OOP programming practice in general, there are individual namespaces that are made for relevant classes.

Defining SELinux security policies means building the structures that will build the permission sets related to the object classes. The object classes are typically already defined by the file system, however in order to construct and apply the relevant security policies to the hybrid SharePoint environment it is necessary to research and analyze the object classes that exist within the environment.

Now we have the object classes that are relevant to the policies that we are construct in our environment, either specific or not specific to our SharePoint implementation. Now that we have objects and objects classes, it is necessary for one to declare the permissions that are related to those objects by defining the sets. Similar to group and individual groups within Active Directory within a Windows Based environment (i.e. you can compile an AD group in windows and bind it to an object, or declare a domain account that has access to that object), SELinux offers two main methods of binding relevant permissions to an object within the system. The first of these is known as common permissions.

Common permissions can easily be thought of as associating permissions with a group in relation to an object class.  When creating common permissions, we are creating permissions that are associated instead with a more than one class, as opposed to specific permissions which are bound to a specific class. Declaring common permissions is a relatively simple class and resembles class declaration in C#. The structure is easy to follow, we declare that we are stating common permissions, declaring the set name, and then declaring the object classes that the permissions apply to. The important thing to grasp with common permissions is just that they apply to more than one object class.

Common myexamplepermissionset








In the above example we are declaring the common permission name by using the common keyword and stating what the common permission set name is. The common name can be ASCII characters, numbers, dashes, or periods, and the permission set can be ASCII characters, numbers, dashes, or periods as well.

Now that we have seen that we can declare a permission set that is common, they have to be bound to a specific object class. The way that this is done is by using an access vector statement. We must associate it with an object class because although we have declared the permission set it is simply an asset that can be associated with an object class, however this is not implied. Meaning, once we associate the common permission set with the object class is when we truly see the effect that they can have, until then they simply exist and have no real effect on the overall hybrid SharePoint environment.

To associate the permission set with the object class is a relatively simple task, we have to declare the object class, and then define the permission set that we wish to bind to the object class. To create an access vector statement that would cause the sharepointsecurity object class to have class myexamplepermissionset permission would look like the following:

Class  sharepointsecurity {  myexamplepermissionset }

We are basically defining the object class and the permission set that we wish to bind, in essence this looks very similar to the C# syntax, the only difference is that there is no terminating character present.

The concept of inheritance is well known is C#, and it is no different in SELinux. Indeed, permission sets are also subject to the concept of inheritance.

Class sharepointsecurity

Inherits myexamplepermissionset





If we instigate the following example of inheritance, we are easily associating the shared permission set myexamplepermissionset with the object class sharepointsecurity, along with the custom permission set that we are defining inbetween the brackets. So, we can inherit an already defined permission set, and extend the permission set with any custom permissions that we wish to define by placing them in the ending statement parameters. This doesn’t mean that you have to extend an object class when inheriting a custom permission set, you can easily just inherit a permission set to an object class after its creation by excluding the statement as defined between the brackets. In the above example, we could modify it to look like:

Class sharepointsecurity inherits myexamplepermissionset

In this, we are simply inheriting the permission of myexamplepermissionset and not including any other custom permission such as execute or mkdir.


Introduction to MOSS Security Architecture

Introduction to MOSS Security Architecture

The Microsoft Office Server System (SharePoint 2007) has many exciting new security mechanisms built into it that allows one to build a highly guarded collaboration environment that provide a unique, fluid user experience for all of the stored content. In previous versions of SharePoint, sometimes implementing very granular security options had the negative side effect of degrading the rich communications and collaborations feature of the product, required heavy development efforts, or additional hardware and software purchase.
Changes To The MOSS Security Architecture


There are however unique security features built into MOSS currently that allow one of the most robust, however secure, information worker centric environments to procure virtual teams within an organization. Building on technologies such as Windows Rights Management, Information Rights Management, and powerful permissions management, many afflictions that typically affect collaboration platforms can be solved through intuitive, internal security mechanisms.

Some of the MOSS security architectural possibilities are very industry exciting, specifically for those organizations that have to conform to certain business and legal regulations that stipulate certain privacy and security requirements, providing built in mechanisms for such popular regulations such as HIPPA and SOX.

Examples of Enhanced Security Provided by ASP.NET 2.0

Some of the greatest security enhancements in MOSS spawn from its new architecture and web application structure.

  • Since SharePoint relies on view states by default, and in the new version of Sharepoint this is protected through various hashing mechanisms through minor effort can be encrypted using some attributes, most notably the viewStateEncryptionMode attribute in machine.config of your SharePoint server.
  • Since one of the greatest enhancements is the introduction of forms based authentication possibilities into a SharePoint environment, forms authentication cookies and related authentication tickets are encrypted instead of being stored in plaintext, protecting authentication assets.
  • There are several options for enabling a session states (regardless of where the session information is stored), and therefore out-of-process session state assets are protected by the ASP.NET 2.0 framework, the backbone of MOSS.
  • For the pluggable authentication options of MOSS, if you are implementing a membership and role provider that is outside of the realm of the default windows authentication routines (which is, by default enabled), the related role manager cookies are encrypted. Along the same lines, if you have anonymous MOSS zones or a perimeter facing site with anonymous authentication enabled, those relevant cookies can be encrypted. For the membership providers, since they are stored in a variety of different systems, these passwords are stored hashed, if a heightened security option is more desirable, these passwords can be encrypted as well.

Why Was The Security Architecture Of SharePoint Changed?

There are several stages in order to implement sheltered knowledge management systems and secure collaborations environments, regardless of network architecture and operational access goals. SharePoint attacks are becoming increasingly relevant towards business operations and strategic business data warehousing as the product becomes increasingly commonplace throughout a variety of industries for an assortment of reasons.
Steps In Securing a SharePoint Environment
The first step in securing a SharePoint environment is to implement standards and policies with an environment, and just having these policies in place is not enough, they have to be enforced and adhered to by both portal users and administrators. These policies can vary in purpose and intent, as shown here in this index of SharePoint policies.
The second step is to investigate, implement, and maintain sister security and disaster recovery based server systems that will integrate and enhance your environment on a variety of levels.
Most Popular Security Shifts in SharePoint
Being built upon the new ASP.NET 2.0 platform offers SharePoint some unique security features that birth the possibility of several very lucrative environments. The two that are immediately evident are:
  • Forms-Based Authentication (FBA)
  • Pluggable Provider Model (Membership, Role, Session, and Profiles)

These two new options are incredibly popular options since they were the most requested features in previous version of SharePoint, and coupling the two options allows users to have an extranet / perimeter facing deployment that is unique and tailored to each specific instance.

Reasons SharePoint is Subject For Attack
The two most commonplace reasons SharePoint is a subject for attack are:
Data Theft Since SharePoint acts as an aggregator and warehouse for several layers of business information, a third party may try to capture vital enterprise data for any number of purposes, ranging from sale of this information to competitors or simply trying to pry into day-to-day operations.
Corporate Espionage Taking down a portal from an operational standpoint for businesses that are heavily dependent on it for operations can prove disastrous, and beneficial to a competitor that can take advantage of a weakened business state. This type of intended disruption has been well-documented throughout history through other systems (mostly through the battles between smaller communications companies in California, see here for more information regarding those DDoD attacks), and has translated over to SharePoint environments.
There are three main levels (tiers) of SharePoint security each of which has to be tackled individually and methodically maintained (loosely based on the OSI model):
  • Network Level
  • Web Application Level
  • Database Level
However, with certain procedures in place the threats to a portal can become vastly mitigated and an organization can collaborate in confidence.

SELinux and SharePoint

I have written about SELinux in the past in regards to SharePoint, the research which is housed on the main site.

Introduction To Hybrid SharePoint (SELinux)

Hybrid SharePoint / SElinux Theory of Operation

SELinux Permissions Management and Creation

The CIA Triad and MOSS

Formal Access Control Methodolgies and SharePoint

I am wondering for the greater community, if I built a step-by-step guide on how to achieve a hybrid environment, or a package that automated it, would this be of interest and usable. I know that MAC level environments tend to only be of interest to parties that are involved in the federal sector, but I don’t know if it would be of interest to other sectors where this might be beneficial.