¿Hay alguna forma de bloquear el acceso de un complemento C# a la aplicación principal C# en un programa?

Question

Tengo un programa y una arquitectura de complemento simple donde los complementos implementan una interfaz genérica y el programa principal carga todos los complementos que implementan esta interfaz. Es la arquitectura de plugins personalizados más común que he encontrado hasta ahora, así que eso es lo que estoy usando.

No estoy usando el MEF de Microsoft y tengo mis razones para no hacerlo. Lo dejo así.

El problema es que cuando se cargan los complementos, no importa cuán "ciegos" sean para el programa principal y sus formularios/clases/etc. todavía puede acceder al System.Windows.Forms.Application y, por lo tanto, puede obtener acceso a mi aplicación y a sus formularios/métodos/controles/etc. actualmente en ejecución.

No quiero esto. ¿Hay alguna forma de restringir el acceso de un complemento a la aplicación principal?

EDIT: Más información sobre el plugin

Nosotros (mi jefe y yo) estamos discutiendo actualmente lo que tienen que hacer los plugins. Obviamente todos ellos necesitan agregar funcionalidad, pero originalmente decidimos darle acceso a cada complemento al formulario que se está ejecutando actualmente para que pueda agregar controles y eventos directamente al formulario. Esto se basó en la suposición de que solo nosotros, los desarrolladores, los escribiríamos.

Ahora estamos considerando la posibilidad de complementos de terceros y, obviamente, el diseño original tiene casi la misma seguridad que un letrero de "No ingresar" en una puerta abierta sin nadie a su alrededor.

O un cartel de "Take One" que cuelga de un bol de bolos individuales en Halloween.

Answer 1

Una forma de hacer esto es alojar sus complementos en sus propios AppDomains. Puede configurar estos AppDomains para tener una seguridad limitada para evitar que accedan a los recursos en el AppDomain principal. Esto complica mucho las cosas, pero te dará el sandboxing que buscas.

Un beneficio adicional que recibe del alojamiento de AppDomain es que puede cargar y descargar estos dominios si desea actualizar los complementos, además de que puede proteger su AppDomain principal de fallas en sus dominios "secundarios".

actualización

Luego de visitar la actualización de nuevo. las capacidades de su complemento, los AppDomains no ayudarán si su complemento debe tener acceso directo a los elementos de la interfaz de usuario, p. acceso a un formulario para agregar controles. No podrá dar acceso directo a un formulario sobre un límite de Dominio de aplicación, ni generar controles en un Dominio de aplicación y luego dirigirlos a otro.

Todavía podría considerar alojar plugins en otro AppDomain, pero deberá pensar en algún tipo de mecanismo proxy para que acciones como agregar un control a un formulario se puedan hacer en nombre de un complemento, en lugar de dejar el complemento accede al formulario directamente Por ejemplo, podría pasar un objeto generador de formulario que tenía métodos como AddButton. El proxy podría realizar estas acciones en nombre del complemento en el dominio principal. De esta forma, podría proporcionar una API limitada para el complemento completo con los eventos requeridos.

Este enfoque no es en absoluto trivial, pero una vez que domina los conceptos básicos, no es demasiado complicado.

Actualización 2

Las cosas han cambiado desde rodar sus propios marcos plugin con AppDomins vuelta en el día. En la actualidad es el apoyo al horno en el marco .Net desde 3.5 para plugins:

MAF - Managed Addin Framework/System.Addin

Es compatible con los modos de aislamiento de dominio de aplicación para los plugins y tiene cargadores de plugin, etc. No hay necesidad de liar.

Answer 2

Si puede ejecutar los complementos en su propio AppDomains, eso ciertamente aumentaría el nivel de aislamiento. Aunque también puede hacerles sentir dolor comunicarse con ellos. Sin saber más sobre lo que los plugins deben hacer, es difícil saber si es apropiado o no.

Answer 3

