.net security code-access-security

.net - ¿El "Código de acceso de seguridad" de cualquier uso del mundo real?



security code-access-security (8)

Advertencia:

Las versiones más recientes de .Net y .Net core han eliminado y / o cambiado "Code Access Security" (CAS) desde que se hizo esta pregunta.

Pregunta Original:

Estoy en el proceso de estudiar para el 70-536 .NET Framework - Application Development Foundation Exam , ya que he estado programando .net durante muchos años, ¡esto no debería ser difícil!

Sin embargo, tengo que aprender sobre "Code Access Security" (CAS), ya que nunca tuve la necesidad de usarlo o configurarlo, me preguntaba si alguien más ha encontrado un uso real para él.

Proporcione ejemplos de cuándo ha utilizado CAS y ha sido parte de la solución en lugar del problema.

(Hasta ahora todo lo demás ha tenido alguna relación con la tarea que he tenido que hacer en mis años de programación .NET)

Preguntas relacionadas:

Resultados hasta el momento.

  • CAS es útil cuando aloja código de terceros. Por ejemplo, una empresa de alojamiento web puede usarlo para evitar que el código Asp.net de sus clientes dañe los servidores. (Office también lo usa cuando .NET se utiliza como reemplazo de VBA)

  • El único ejemplo detallado de que se usa fuera de una aplicación de Microsoft hasta ahora es:

    Un proyecto reciente que hice tenía algo similar: permitir que el usuario cargue una biblioteca y probar su rendimiento ("quién hace el mejor algoritmo"). No hace falta decir que necesitábamos CAS mucho allí.

  • CAS parece ser útil para obtener la certificación JITDC, que es como el departamento de defensa de EE. UU., Sin embargo, no sé si CAS tenía algún valor real, o si solo se trataba de marcar el casillero.

(Si necesita eludir un host que usa CAS y tiene derechos de administrador en la máquina, puede simplemente colocar sus ensamblajes en el GAC).

De cara al futuro, CAS es un poco menos complejo en .net 4 .

Al menos parece que los nuevos exámenes de Microsoft no tendrán un examen de "fundación" que incluya CAS. No sé si se incluirá en los nuevos exámenes de Winforms / WPF.

Aunque nunca lo he usado, mi comprensión de CAS era que también se podía usar para expandir la mecánica de diseño orientada a objetos. Por ejemplo, supongamos que está desarrollando un paquete masivo de acceso a datos para un banco que debe implementar el acceso a la base de datos y el almacenamiento en caché. Aunque forman parte del mismo paquete de implementación, dado el tamaño hipotético del proyecto, la lógica debe implementarse en ensamblajes separados ya que son conjuntos de problemas suficientemente diferentes que dependen de diferentes fuerzas externas (infraestructura de base de datos frente a uso del consumidor).

Sin embargo, el código de almacenamiento en caché podría necesitar acceder a algunas clases o métodos sensibles en el conjunto de acceso a datos a los que los consumidores del paquete general no deberían tener acceso. Por lo tanto, estas clases y métodos de acceso a los datos no pueden ser simplemente public . Los métodos protegidos en el conjunto de acceso a datos con subclases en el conjunto de almacenamiento en caché podrían solucionar algunos casos, pero muchas veces es un abuso de herencia. Simplemente podría ser más elegante dejarlos public con LinkDemands colocados en las personas que llaman para un permiso personalizado (por ejemplo, DataPackagePermisson ) que los administradores solo otorgarían al ensamblado de almacenamiento en caché.

Fui el líder de desarrollo en un proyecto para obtener la certificación JITC (Departamento de Defensa de EE. UU.) Para una solución basada en .NET, y la configuración de CAS se examinó muy de cerca durante las pruebas de certificación.

Como la mayoría de los demás requisitos de certificación, el código solo podía usar los privilegios necesarios para funcionar y nada más.

Si planea obtener certificaciones de seguridad, CAS definitivamente puede ser importante.

Lo que hay que entender sobre Code Access Security es que es de muy poca utilidad para un desarrollador de aplicaciones más allá de comprender cómo se usa y a qué nivel de permisos de las API puede estar llamando. La única excepción a esto, que realmente he encontrado útil es un CAS llamado PrincipalPermission, básicamente no permite que se ejecute cierto código si el Rol correcto no está definido para el Principal actual. Ver esta publicación en él:

http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/

