Re: Refresh .Net Framework policy

From: Nicole Calinoiu (calinoiu)
Date: 09/08/05


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

"tanguy" <tanguy@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" <tanguy@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...
>>
>>
>>



Relevant Pages

  • Re: CAS Policy issue
    ... If enterprise-specified CAS restrictions are set at the enterprise policy level, neither the machine nor user levels will be able to override the restrictions to grant additional permissions. ... Any given code group can be marked as exclusive, which will prevent code that meets the code group membership conditions from being granted any additional permissions via other groups. ... I'd really like the option to prevent the control from loading at child B level, but it seems with child C full trust, this is not possible. ... If you're trying to troubleshoot CAS permission problems, I'd recommend resetting your CAS policy. ...
    (microsoft.public.dotnet.security)
  • Re: Creating code groups | Setup project
    ... add a class lib to the installer project - and include its primary output ... throw new ApplicationException("Failed to find the machine policy ... // add our named permission set to the machine policy level ... // now we need to create a code group that matches all assemblies ...
    (microsoft.public.dotnet.security)
  • Re: assign permission set
    ... policy it does so at some risk. ... If an msi install will work for you, ... The .NET Framework Configuration tool generates a Microsoft installer ... >> code shows how to programmatically replace the trusted zone code group. ...
    (microsoft.public.dotnet.security)
  • Security Policy, Code Groups and Security Tools.
    ... membership conditions specified within each code group. ... When an assembly belongs to multiple code groups, permissions assigned by ... another code group when they are both part of the same Policy level. ...
    (microsoft.public.dotnet.languages.csharp)
  • Security Policy, Code Groups and Security Tools.
    ... membership conditions specified within each code group. ... When an assembly belongs to multiple code groups, permissions assigned by ... another code group when they are both part of the same Policy level. ...
    (microsoft.public.dotnet.framework)