Securly hosting addins and/or sandboxing

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I've been researching how to securely host addins in a .NET 1.1 environment
(AKA sandboxing). I've found various references on the separate AppDomain
method which (if I'm following correctly) essentially loads an assembly and a
type from that assembly within a different AppDomain and marshals the object
to another AppDomain via use of the following functions:
AppDomain.CreateDomain
AppDomain.CreateInstanceAndUnwrap or .CreateInstancFromAndUnwrap
Assembly.Load

....where CreateInstance[From]AndUnwrap would create an internal utility type
(deriving from MarshalByRefObject) that calls Assembly.Load and/or
CreateInstance[From]AndUnwrap for the addin and its type. This also requires
the addin type (and aggregate types) to be Serializable.

This provides a certain physical separation of the addin type from the rest
of the application. Security can be added with AppDomain.SetAppDomainPolicy
before loading the addins assembly and loading the requisite type to apply
the principle of least privilege and to prevent luring attacks.

I've found the bare minimum permissions to be Execution and FileIOPermission
= Unrestricted. Although, I'm leery an addin truely requires this level of
FileIOPermission.

I've only found theoretic discussions on the use of these functions and have
not found a complete concrete example. e.g. is simply calling these
functions provide the best security for an application running addins? Could
someone point me to a good example of this type of sandboxing. Also, I would
be interested in unit tests that show the various types of attacks and how
they are thwarted by this sandboxing technique.
 
Hi,

Based on my research, I did not find a mature Unit test code to simulate
the attack.
Here is link about create Sandboxing application for your reference.
The Simple Sandboxing API
http://blogs.msdn.com/shawnfa/archive/2005/08/08/449050.aspx

Also based on my knowledge, there is no such definite permission setting
for a Sandboxing Application. Less permission will make the Sandboxing
application more secure. But less permission will restrict the Sandbox
application's function. So how to set the permission depends on what you
Sandboxing application want to do. The principle is as less as possible
based on the functions you want to implement in your Sandboxing application.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Peter. Thanks for your response. Your reference to the blog on the
Simple Sandboxing API was interesting; but, I'm dealing with .NET 1.1--the
Simple Sandboxing API is .NET 2.0.

That blog's reference to "Creating an AppDomain with limited permissions"
(http://blogs.msdn.com/shawnfa/archive/2004/10/25/247379.aspx) is one of the
references I've been using; but, as with all of the other references, it does
not provide any example of how to properly use the "restricted domain",
especially with external assemblies (e.g. "addins").

For example, I was under the impression that creating a new AppDomain and
attempting to load an assembly with that object doesn't properly load that
assembly within the restricted domain. I've found other references on doing
that; but, there are no examples on how to use types loaded from that
assembly in the correct domain. Does all access to anything in that domain
have to be marshaled?

For example, some of Shawn Farkas' examples mandate that in order to truly
load the assembly in another domain CreateInstanceAndUnwrap needs to be
called on an internal class and have a method of that class load the
assembly. This seems to work fine; the assembly is loaded within the correct
AppDomain and execution of a method of a type loaded from that assembly is
executed within the correct domain. But, if that type is returned back from
the assembly loader class we're back into the original domain and any calls
into that assembly loaded into a restricted domain are not restricted.

I'm assuming this is because the type has been marshaled back into the
calling domain; which really defeats the purpose of an assembly loader class.

Through trial and error I've found that the permissions required to even
load a type from an assembly are as follows:
FileIOPermission(FileIOPermissionAccess.Read |
FileIOPermissionAccess.PathDiscovery, assemblyDirectory)
FileIOPermission(FileIOPermissionAccess.Read,
System.Runtime.InteropServices.RuntimeEnvironment.SystemConfigurationFile)

For that assembly to do anything else may (probably) requires more
permissions--which are wholly undocumented. For example, given the above
permissions a call to System.Diagnostics.Debug.WriteLine() causes a security
exception; but Diagnostics, Debug, and WriteLine (in 1.1) make no mention of
permission requirements.
 
Hi

Based on my research, it seems that there are no such a complete sandboxing
example to fully address your concern.
Although the blog is discussing the .NET 2.0, the principle is of the same.

Also commonly we did not want the the sandboxing environment to interact
with other assembly.
e.g. Assembly load in AppDomain A, our application loaded in domain B.
If we allow certian method in AppDomain A to call the method in AppDomain
B. Because B have more rights than A, there will be security vulnerable.

The communication between appdomains is using Remoting which is a mechanism
introduced by .NET.
Here is a sampe for your reference.
Plug-in Manager
https://secure.codeproject.com/csharp/DynamicPluginManager.asp

For the detailed information about .NET Security, please post in the .NET
security group.
microsoft.public.dotnet.security

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top