Securing assembly/dlls - unable to add secured component in design time

  • Thread starter Thread starter sudhakar
  • Start date Start date
S

sudhakar

Hi

I'm using linkdemand
(System.Security.Permissions.SecurityAction.LinkDemand)with
strongnameidentitypermission to secure my dlls. If i try to add a component
(say an user control which is secured in the above fashion) to a windows
form, in the DESIGN time, I'm getting a security exception. However, there's
no problem when i run the application. Is there anyway i can add the
usercontrol in the design time without getting the security exception (any
other appropriate SecurityAction parameter, perhaps ?? )?

Thanks

-sudhakar
 
When you place a link demand with the strong name identity on a control
and add that control to a winform app the designer will try to create
an instance of the application. This causes the CLR to verify the link
demand and make sure that the calling designer has the same strong name
identity. Obviously this fails as the designer has a completely
different strong name identity.

Unfortunately if you are securing your code using strong name it isnt
possible to use it in the designer as it is always gonna raise a
security exception.

NuTcAsE
 
sudhakar said:
Hi

I'm using linkdemand
(System.Security.Permissions.SecurityAction.LinkDemand)with
strongnameidentitypermission to secure my dlls.

Identity permission (including StrongNameIdentityPermission) verifications
are easily bypassed or spoofed by highly privileged (e.g.: fully trusted)
code, so you should not rely on them to block potentially unwanted callers.

If i try to add a component (say an user control which is secured in the
above fashion) to a windows form, in the DESIGN time, I'm getting a
security exception. However, there's no problem when i run the
application. Is there anyway i can add the usercontrol in the design time
without getting the security exception (any other appropriate
SecurityAction parameter, perhaps ?? )?

I can think of only two possible approaches:

1. Instead of using declarative security via attributes, use imperative
security, and only demand the permission if the control is not in design
mode. Of course, this won't work with link demands since these can only be
applied via attributes, and full demands don't generally work particularly
well with Windows Forms controls due to the Microsoft code on the stack.

2. Create a custom permission attribute similar to
StrongNameIdentityPermissionAttribute that only creates the corresponding
StrongNameIdentityPermission if design mode is not detected. Unfortunately,
this would be trivial to bypass since the attribute will only be applied if
its assembly is properly registered as a trusted policy assembly; otherwise,
it's simply ignored.

All in all, licensing is a generally better solution to the problem you are
trying to address.
 
Back
Top