Refresh .Net Framework policy

7 Sep 2005 9:36 AM

tanguy

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...

So my question are :

- How the .Net framework refresh itself ? how often ?

- How can I be sure that the policy is well applied ? it's not really clear
for me...

Thanks for your help ;)

7 Sep 2005 2:40 PM

Nicole Calinoiu

Show quote Hide quote

"tanguy" <tan***@discussions.microsoft.com> wrote in message
news:D8FE90C7-8A05-4086-B844-DE01050CFD80@microsoft.com...
> 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 changes?)

> 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...

7 Sep 2005 3:05 PM

tanguy

This is the applied code to allow the dll to be executed...

IEnumerator levels = SecurityManager.PolicyHierarchy();

            while (levels.MoveNext() &
!(((PolicyLevel)levels.Current).Label=="Machine"))
            {}

            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,
2),System.Globalization.NumberStyles.HexNumber);
            }

            StrongNameMembershipCondition temp = new
StrongNameMembershipCondition(new
System.Security.Permissions.StrongNamePublicKeyBlob(key), null, null);
            CodeGroup cg = new UnionCodeGroup(allCodeMC, ps);
            cg.MembershipCondition = temp;
            cg.Description = "MailMerge Applet";
            cg.Name = "DW";
            level.RootCodeGroup.AddChild(cg);
            SecurityManager.SavePolicy();

"Nicole Calinoiu" a Ã©crit :

Show quoteHide quote

> "tanguy" <tan***@discussions.microsoft.com> wrote in message
> news:D8FE90C7-8A05-4086-B844-DE01050CFD80@microsoft.com...
> > 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 changes?)
>
>
> > 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...
>
>
>

8 Sep 2005 2:43 PM

Nicole Calinoiu

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
alternate approaches.

BTW, there are also a couple of somewhat iffy practices in your policy
modification:

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.

Show quoteHide quote

"tanguy" <tan***@discussions.microsoft.com> wrote in message
news:0B1AA40A-FC1F-4710-9022-0F52A1ED3B3C@microsoft.com...
> This is the applied code to allow the dll to be executed...
>
> IEnumerator levels = SecurityManager.PolicyHierarchy();
>
> while (levels.MoveNext() &
> !(((PolicyLevel)levels.Current).Label=="Machine"))
> {}
>
> 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,
> 2),System.Globalization.NumberStyles.HexNumber);
> }
>
> StrongNameMembershipCondition temp = new
> StrongNameMembershipCondition(new
> System.Security.Permissions.StrongNamePublicKeyBlob(key), null, null);
> CodeGroup cg = new UnionCodeGroup(allCodeMC, ps);
> cg.MembershipCondition = temp;
> cg.Description = "MailMerge Applet";
> cg.Name = "DW";
> level.RootCodeGroup.AddChild(cg);
> SecurityManager.SavePolicy();
>
> "Nicole Calinoiu" a écrit :
>
>> "tanguy" <tan***@discussions.microsoft.com> wrote in message
>> news:D8FE90C7-8A05-4086-B844-DE01050CFD80@microsoft.com...
>> > 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
>> changes?)
>>
>>
>> > 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...
>>
>>
>>