TAM v2.1 Sandboxing – Part II – Risk Measurement Plug-in
TAM v2.1 introduces a new security model for the plug-in under which the behavior of the plug-in can be controlled by the user. TAM v2.1 allows user to configure the permission set which is granted to the plug-in when it is loaded. From a usability perspective this has to be simple and effective for user to manage. Thus TAM allows users to select either “Internet”, “Intranet” or “My Computer” permission set in the options dialog where a plug-in is selected (TAM defaults it to “Internet”). The selected permission set will be loaded from the .NET Framework computer security policy. The following piece of code illustrates the permission set loading.
PermissionSet oPSet = new PermissionSet(polLevel.GetNamedPermissionSet(permissionSetName));
TAM takes this restricted permission set and uses it to create a separate app domain and loads the plug-in in that. As this is a restricted permission set, by default the permission to read the plug-in file will be denied and TAM will get a security exception if it tries to load the plug-in. For this purpose, TAM adds read-only permission to the plug-in file which will avoid the security exception. Apart from that it also gives PathDiscovery and Read permissions to the folder in which the plug-in resides. The following code illustrates the restricted app domain creation.
oPSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.Read,<pluginfile>);
oPSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.Read | FileIOPermissionAccess.PathDiscovery, <pluginfolder>));
AppDomain restrictedDomain = AppDomain.CreateDomain(domainName, null, oSetup, oPSet, null);
If we create a restricted app domain and load the plug-in directly into it, we will end up getting FileNotFound exceptions for the plug-in and its references, due to app domain base directory issues. It has partly to do with how .NET Framework handles app domain assembly resolving, etc. Additionally we will also get exceptions when we try to interrogate the plug-in for the TAM risk interface. In order to avoid this, we create a worker class which loads the plug-in. The worker class is responsible for loading the plug-in and interrogating the plug-in for interfaces and returning an instance of the plug-in class. The plug-in worker class will be loaded in the restricted app domain and it is responsible for loading the plug-in and returning the plug-in object. That is the reason all of the exposed classes in the plug-in needs to inherit MarshalRefByObject as TAM uses the instance of the class to invoke the methods.
In summary, TAM performs three important steps to load the plug-in under restricted permissions.
1. Creates a restricted permission set (TAM)
2. Creates an app domain with the above restricted permission set (TAM)
3. Interrogates the plug-in for necessary interface and loads the plug-in (PluginWorker loaded under restricted app domain)
TAM does not perform all these steps, only step1 and step2 are done by TAM. Step 3 is handled by the plug-in worker class. .NET framework 3.0 makes it much easier to accomplish all this. For more information on the .NET Managed Add-in Framework (MAF), check https://blogs.msdn.com/jackg/archive/2005/09/15/468068.aspx.
Thanks
Anil Revuru (RV)