¿Cómo negar Assert con CAS?

Question

En este código, me gustaría que el método ReadFileSystem esté prohibido para solicitar un permiso en el sistema de archivos.

Esperé que esto se lance en fileIo.Assert (), pero no lo hace. ¿Por qué?

using System.Security.Permissions;
static void Main(string[] args)
{
    var fileIo = new FileIOPermission(PermissionState.Unrestricted);
    var secuPerm = new SecurityPermission(SecurityPermissionFlag.Assertion);
    PermissionSet set = new PermissionSet(PermissionState.Unrestricted);
    set.AddPermission(fileIo);
    set.AddPermission(secuPerm);
    set.Deny();
    ReadFileSystem();
    Console.Read();
}

private static void ReadFileSystem()
{
    var fileIo = newFileIOPermission(PermissionState.Unrestricted);
    fileIo.Assert();

    DirectoryInfo dir = new DirectoryInfo("C:/");
    dir.GetDirectories();
}

Actualización

Gran enlace aquí en CAS: http: // blogs .msdn.com / shawnfa / archive / 2004/08/25 / 220458.aspx

Answer 1

La afirmación posterior niega los efectos de la Denegación.

La capacidad de afirmar FileIOPermission depende principalmente de si su ensamblado es confiable. No se ve afectado por una Denegación previa de FileIOPermission. Resulta que tampoco se ve afectado por la Denegación previa del Permiso de Seguridad de Afirmación. Esto se debe a que SecurityPermissionFlag.Assertion se verifica como una demanda de tiempo de enlace. Esto no está claramente documentado; Lo encontré aquí .

Para obligar al CLR a no confiar en su ensamblado para FileIOPermission, puede usar lo siguiente en la parte superior de su archivo después de las declaraciones de uso. Cuando agrega esto a su archivo, la afirmación no tendrá efecto. Esto afecta a todo el conjunto. No hay una granularidad más fina.

[assembly:FileIOPermission(SecurityAction.RequestRefuse, Unrestricted=true)]

Answer 2

Creo que puede malinterpretar el propósito de la Asignación de permisos. Cuando afirma un conjunto de permisos en CAS, está diciendo efectivamente "Sé lo que estoy haciendo ... No me importa cuáles son los permisos más profundos en la pila". Eso es casi nunca lo que quieres. En general, desea exigir un conjunto de permisos. Eso provoca una caminata de pila, que encontraría el Denegado en la pila y luego causaría una excepción de seguridad.

Sin embargo, dado que .NET tiene prácticamente todas las Demandas necesarias incorporadas, rara vez es necesario exigir algo a menos que esté haciendo Asserts (de nuevo, eso es raro) o ha escrito su propia clase de Permiso personalizada. / p>

Answer 3

Buena pregunta con seguridad. Ejecuté el código y también estoy un poco desconcertado. Solo paso una o dos horas estudiando los documentos y buscando en Google, pero fue en vano. Tenga en cuenta que MSDN se libra haciendo una demanda en el permiso de aserción.

Editar: la respuesta de binarycoder me apuntó en la dirección correcta.

Los derechos de Aserción son simplemente no efectivos en un ensamblaje de empuje completo. Solo si agrega lo siguiente en la parte superior del archivo:

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse, Assertion = true)] 

la llamada a fileIo.Assert () fallará.

Pero de lo contrario, intentar denegar () el permiso de Afirmación y el siguiente atributo son totalmente ineficaces (a menos que Exija explícitamente () los derechos de Afirmación).

[SecurityPermissionAttribute(SecurityAction.Deny, Assertion = true)]
private static void ReadFileSystem() {}

La documentación indica que Assert () 'tiene algunos problemas de seguridad' y la recomendación es siempre Demand-before-Assert:

fileIo.Demand();
fileIo.Assert();

pero todavía tengo que volver a ajustar mi modo de pensar sobre la aplicación del principio de privilegio mínimo.