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

Question

ver también está “Code Access Security” of any real world use?

quiero conseguir algunos otros comentarios sobre esto ...

me gusta la idea de Código de Acceso de seguridad para aplicaciones de escritorio. Pero durante la vida de .NET tengo que admitir que nunca he tenido una situación en la que CAS haya bloqueado algo para mi beneficio.

Sin embargo, he tenido muchas veces en que algo tan simple como compartir una aplicación .NET rápida en una unidad mapeada se convierte en una pesadilla de acceso a código empresarial. Tener que romper caspol.exe para crear reglas de ruta confiables y no tener una manera clara de saber por qué algo falló, hace que parezca que CAS agrega mucho 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 a herir, o si hay otras personas frustradas con su implementación actual y sus valores predeterminados.

Answer 1

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

Answer 2

Aquí, aquí! He compartido muchas de las mismas frustraciones. Y, por supuesto, la sobre-complicación y la horrible documentación básicamente alientan a los desarrolladores a pasar por alto o usar reglas demasiado amplias. La seguridad siempre será una tuerca dura 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 expulsar 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, tenga en cuenta que a partir de .NET 3.5 puede ejecutar aplicaciones en un recurso compartido de red sin CAS.

Answer 4

Después de mucho buscar me topé con esta entrada del blog del equipo de CLR que no sólo confirma que el CAS se va en .NET 4, pero también da una gran guía de qué se romperá y cómo migrar hacia el nuevo modelo de espacio aislado: New Security Model: Moving to a Better Sandbox. Desde el artículo:

En las versiones de .Net Framework antes v4, tuvimos muchas maneras de restringir los permisos de una asamblea o incluso cierta ruta de código dentro del conjunto:

1. Pila -Paseo modificadores: Denegar, PermitOnly

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

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

4. Carga de un montaje con una zona distinta de MiEquipo

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

Lo más preocupante 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 cualquier alma pobre (como yo) que por cualquier razón se requiere para implementar CAS en su organización en este momento. Usted ha sido advertido.