La mejor manera de manejar esto es exponer una API de complemento documentada. Si tus complementos se ejecutan con plena confianza, incluso si ejecutas el complemento en su propio Dominio de aplicación, puede volver a insertarse en la aplicación, entonces todo lo que necesita es que alguien ponga un contenedor disponible y todos los complementos regresen al mismo estado en el que se encuentran. comenzó en. Si su API permite que los complementos brinden las funciones deseadas de una manera directa, consistente y documentada, eso es lo que utilizarán los desarrolladores de complementos.

Los siguientes son ganchos de interfaz de usuario externos para WPF, Windows Forms y el clásico Spy ++ (todos con fuente).

• Snoop (the WPF Spy)
• Managed Spy
• .NET Object Spy and InvokeRemote
• Win Spy++

Answer 4

Así que para reafirmar su principal preocupación:

... y por lo tanto puede acceder a mi solicitud y es actualmente ejecuta formularios/métodos/controles/etc.

Antes de embarcarse en un medio complejo y difícil de cargar, aislar y restringir estas extensiones, debe saber algunas cosas sobre Windows y el CLR. En primer lugar, cualquier programa que se ejecute en la caja puede usar varias API de Windows para inyectar código en su proceso. Una vez que usted o el sistema operativo carga el código en su proceso, acceder al tiempo de ejecución de CLR y cargar ensamblajes y/o ejecutar código en su AppDomain existente es bastante fácil.

Sabiendo esto, debe pesar y equilibrar el esfuerzo que extrae para restringir las "extensiones". Si estuviera construyendo algo así, estaría más preocupado por otras cosas que una parte maliciosa del código de extensión que manipule el estado de mi aplicación. Por ejemplo estas son cosas que usted podría considerar:

1. extensiones de carga Sólo que son aprobados por el usuario, les permiten controlar lo que está permitido y les permiten revocar una extensión más adelante si lo desea. Mire Office o VStudio como ejemplo.
2. Asegúrese de que estas extensiones aprobadas no estén atenuadas mediante el uso de un requisito de firma de código (nombres seguros o certificados de firma de código).
3. Considere la posibilidad de revocar la capacidad de una extensión para ejecutarse de forma remota si se descubre que es maliciosa.
4. Demuestra una Interfaz API bien equipada para permitir a los desarrolladores implementar fácilmente el comportamiento deseado. Si les es fácil usar sus interfaces para realizar su tarea, no necesitarán 'hackear'.

Más allá de esto realmente no hay mucho más que pueda hacer. Como dije, cualquiera puede atacar su aplicación incluso con las protecciones anteriores. Su principal preocupación debe ser no sorprender a sus usuarios. Por lo tanto, es recomendable tener cuidado en qué código se ejecuta SU aplicación, pero lo que esas extensiones hacen una vez que los usuarios les otorgan acceso no es realmente algo que usted pueda controlar completamente.

Esto no quiere decir que un aislamiento AppDomain no le proporcione valor, puede; Sin embargo, en mi humilde opinión, obtener la seguridad lo suficientemente restringida sin limitar su capacidad de funcionar resultará difícil.

ACTUALIZACIÓN

... pero si se carga un plug-in en un dominio de aplicación, que está configurado con permisos limitados cómo puede utilizar este vector?

Correcto, como dije en mis declaraciones de cierre, puede limitar su acceso al código no administrado dentro de AppDomain. Esto también limita su capacidad de desarrollar una experiencia de Windows utilizable. Espero que la mayoría de las aplicaciones de WinForms usen al menos una llamada PInvoke o un control COM no administrado. Esta limitación impuesta puede ser aceptable, realmente no puedo decir sin más información sobre qué funcionalidad están tratando de proporcionar.

Todo lo que traté de decir es que al instalar y aprobar la extensión, los usuarios aceptan la responsabilidad de permitir que se ejecute esa extensión. Lo que hace esa extensión y cuán malicioso puede intentar ser no es su responsabilidad, suponiendo, por supuesto, que haya cargado el código correcto. Es por eso que recomiendo centrar su energía en ejecutar el código aprobado en lugar de preocuparse por lo que ese código podría hacer una vez que esté en proceso.