Sharepoint 2010 Sandbox Solutions : You see it a new feature ?

“Amit! SharePoint 2010 has many new features. I found Sandbox Solutions…a cool new feature !!” –exclaimed my friend… who started his career as a SharePoint developer. If you are a pure SharePoint developer, chances are high that you may feel the same :) .

The concept of ‘Sandbox’ existed in .NET right from the beginning.  SharePoint in nothing but a .net application on steriods. With Sharepoint 2010, it is good that we can exploit the concept of “Sandbox” like we were(and we are) able to do in .NET

A sandbox is an environment where every aspect of security is controlled by the host.The host is a separate process which can be a windows service, console application or IIS website or SharePoint 2010 Sandbox Worker Process (which runs sandbox solutions in SharePoint).

Before going into a sandbox, let me talk a bit about of Permissions in .NET. Permissions are the different powers or abilities which CLR can grant or deny to .NET code. The .NET Framework has a set of permissions to control access to system which you’ll find  in the System.Security.Permissions namespace.

In .NET, Permissions provide a layer of security (apart from operating system security) in two ways:

  1. Sandboxing: Limiting the type of operations that partially trusted .NET assemblies can perform. Sandboxing uses code access permissions.
  2. Authorization: Limiting who can do what. Authorization uses identity and role permissions.

To understand how a Sandbox work, we should also know about code access security (CAS) in order to :

  •  Write assemblies that will run in a limited permissions environment (a sandbox).
  •  Create your own hosting environment, like Sandbox Worker Process (SPUCWorkerProcess.exe) we have in SharePoint 2010, those sandboxes other assemblies.

How Code Access Security Is Applied to Sandbox

When you run a .NET exe from the Windows shell or command prompt, it runs with unrestricted permissions. This is called full trust.

If you execute an assembly via another hosting environment – such as a SQL Server CLR integration host or Sandbox Worker Process (SPUCWorkerProcess.exe), the host decides what permissions to give your assembly ( a sandbox web part for example).

To be technically correct, a host does not apply restricted permissions to your assembly. Rather, it creates an application domain with restricted permissions, and then loads your assembly into that sandboxed domain. This means that any assemblies that load into that domain run in that same sandbox with the same permissions.

There are two exceptions, however:

• Assemblies registered in the GAC like Farm level solutions in SharePoint

• Assemblies that a host has nominated to fully trust. We know that Sandbox solutions can use Proxy, SPProxyOpertion, which is fully trusted and allows us to extend sandbox solutions capability in SharePoint 2010.

Code Access Security Restrictions for Sandbox Solutions in SharePoint

The sandboxed solutions are enforced by a restrictive code access security policy. This restricts sandboxed solutions to use a specific subset of the Microsoft.SharePoint namespace and access to external resources or databases.

The Web.config file in the 14Usercode folder contains the CAS policies that apply to sandboxed solutions in SharePoint.

Permission Restrictions

Apart from code access security policy , there are restrictions on the actions that you can perform from sandbox solution as the sandbox worker process uses an account with a limited permission set.

Because sandbox solutions run in a partial-trust environment, any assembly that contains method to be called from the sandbox must include the attribute AllowPartiallyTrustedCallersAttribute.

 

Creating a sandbox solution in .NET

Imagine you want write an application that allows your friends to install third-party plugins. One example is Visual studio- It allows you to install plugins like SPDisposeCheck. Right?

Most likely you’d want to prevent plug-ins from exploiting your privileges as a trusted application, so as not to destabilize your application or the user’s machine.  The purpose of Sandbox solutions in SharePoint 2010 is also the same – to prevent code from destabilizing the SharePoint farm. And the best way to achieve this is to run each plug-in in its own sandboxed Application domain.

This is what the Sandbox Worker Process (SPUCWorkerProcess.exe) does. For every sandbox solution, it creates a separate application domain which is, of course, subject to execution and access constraints.

For this example, we’ll assume a plug-in is a .NET exe called  sandboxplugin.exe. Here’s the complete code, for the host program:

using System;
using System.IO;
using System.Net;
using System.Reflection;
using System.Security;
using System.Security.Policy;
using System.Security.Permissions;
class Program
{
static void Main()
{
string sandboxPluginPath = @"c:sandboxfoldersandboxplugin.exe";

//Creating  restricted permissions for plugin to execute
PermissionSet ps = new PermissionSet (PermissionState.None);
ps.AddPermission (new SecurityPermission (SecurityPermissionFlag.Execution));
ps.AddPermission (new FileIOPermission (FileIOPermissionAccess.PathDiscovery |
FileIOPermissionAccess.Read, plugInPath));
ps.AddPermission (new UIPermission (PermissionState.Unrestricted));

AppDomainSetup setup = AppDomain.CurrentDomain.SetupInformation;

//Creating a new application domain for plugin
AppDomain sandbox = AppDomain.CreateDomain ("sbox", null, setup, ps);

//Any problem in running the plugin will not destablize your host application.
sandbox.ExecuteAssembly(sandboxPluginPath);
AppDomain.Unload (sandbox);
}
}

Technorati Tags : ,

Leave a Reply

Subscribe

Get every post delivered to your inbox via FeedBurner :

© 2010-2013 Extreme Sharepoint | The content is copyrighted to Amit Kumawat and may not be reproduced on other websites.