Introducing Sandboxable: use your favorite (Azure) NuGet packages in a sandbox environment

I would like to introduce to you Winvision’s first open-source project: Sandboxable.

Sandboxable enables your project to utilize functionality provided by other (Microsoft) libraries that normally are not able to use in a Partial Trust environment like the Microsoft Dynamics CRM sandbox process.
The project offers modified NuGet packages that will run with Partial Trust.

Sandboxing

Sandboxing is the practice of running code in a restricted security environment, which limits the access permissions granted to the code. For example, if you have a managed library from a source you do not trust, you should not run it as fully trusted. Instead, you should place the code in a sandbox that limits its permissions to those that you expect it to need.

You can read more on this in the article How to: Run Partially Trusted Code in a Sandbox
If you encounter a .NET sandbox today chances are it’s running with Security-Transparent Code, Level 2

A big example of software running in a sandbox are the Microsoft Dynamics CRM (Online) Plug-ins and custom workflow activities. (Plug-in Trusts)

The problem

As developers we use a lot of library code like NuGet packages as we are not trying to reinvent the wheel. The downside is that most of these libraries are not written with a Partial Trust environment in mind.
When we embed these libraries to our code in the sandbox, we encounter two common issues:

1. The code contains security critical code and will fail to load with a TypeLoadException or will throw an SecurityException at runtime
2. The package references another package that contains security critical code and even though the code might not even be used it will trigger one of the exceptions mentioned above

Problematic constructs

Calling native code

[DllImport("advapi32.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
internal static extern bool CryptDestroyHash(IntPtr hashHandle);

Override SecurityCritical properties of an object like Exception

public override void GetObjectData(SerializationInfo info, StreamingContext context)
{
     ... 
}

Where Exception has the following attributes on this method

[System.Security.SecurityCritical]
public virtual void GetObjectData(SerializationInfo info, StreamingContext context)
{
     ...
}

Serialize non-public classes, fields or properties

[JsonProperty(DefaultValueHandling = DefaultValueHandling.Ignore, NullValueHandling = NullValueHandling.Ignore, PropertyName = PropertyNotBefore, Required = Required.Default)]
private long? _notBeforeUnixTime { get; set; }

The solution

When we encounter a NuGet package that fails to load or execute in the sandbox and its source is available we make a Sandboxable copy of it.

This is done by eliminating the offending code in a way that is the least obtrusive and publish this version to NuGet.

The base rules are:

• Keep the code changes as small as possible
• Prefix all namespaces with Sandboxable
• Eliminate offending NuGet dependencies
• If a new dependency is needed, it will be on a sandbox friendly NuGet package

Source and contribution

The source is published at the Sandboxable project at GitHub.

Included in the solution is also a stand-alone project to test if code will break inside a sandbox. This makes testing libraries easier without the need to deploy it to a (remote) environment.

I like to invite everybody to use the Sandboxable NuGet packages and contribute to the project.

Related posts:

Sending a message to an Azure queue from a sandboxed CRM plug-in Storing entities on Azure blob storage from a sandboxed CRM plug-in “Missing” Azure APIs when adding permissions to an Azure AD app