Re: Refresh .Net Framework policy
From: Nicole Calinoiu (calinoiu)
Date: Thu, 8 Sep 2005 10:43:37 -0400
There are a couple of possible problems here:
1. If the host application (IEHost?) remains loaded during the policy
modification, it will not pick up the change. You should ensure that the
host application is entirely stopped then restarted after the policy
modification. (For initial testing purposes, I'd recommend a full reboot in
order to verify whether this is really the problem or not.)
2. If you are hosting in IE, using a strong name membership condition for
your code group will not be sufficient. See
http://blogs.msdn.com/shawnfa/archive/2003/06/26/57026.aspx for details and
BTW, there are also a couple of somewhat iffy practices in your policy
1. You should at least add the new code group under the zone from which the
target assembly will be run. (See
http://blogs.msdn.com/shawnfa/archive/2004/09/09/227534.aspx for an example
of how to do this.) The more specific you are about the membership
condition(s), the less likely your code group can be used by an attacker to
escalate privilege of other assemblies.
2. There's no need for your "allCodeMC" membership condition. Just use the
real target membership condition (in this case the "temp"
StrongNameMembershipCondition) from the start. Otherwise, a very small (and
potentially accidental) edit to your code could land the user with a very
undesirable modification to their CAS policy.
"tanguy" <firstname.lastname@example.org> wrote in message
> This is the applied code to allow the dll to be executed...
> IEnumerator levels = SecurityManager.PolicyHierarchy();
> while (levels.MoveNext() &
> PolicyLevel level = (PolicyLevel)levels.Current;
> IEnumerator sets = level.NamedPermissionSets.GetEnumerator();
> AllMembershipCondition allCodeMC = new AllMembershipCondition();
> PermissionSet myPermissionSet = new NamedPermissionSet("FullTrust");
> PolicyStatement ps = new PolicyStatement(myPermissionSet);
> string keyStr = "0024[...]8b4";
> byte key = new byte[keyStr.Length / 2];
> for(int index = 0; index < key.Length; ++index)
> key[index] = byte.Parse(keyStr.Substring(index * 2,
> StrongNameMembershipCondition temp = new
> System.Security.Permissions.StrongNamePublicKeyBlob(key), null, null);
> CodeGroup cg = new UnionCodeGroup(allCodeMC, ps);
> cg.MembershipCondition = temp;
> cg.Description = "MailMerge Applet";
> cg.Name = "DW";
> "Nicole Calinoiu" a écrit :
>> "tanguy" <email@example.com> wrote in message
>> > Hi,
>> > I need some info after strange behavior from .Net Framework security
>> > update...
>> > I developed an activeX in C# (ie: a dll) and I need now to allow this
>> > activeX to run on the client computers without any manual action (such
>> > as
>> > configure the .Net framework policy). I create an exe file which update
>> > framework policy for my dll (using its public key) with full trust
>> > access.
>> > The strange behavior is the following:
>> > When I apply the security policy update, my activeX doesn't display...
>> > Some
>> > times after (I don't know exactly how many), the ActiveX can be
>> > displayed...
>> > If I remove the dll security policy, the activeX can still display for
>> > a
>> > certain time...
>> How exactly does your executable modify the policy? (i.e.: What policy
>> changes does it make and what approach does it use to effect these
>> > So my question are :
>> > - How the .Net framework refresh itself ?
>> It doesn't.
>> > how often ?
>> Policy is only modified when triggered by an external process.
>> > - How can I be sure that the policy is well applied ? it's not really
>> > clear
>> > for me...
>> That depends on how you're modifying the policy...