¿Debería mezclar mi código de seguridad con mi código inseguro?

Question

Estoy trabajando en un proyecto que utiliza un montón de llamadas API WIN32 y requiere algún código inseguro. Desde el punto de vista de las mejores prácticas, ¿debo aislar este código en su propia DLL compilada con el interruptor/inseguro mientras se mantiene segura mi aplicación principal?

Para decirlo de otra manera. ¿Hay alguna razón para no compilar un proyecto con el modificador/inseguro? ¿Hay algún riesgo potencial?

Answer 1

Un conjunto es, por definición, la unidad más pequeña de código redistribuible, de versión independiente en .NET. Por lo tanto, la primera pregunta que me haría es "¿Alguna vez querré crear una nueva versión del código inseguro y distribuirlo independientemente de mi aplicación?"

Si la respuesta es sí, entonces, por supuesto, ponga ese código en su propio conjunto.

Si la respuesta es no, entonces considere otros factores. Por ejemplo, en la seguridad .NET "clásica", puede tener diferentes ensamblados ejecutándose en diferentes niveles de confianza en el mismo dominio de aplicación. (En el CLR moderno, el sistema es mucho más simple, solo hay un código completamente confiable y todo lo demás se ejecuta en el nivel de confianza otorgado al dominio de aplicación). El código que hace algo inseguro debe ser completamente confiable, pero el código simplemente llama podría ser menos confiable si el código inseguro confirma el conjunto correcto de permisos.

¿Alguna vez se encontrará en una situación en la que se confíe parcialmente en su código de seguridad? Si es así, entonces, por supuesto, coloque el código inseguro en su propio ensamblaje y luego documente que este ensamblado debe ser completamente confiable.

Si no estás en ese tipo de situaciones, entonces no me inclinaría a poner mi código inseguro en su propio conjunto.

Sin embargo, me inclinaría a escribir un modelo de objeto administrado agradable encima de mi código no administrado, en lugar de simplemente exponer las llamadas crudas de win32. Por ejemplo, el otro día necesité llamar algunas de las firmas de win32 de verificación de nombres fuertes de C# y simplemente abrí una pequeña biblioteca que las exponía muy bien, abstrayendo todos los desagradables detalles de interoperabilidad al interior privado de la clase.