Los desarrolladores que realmente necesitan prestar atención a CAS y cómo debe implementarse en su aplicación son los desarrolladores de la arquitectura de código y código. Debido a que hay ciertos niveles de confianza que necesita exigir para que su aplicación funcione, especialmente cuando se trata de recursos no administrados, como archivos, flujos de red, puertos serie, etc. O si está creando el código para ese recurso no administrado, como algunos speicalized servidor, o cualquier tipo de acceso de bajo nivel en sus ensamblajes, querrá crear algo de seguridad de acceso a los códigos para que las personas no puedan ejecutar algo que se les ha negado estrictamente.

No ayuda que Microsoft realmente no haya hecho tan buen trabajo explicando cómo debe usarse CAS en la aplicación diaria. Entonces esa es realmente la razón de la falta de uso. Sin embargo, CAS es una de las muchas razones por las que .NET es un lenguaje tan seguro y tiene muchos menos problemas que sus competidores.

Me encuentro con la seguridad de acceso al código con bastante frecuencia en el "mundo real", a menudo cuando menos lo espero. Y, en cierto modo, SilverLight sería una aplicación excelente en el mundo real, si no fuera porque SilverLight decidió no emplear CAS en absoluto al final.

Proveedores de alojamiento

Los lugares donde lo ve en acción es donde se necesita un entorno seguro: ASP.NET sí mismo, por supuesto, pero los proveedores de alojamiento ASP.NET utilizan un modelo de seguridad modificado para evitar la intrusión en sus sistemas preciosos. Sé con certeza que Webhost4Life usa esto (no hay información en su sitio al respecto, pero he trabajado con ellos, está allí, realmente). Mirando más allá, otros proveedores de hosting ASP.NET hacen lo mismo, pero tampoco lo tienen muy claro: thread en godaddy.com no quiere cambiar el CAS (y no aclara qué es compatible y qué no) o este debate relacionado en 1 y 1 . Algunos sitios de alojamiento en la nube (rackspacecloud) lo llevaron un poco más allá y "trabajaron con Microsoft para obtener un nivel de confianza total modificado" cualquiera que sea.

En resumen: si encuentra un host ASP.NET, lo más probable es que haya usado CAS para evitar que haga cosas que no quiere que haga. Incluso pueden usarlo para diferenciar entre alojamiento "básico" (muchas restricciones) y alojamiento "empresarial" (pocas restricciones), lo que le da un significado completamente diferente a CAS.

Otras aplicaciones de CAS

Tanto para algunas situaciones del mundo real que me encontré a mí mismo. Un proyecto reciente que hice tenía algo similar: permitir que el usuario cargue una biblioteca y probar su rendimiento ("quién hace el mejor algoritmo"). No hace falta decir que necesitábamos CAS mucho allí. Otros ejemplos o recursos interesantes:

  • NAR Loader (una aplicación de proyecto de código) usa su propio CAS
  • LR Evaluator (también aplicación codeproject) usa CAS
  • ClickOnce (ver a continuación) usa CAS
  • Patrones de diseño de CAS : su popularidad "asume" que CAS se está utilizando
  • Comprender CAS : incluso una mayor popularidad y algunos comentarios implican aplicaciones
  • Microsoft SharePoint usa CAS hasta el final, parece (lo siento, no soy especialista en SP)

Para cualquier situación en la que simplemente usted tenga el control total, construya su propia aplicación y código (o lo construya) y tenga el control total de su sistema, no creo que necesite CAS demasiado a menudo. Es más algo que usaría en el momento en que tenga que ejecutar código de fuentes de menor confianza (que es básicamente todo lo que no está bajo su control).

CAS frente a ClickOnce

La configuración predeterminada de CAS limita las capacidades del código ejecutado desde un recurso compartido de red u otras fuentes no locales. Esto tiene sentido, pero las estrictas restricciones dificultan tener un repositorio central para la aplicación distribuida. .NET 2.0 introdujo ClickOnce, que se suponía que elevaría la seguridad ( discusión aquí ).

ClickOnce utiliza CAS para evitar que el instalador llame a las funciones del sistema. Como tal, creo que es posiblemente la aplicación mejor conocida que se basa en CAS .

El punto es: necesitas entender CAS para poder crear algo que pueda ejecutarse directamente desde un recurso compartido, o lo ignoras todo y usas ClickOnce.

Encuesta de Microsoft sobre CAS

En 2005, Microsoft convocó una encuesta para descubrir por qué CAS era tan impopular, con la esperanza de mejorarlo para hacerlo mejor aplicable. Lamentablemente, no pude encontrar los resultados reales de la encuesta, aparte de esta publicación que detalla por qué CAS está infrautilizado.

CAS en otro mundo

