Avoiding adding another code group

Rodney · Jan 26, 2004

I have an application that has been deployed at a client site where it
runs under a strong-named security context (it lives on the LAN – is
not installed on each machine, thus all assemblies must be signed and
added to a code group on each client machine's runtime security
policy).

I now want to deploy an upgrade that uses a third-party component not
used in the first deployment. I expect to have to add a new
code-group to the runtime security policy on each client machine so
the assembly can be called by my app.

I was wondering if there was any way that the referenced assembly's
public key is somehow pre-approved in the main assembly's manifest so
only the main assembly's public key needs to be known by the
framework. It would greatly simplify deployment where many
third-party components each have a different public key.

Shawn Farkas · Jan 27, 2004

Hi Rodney,

There is no way to "pre-approve" a public key, however you could do one of two things. Since your app is already trusted, you could
programatically modify the security policy to include the third party's public key at startup. You could also Assert for the trust that the 3rd party
needs (with the standard disclamers about being very careful with asserts applying). Feel free to post back if you need details on either of these
methods.

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------

Rodney · Jan 29, 2004

Thanks Shawn - I am not familiar with either of these methods, could
you please give more information.
Many thanks,
Rodney.

Shawn Farkas · Feb 3, 2004

You're going to have to modify the policy on each user's machine in order to trust this third party dll. You could do this through caspol:

caspol -ag 1. -strong 3rdparty.dll -noversion FullTrust

Or you can write a bit of bootstrap code at the beginning of your application that catches the security exception thrown by this third party dll and
modifies the security policy to allow trust to the dll. However, doing this will require that after the policy is changed, your application be restarted.
The class you're going to need to use in order to do this is System.Security.SecurityManager. You can use its PolicyHierarchy() method to get an
enumerator over the PolicyLevel's on the current machine. When you find the machine level (Where all the policy is currently stored), you can then
create a UnionCodeGroup object, using a StrongNameMembershipCondition object as its membership condition, and a PermissionSet
(PermissionState.Unrestricted) permission set as its permissions. After adding the code group, you could then call SecurityManager.Save() to
save the modified policy, and prompt your users to restart the application.

Another option would be to create the desired policy on your machine, and then using the .Net Framework Configuration Wizards, export the policy
to a .MSI file that all of your users could then install.

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------

Chris Capel · Feb 3, 2004

"Shawn Farkas" said:
You're going to have to modify the policy on each user's machine in order

to trust this third party dll. You could do this through caspol:

caspol -ag 1. -strong 3rdparty.dll -noversion FullTrust

Or you can write a bit of bootstrap code at the beginning of your

application that catches the security exception thrown by this third party
dll and

modifies the security policy to allow trust to the dll. However, doing

this will require that after the policy is changed, your application be
restarted.

The class you're going to need to use in order to do this is

System.Security.SecurityManager. You can use its PolicyHierarchy() method
to get an

enumerator over the PolicyLevel's on the current machine. When you find

the machine level (Where all the policy is currently stored), you can then

create a UnionCodeGroup object, using a StrongNameMembershipCondition

object as its membership condition, and a PermissionSet

(PermissionState.Unrestricted) permission set as its permissions. After

adding the code group, you could then call SecurityManager.Save() to

save the modified policy, and prompt your users to restart the application.

Another option would be to create the desired policy on your machine, and

then using the .Net Framework Configuration Wizards, export the policy

to a .MSI file that all of your users could then install.

-Shawn
http://blogs.msdn.com/shawnfa

message are best directed to the newsgroup/thread from which they

Chris Capel · Feb 3, 2004

If the application lives on the LAN, I think a much easier way to deploy is
to assign trust not to the assemblies' key, but to the URL which they're run
from. We do no-touch deployment using many different third-party tools, and
as long as they don't require some sort of COM registration (no normal .NET
component will [Crystal reports is not a normal .NET component] ) nothing
needs to be done to the client in order to give trust to the new assemblies,
since they're located in the trusted location. This is somewhat less secure
than assigning trust to the strong key, but more than secure enough for our
software, which is a banking package that handles data processing, reports,
and document imaging. Really, I don't see any advantages to using the strong
key instead of the location, unless you're really paranoid about security,
but I could be missing something, so no offense.

Chris