Trust Levels in Microsoft Office SharePoint Server and WSSv3

Introduction to Microsoft Office SharePoint Server and WSSv3 Trust Levels and Code Access Security

Trust levels are an integral portion of SharePoint security and how your application architecture will interact with users. Trust levels are integrally tied into the concept of Code Access Security (CAS) in SharePoint, and how that code interacts with various security decisions. Typically, when executing code in an application environment, the context of that application will assimilate the identity of the user, regardless of what the arbitrary application may be. This however differs in SharePoint, which leverages the concept of Code Access Security in order to determine what code should be run within the SharePoint environment. CAS, at first glance can appear very confusing, but rather, once the concept and architecture that builds CAS is understood it is a very powerful concept.

Defining Trust Levels Within SharePoint

There are various CAS trust levels that SharePoint can run under, each which has its owns implications and after effects, and deciding which to leverage dictates a through analysis before implementing each within your SharePoint environment. As developers of the previous version of SharePoint can attest to, establishing the trust levels for your custom WebParts that are developed can prove rather problematic. The trust levels that are managed are saying exactly what classes your code can call out of the .NET framework as well as how that code is managed and leveraged within the SharePoint application, and although developing the actual WebPart is straightforward, how to properly implement it within your SharePoint environment tends not to be. These trust levels exist on the actual SharePoint machine as provided by the ASP.NET 2.0 framework, and can be modified or added to with custom policy files as deemed appropriate. It is somewhat common since it is the default for vanilla ASP.NET application to implement full trust, however is incredibly poor code access security practice.

The Various Trust Levels of SharePoint

There are several standard default trust levels that you get with SharePoint; full trust, high trust, medium trust, low trust, and minimum trust. With full trust all code that is implemented is allowed to run in essence, it is allowed to call any class within the .NET framework and can call pretty much any operation on the local machine. This can be a dangerous level to implement, since it will allow SharePoint WebParts to call operations on the machine that although are quite powerful, can prove dangerous to the machine. High trusts, and any subsequent trust levels, are considered partial trust, since they don’t allow full trust as the previously described level does. The next level of trust is high trust. High trust when implemented in SharePoint is simply that your SharePoint WebParts can not call native unmanaged code, which is defiantly a good thing. When defining the level as high, it will significantly reduce the threat to your SharePoint environment and is definitely the first step to implemented proper SharePoint security. Medium trust is the next trust level, and is typically within an implementation where there are multiple SharePoint instances hosted on a singular machine, where it is important to maintain a more granular level of permissions across a shared environment. The largest restriction that gets placed on applications that are running in medium trust is that it inherits the restriction of not being able to call the win32 API’s from the high trust level, and in addition restricts reading and writing to anything outside of the SharePoint instance, i.e. where you provision your SharePoint web application structure. You can easily find this by doing an explore through the IIS MMC which will show you the exact path that the code will be able to write. Low trust is the next trust, and is the most restrictive trust, and is typically if you are not running and code on the web server at all, is a good level of trust. It s a typically trust level implemented by default when implemented COTS software that doesn’t have several .aspx pages that exist on the filesystem. In MOSS and WSSv3, there is a modified level of low trust that is implemented by default, however this can obviously be extended with the trust levels that we have talked about thus far. The last trust level to be discussed is that of minimal trust, and minimal locks down the levels available to the developer to a large extent. When running under minimal trust, it means that all WebParts and custom application hooks into SharePoint will not be able to call classes that could at any point possible cause a security compromise of the SharePoint environment. This is a good practice for sheltered SharePoint environments for one overlying reason. When developing WebParts, you can sign them in order to bind them with a strong name, and then deploy them into the Global Assembly Cache (GAC). Only a user with local administrator privileges within a SharePoint server can install various assemblies to the GAC, and therefore deploying code that could potentially cause undue security problems is locked down to simply an administrative task, whom can firstly examine and analyze the code before deploying it to the production SharePoint server.

Partially Trusted Callers

One of the largest differences that a developer will see within MOSS and WSSv3 is that there is within the assemblyinfo file within there project file in the system.security namespace partially trusted callers. Now that we have seen what a partial trust class is, we can see that when under certain trust levels the code will not be able to call various interops, however in the aseemblyinfo file you can set the partially trusted attribute to true to bypass this restriction in your code when needing to make such actions.

Permission Sets and Code Groups

