.NET Code Access Security: ¿Útil o simplemente complicado?

Question

  

vea también Is & # 8220; Código de acceso Seguridad & # 8221; de   ¿Algún uso en el mundo real?

Quiero obtener otras opiniones sobre esto ...

Me gusta la idea de Code Access Security para aplicaciones de escritorio. Pero en la vida de .NET tengo que admitir que nunca he tenido una situación en la que CAS haya bloqueado algo en mi beneficio.

Sin embargo, he tenido muchas veces que algo tan simple como compartir una aplicación .NET rápida a través de una unidad asignada se convierte en una pesadilla de acceso al código empresarial. Tener que romper caspol.exe para crear reglas de ruta confiables y no tener una forma clara de saber por qué algo falló hace que parezca que CAS agrega mucha más frustración al proceso de desarrollo e implementación de lo que ofrece en seguridad.

Me gustaría escuchar algunas situaciones en las que CAS realmente ha ayudado más que perjudicar, o si hay otras personas frustradas con su implementación actual y los valores predeterminados.

Answer 1

El equipo .NET ellos mismos han llegado a la misma conclusión de que la seguridad de acceso al ensamblado se está modificando para .NET # 4. Echa un vistazo a este blog para más información: .NET Blog de seguridad

Answer 2

¡Aquí, aquí! He compartido muchas de las mismas frustraciones. Y, por supuesto, la complicación excesiva y la documentación horrible básicamente alientan a los desarrolladores a evitarla o usar reglas demasiado amplias. La seguridad siempre será una locura para cualquiera, pero CAS es realmente difícil de hacer bien.

Answer 3

Tuve que lidiar con CAS, pero no fue demasiado difícil ya que solo tuve que implementarlo en una docena de estaciones de trabajo más o menos. También puede eliminar la configuración requerida a través de la Política de grupo.

Pero para responder a su pregunta, no, creo que nunca ayudó.

Sin embargo, mire el lado positivo, comenzando con .NET 3.5 puede ejecutar aplicaciones en un recurso compartido de red sin CAS.

Answer 4

Después de mucha búsqueda, me topé con esta entrada del blog del equipo de CLR que no solo confirma que CAS va a desaparecer en .NET 4, sino que también brinda una excelente guía sobre qué se romperá y cómo migrar hacia el nuevo modelo de caja de arena: Nuevo modelo de seguridad: mudarse a un sandbox mejor . Del artículo:

  

En versiones de .Net Framework anteriores   v4, teníamos muchas formas de restringir   permisos de una asamblea o incluso   cierta ruta de código dentro del ensamblado:

     

  

1. Modificadores de desplazamiento de pila: Denegar, Permitir solo

  

2. Solicitudes de nivel de ensamblado: RequestOptional, RequestRefuse,   RequestMinimum

  

3. Cambios de política: caspol y AppDomain.SetPolicyLevel

  

4. Carga de un ensamblaje con una zona que no sea MyComputer

  

     

En el pasado, estas API han sido   fuente de confusión para el anfitrión y   escritores de aplicaciones. En .Net Framework   4, estos métodos de restricción   los permisos están marcados como obsoletos y nosotros   espero eliminarlos en un punto en el   futuro.

Lo más angustiante es el hecho de que todos estos métodos obsoletos de crear un sandbox comenzarán a arrojar un NotSupportedException. Esto es excepcionalmente precario para las almas pobres (como yo) que, por cualquier razón, están obligadas a implementar CAS en su organización en este momento. Has sido advertido.