Code Access Security es una broma?

Question

Acabo de leer acerca de esto article sobre Code Access Security. Tiene un ejemplo en el que:

using System.Security.Permissions; 
public class MyFileAccessor 
{ 
    public MyFileAccessor(String path, bool readOnly) 
    { 
    path = MakeFullPath(path); // helper fcn 
    FileIOPermissionAccess desiredAccess = readOnly 
     ? FileIOPermissionAccess.Read 
     : FileIOPermissionAccess.AllAccess; 
    FileIOPermission p = new FileIOPermission(desiredAccess, path); 
    p.Demand(); 
    // 
    ••• 
    open the file 
    } 
    // ••• 
} 

¿Qué pasa si yo no uso la FileIOPermissionAccess tipo y nunca Includ código como p.Demand() en mi código en absoluto? En otras palabras, si quiero hacer algo malo, ¿por qué debería molestarme en pedir permiso para eso? ¿No es una especie de broma? O lo tomé mal?

Answer 1

Bueno, sí, el ejemplo es un chiste, nunca escribirías algo como esto tú mismo. Lo que falta es la parte realmente importante, el código // que abre el archivo. Una versión realista de él sería, por ejemplo, pinvoke CreateFile().

El punto es que Windows no sabe nada acerca de CAS.Por lo tanto, si proporciona una función de utilidad como esta y desea aplicar las reglas de CAS, debe verificar que su código de llamada tenga el permiso requerido. Por supuesto, este tipo de código realmente solo pertenece al framework .NET. Eche un vistazo-vea en FileStream.Init() y note que se exige FileIOPermission allí antes de la llamada CreateFile.

Answer 2

El acceso a archivos (por ejemplo, usando FileStream) exigirá automáticamente FileIOPermission. Y esto es así para todas las clases estándar, cuando hacen alguna acción que requiera permiso, lo exigirán automáticamente. Consulte .NET Framework Security here. Entonces, el código de muestra es inútil, nadie exigirá explícitamente permisos de archivos. Es razonable si desarrolla alguna API y su código se firma para que nadie pueda cambiarlo.

Leer más, aquí es cita de este artículo:

Ahora bien, en el mundo real, no se le clases de escritura como MyFileAccessor acceder a los archivos. En su lugar, utilizará las clases proporcionadas por el sistema, como System.IO.FileStream, que ya se han diseñado para realizar las comprobaciones de seguridad adecuadas para usted. A menudo se hacen en el constructor con todas las implicaciones de rendimiento y seguridad que discutí anteriormente.

Answer 3

Dentro de las API de java.io, puede asegurarse de que las comprobaciones se están realizando. Si desea controlar el acceso (evitando un bloqueo antes de que ocurra), debe realizar las comprobaciones correspondientes ANTES de las comprobaciones internas realizadas por las llamadas a la API.

El código de Java a menudo se ejecuta en las computadoras que usted controla, pero a menudo se ejecuta en computadoras que no controla. Piensa en los applets de Java. Deben pedir permiso para acceder al sistema de archivos porque no se debe permitir que el autor del programa acceda sin control al sistema de archivos de todos los demás.

Si necesita evitar que un grupo de personas haga algo malicioso, entonces debe evitar que todos realicen algo malintencionado para que la seguridad sea real. De lo contrario, los malhechores simplemente dirán que son parte del grupo de confianza sin control.

El ejecutable de la línea de comandos de Java se ejecuta de forma predeterminada con permisos que le permiten tocar su propio sistema de archivos. La suposición es que si lanzó el programa localmente, podría haber arruinado las partes de su sistema de archivos a las que tenía acceso de todos modos. Los applets se lanzan con todos estos permisos predeterminados eliminados. De esta forma, la persona que navega por la página web donde reside el applet debe otorgar permisos de forma manual para que un programa remoto (applet) toque su sistema de archivos.

Que vea esto es una prueba de que no hay una puerta trasera especial que elude la seguridad de algunos usuarios (o en algunas condiciones).