As discussed previously, the central concept to understand in terms of trust levels is CAS, which is discussed more exhaustively in other articles. In other articles the idea of a permission set was discussed which deserves some examination in this current context since it plays a heavy role in the concept of trust levels with SharePoint. As defined in the CAS article, a permission set is simply a way of lumping code restrictions into a manageable group that can be applied to singular or multiple sets of code that are going to run within your SharePoint environment. This is a very powerful configuration concept since it allows a developer to define new permissions to apply to code when it is necessary, when the standard permission sets the ASP.NET 2.0 doesn’t give by default. Within ASP.NET 2.0, there are a few default permission sets that are defined by default: FullTrust, Nothing, and ASP.Net. Each of these, as well as we will see with custom permission sets, are defined within the < PermissionSet /> node in the web.config file, and within this node, there are several child elements that can be defined that can be used to either extend/change the default permission sets or modify custom created permissions that you leverage against your code. In this, the permission sets have to bound to a specific set of code to be useful, as opposed to something that is applied at a global level. The major concept that binds the permission set to a specific piece of code is code evidence, which defines things such as where the compiled code is located, signatures on the compiled assembly, and other various pieces of information, and once the evidence is there, the evidence can be then used in to place the CAS rules against the running piece of code, called a code group, by using a membership condition. Code groups where discussed on another article on this site, however they are easily defined within the code group elements in the web.config file. The code group in essence will allow a developer to bind to a defined permission set whether it is a default permission set, or a custom defined one, and then will look at the code evidence as presented in the membership conditions for final applicability. Code groups are inherently important to concept of securely running a SharePoint environment, since they build the binding of evidence within WebPart code. Code Groups, as you may have guessed, are related to the concept of permissions sets in that each code group is associated within a defined permission set, as discussed above, so when examining the code group values in the web.config file, you will see that for each the PermissionSetName value will be set to a permission set. Within the code group, there is also a node for the conditionally membership match as discussed above, which is defined in the IMembershipCondition node, which is based on the concept of evidence as provided thus far.

Example of Default Code Groups

Code groups within the web.config a very easy to breakdown and define, they are very self explanatory and the concepts that they birth are easy to see within their XML values. For example, let’s look at the first code group that is defined, which is just the FirstMatchCodeGroup. It looks like the following:

[xml]

< CodeGroup class=FirstMatchCodeGroup

version=1 PermissionSetName=Nothing >

< IMembershipCondition class=AllMembershipCondition version=1

/ >

[/xml]

String Replacement Values and Their Definitions

When examining the code groups, there may be some values that appear confusing, and they are string replacement values. These appear in various places when doing SharePoint development as well as traditional ASP.NET 2.0 development that may hook into SharePoint API’s. This are extremely evident when firstly examining the policy files, but appear in other places as well. The string replacements that you find are $AppDir$, $AppDirUrl$, $CodeGen$, and $OriginHost$. These are placed in these files for a very good reason, because SharePoint in essence is a very dynamic application that allows the placement of relevant files and configuration elements in various locations, the values may at times may need to be replaced at run time. The actual values that are going to be used when the replacement variables run at pretty self-evident, $AppDir$ will give the full file system path, $AppDirUrl$ will give the replacement file system path is fit for consumption that are needed in a certain format, $CodeGen$ shows where the managed code that a developer writing against SharePoint, or in a larger picture, the managed code that ASP.NET 2.0 is using, in essence where the temporary ASP.NET files lie (usually in the framework directly under the Temporary ASP.NET Files directory) and is the code that the developer defines is located, and lastly $OriginHost$ which will give will give the fully qualified URL endpoint of where the code is originating from, so for code running on this site, the OriginHost value would be http://www.sharepointsecurity.com.

Examining the Default Values of SharePoint

To get a better idea of this whole concept, examine the default permissionsets that are given by default: FullTrust, Nothing, and ASP.Net, and then I will show how to create a new permissionset that can be used if you need to create a new one for consumption into SharePoint. As well, lets look at a real world example of using code groups within our SharePoint environment to effectively restrict the permissions that are leveraged against a SharePoint WebPart.

Firstly, here is the permission set for fulltrust, the most lenient of permission sets:

[xml]

< PermissionSet class=NamedPermissionSet version=1

Unrestricted=true Name=FullTrust

Description=Allows full access

/ >

[/xml]

We can see in the above that we are allowing unrestricted access, a very open permission level.

The next permission set is that of nothing, and means that there are null permissions.

[xml]

< PermissionSet class=NamedPermissionSet version=1

Name=Nothing

Description=Denies all resources, including the right to execute

/ >

[/xml]

The ASP.Net permission set allows various meanings that define each of the unique trust levels, and looks like the below:

[xml]

< PermissionSet class=NamedPermissionSet version=1

Name=ASP.Net >

…….

…….

…….

< /PermissionSet >

[/xml]

Outside of the default permission sets that are defined, it is possible to define custom permissions that can be applied in regards to CAS, such as the option for I/O operations for a specific piece of code.

Share

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.
Share