Esa publicación, sin embargo, apunta a un nicho intrigante: CAS aplicado a otro mundo: Unix / Linux. No lo llaman CAS, en cambio es BitFrost . ¿Cómo es eso para una aplicación en el mundo real: el proyecto "One Laptop Per Child" , que se basa en BitFrost como un reemplazo para el modelo de seguridad tradicional de Unix.

Actualización: sección sobre CAS en Unix / Linux como BitFrost y sección sobre encuesta.
Actualización: agregado CAS frente a la sección ClickOnce
Actualización: lista de recursos añadida usando CAS (¡y disculpas por todas estas actualizaciones seguidas!)

Nota para el lector: vea los dos comentarios a continuación; parece que estoy inflando accidentalmente la definición de CAS para (incorrectamente) incluir RBS. Dejaré la respuesta aquí para referencia, pero tenga en cuenta la distinción.

Hay dos términos para CAS; lo que más verá en ese examen son todos los matices para codificar el código de otro código, que puede ser útil para la confianza parcial, pero la mayoría de las veces es simplemente un dolor, y lo que es peor: si su código tiene plena confianza ( que más / demasiado hace) nada de esto realmente se ejecuta (se omite por completo).

La parte útil de CAS RBS es el permiso principal, que se utiliza; por supuesto, su UI debe verificar el acceso a las características, pero puede poner (en su lógica de baja-baja):

[PrincipalPermission(SecurityAction.Demand, Role = "ADMIN")] static void DeleteOrder(int id) { ... }

Esto se aplicará incluso con plena confianza; puede definir su propio principal (vinculado al usuario) mediante la implementación de IPrincipal (consulte IsInRole() ). Y dado que los principales son compatibles en la mayoría de los entornos (winforms, webforms, mvc, wcf, etc.) esto puede brindar una manera muy flexible de verificar dos veces la seguridad en la capa de negocios sin tener que hacer referencia al modelo de seguridad específico . Tenga en cuenta que la verificación anterior funcionaría en cualquier entorno.

También puede usar esto para conducir su UI. Tenía una publicación de Usenet que habilitaba / deshabilitaba los controles de winforms basados ​​en el director (usando propiedades de tiempo de ejecución para especificar el rol por control, un poco como ToolTip etc.) - No puedo encontrarlo en el minuto, sin embargo (editar: tal vez esto uno ).

Técnicamente, es muy útil ya que permite una especificación de permisos de grano muy fino. Esto es bueno para usted (ya que teóricamente hace que explotar las vulnerabilidades de seguridad sea mucho más difícil, incluso si un atacante obtiene control total de su aplicación, todavía está bloqueado en el CAS Sandbox) y para su cliente (ya que pueden ver exactamente cuál es su aplicación puede hacer y ejecutar su propia auditoría de seguridad).

En el uso práctico, es casi sin sentido. Creo que es demasiado complejo, muy poco soportado por las herramientas de desarrollo disponibles y a la mayoría de los usuarios no les importa de todos modos.

Hay excepciones, por supuesto (gobiernos y clientes que realmente conocen .net / CAS) y me gustaría decir que CAS es absolutamente útil y obligatorio, pero la realidad habla un lenguaje claro.

Una cosa que debes saber es que Code Access Security está prácticamente roto como método de protección contra manipulaciones. Ver:

CAS Tamper-Proofing está roto: Consecuencias para la concesión de licencias de software

...

Ya no se puede confiar en Code Access Security para evitar el uso de ensamblajes manipulados en productos enviados. Esto significa que si su aplicación depende de Code Access Security para realizar comprobaciones de licencia, es trivial que un atacante reemplace su ensamblaje de licencia por otro, lo que le permite obtener acceso gratuito a su aplicación.

...

Usamos CAS para nuestras aplicaciones no fue realmente difícil, ya que solo habíamos intentado detener la ejecución de código no-humanizado. Surgieron problemas una vez que usamos nuestro software desde el recurso compartido de la red local, pero una política informal eliminó el problema.

  1. Aseguramos todas nuestras asambleas usando un nombre fuerte.
  2. Creamos una política cas para todos los ensamblajes con nuestro nombre fuerte y código permitido firmado con nuestro nombre fuerte para comenzar desde la red de área local y el código colocado localmente.
  3. Ensamblados cargados desde la red de área local que necesitan acceso de archivo local (componente para grabar CD de datos) necesarios para obtener el atributo de demanda de enlace en todas las clases públicas.

Desde la actualización de .NET3.5 nuestros problemas ya no existían, ya que el código en la red de área local se maneja ahora como código local.