Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Para un sistema de archivos, la mayor parte del trabajo de seguridad interesante se produce durante IRP_MJ_CREATE procesamiento. Es este paso que debe analizar la solicitud entrante, determinar si el autor de la llamada tiene los derechos adecuados para realizar la operación y conceder o denegar la operación según corresponda. Afortunadamente, para los desarrolladores del sistema de archivos, la mayoría del mecanismo de decisión se implementa en el Monitor de referencia de seguridad. Por lo tanto, en la mayoría de los casos, el sistema de archivos solo necesita llamar a las rutinas adecuadas del Monitor de referencia de seguridad para determinar correctamente el acceso. El riesgo de un sistema de archivos se produce cuando no se puede llamar a estas rutinas según sea necesario e incorrectamente concede acceso a un autor de llamada.
En el caso de un sistema de archivos estándar, como el sistema de archivos FAT, las comprobaciones realizadas como parte de IRP_MJ_CREATE son principalmente comprobaciones semánticas. Por ejemplo, el sistema de archivos FAT tiene numerosas comprobaciones para asegurarse de que se permite el procesamiento de IRP_MJ_CREATE en función del estado del archivo o directorio. Estas comprobaciones realizadas por el sistema de archivos FAT incluyen comprobaciones de medios de solo lectura (por ejemplo, intentos de realizar operaciones de "creación" destructivas, como sobrescribir o reemplazar, en medios de solo lectura no están permitidos), comprobaciones de acceso compartido y comprobaciones de interbloqueo. Una de las partes más difíciles de este análisis es darse cuenta de que una operación en un nivel (por ejemplo, el nivel de archivo) puede de hecho no estar permitida debido al estado de un recurso de nivel diferente (el nivel de volumen, por ejemplo). Por ejemplo, es posible que un archivo no se abra si otro proceso ha bloqueado exclusivamente el volumen. Entre los casos comunes que se van a comprobar se incluyen:
¿El nivel de archivo es compatible con el estado de nivel de volumen? El bloqueo de nivel de volumen debe obedecerse. Por lo tanto, si un proceso contiene un bloqueo de nivel de volumen exclusivo, solo los subprocesos dentro de ese proceso pueden abrir archivos. No es necesario permitir que los subprocesos de otros procesos abran archivos.
¿El nivel de archivo es compatible con el estado multimedia? Ciertas operaciones "create" modifican el archivo como parte de la operación "create". Esto incluiría sobrescribir, reemplazar e incluso actualizar la hora de último acceso en el archivo. Estas operaciones de "creación" no se permiten en medios de solo lectura y la hora de último acceso no se actualiza.
¿El nivel de volumen está abierto con el estado de nivel de archivo? No se permitiría abrir un volumen exclusivo si hay archivos existentes abiertos en el volumen. Se trata de un problema común para los nuevos desarrolladores porque intentan abrir el volumen y encuentran que se produce un error. Cuando se produce un error, se puede usar FSCTL_DISMOUNT_VOLUME para invalidar los identificadores abiertos y forzar un desmontaje, lo que permite el acceso exclusivo al volumen recién montado.
Además, los atributos de archivo deben ser compatibles. No se puede abrir un archivo con el atributo de solo lectura para el acceso de escritura. Tenga en cuenta que el acceso deseado debe comprobarse después de expandir los derechos genéricos. Por ejemplo, esta comprobación dentro del sistema de archivos FASTFAT está en la función FatCheckFileAccess (vea el archivo de origen Acchksup.c de las muestras fastfat que contiene el WDK).
El ejemplo de código siguiente es específico de la semántica FAT. Un sistema de archivos que también implementa DACLs, realizaría una comprobación de seguridad adicional mediante las rutinas monitor de referencia de seguridad (SeAccessCheck, por ejemplo).
//
// check for a read-only Dirent
//
if (FlagOn(DirentAttributes, FAT_DIRENT_ATTR_READ_ONLY)) {
//
// Check the desired access for a read-only Dirent
// Don't allow
// WRITE, FILE_APPEND_DATA, FILE_ADD_FILE,
// FILE_ADD_SUBDIRECTORY, and FILE_DELETE_CHILD
//
if (FlagOn(*DesiredAccess, ~(DELETE |
READ_CONTROL |
WRITE_OWNER |
WRITE_DAC |
SYNCHRONIZE |
ACCESS_SYSTEM_SECURITY |
FILE_READ_DATA |
FILE_READ_EA |
FILE_WRITE_EA |
FILE_READ_ATTRIBUTES |
FILE_WRITE_ATTRIBUTES |
FILE_EXECUTE |
FILE_LIST_DIRECTORY |
FILE_TRAVERSE))) {
DebugTrace(0, Dbg, "Cannot open readonly\n", 0);
try_return( Result = FALSE );
}
Una comprobación más sutil implementada por FASTFAT es asegurarse de que el acceso solicitado por el autor de la llamada es algo sobre el que el sistema de archivos FAT es consciente (en la función FatCheckFileAccess de Acchksup.c de la muestra fastfat que contiene el WDK):
En el ejemplo de código siguiente se muestra un concepto importante para la seguridad del sistema de archivos. Compruebe que lo que se pasa al sistema de archivos no se encuentra fuera de los límites de lo que espera. El enfoque conservador y adecuado desde la perspectiva de la seguridad es que si no entiende una solicitud de acceso, debe rechazar esa solicitud.
//
// Check the desired access for the object.
// Reject what we do not understand.
// The model of file systems using ACLs is that
// they do not type the ACL to the object that the
// ACL is on.
// Permissions are not checked for consistency vs.
// the object type - dir/file.
//
if (FlagOn(*DesiredAccess, ~(DELETE |
READ_CONTROL |
WRITE_OWNER |
WRITE_DAC |
SYNCHRONIZE |
ACCESS_SYSTEM_SECURITY |
FILE_WRITE_DATA |
FILE_READ_EA |
FILE_WRITE_EA |
FILE_READ_ATTRIBUTES |
FILE_WRITE_ATTRIBUTES |
FILE_LIST_DIRECTORY |
FILE_TRAVERSE |
FILE_DELETE_CHILD |
FILE_APPEND_DATA))) {
DebugTrace(0, Dbg, "Cannot open object\n", 0);
try_return( Result = FALSE );
}
Afortunadamente para los sistemas de archivos, una vez realizada la comprobación de seguridad durante el procesamiento de creación inicial, el administrador de E/S realiza comprobaciones de seguridad posteriores. Por lo tanto, por ejemplo, el administrador de E/S garantiza que las aplicaciones en modo de usuario no realizan una operación de escritura en un archivo que se ha abierto solo para el acceso de lectura. De hecho, un sistema de archivos no debe intentar aplicar la semántica de solo lectura en el objeto de archivo, incluso si se abrió solo para el acceso de lectura, durante la rutina de envío de IRP_MJ_WRITE. Esto se debe a la forma en que el administrador de memoria asocia un objeto de archivo específico a un objeto de sección determinado. La escritura posterior a través de esa sección se enviará como IRP_MJ_WRITE operaciones en el objeto de archivo, aunque el archivo se abrió de solo lectura. En otras palabras, la aplicación del acceso se realiza cuando un identificador de archivo se convierte en el objeto de archivo correspondiente en los puntos de entrada del servicio del sistema Nt por ObReferenceObjectByHandle.
Hay dos lugares adicionales dentro de un sistema de archivos donde se deben realizar comprobaciones de seguridad semánticas similares al procesamiento de "crear":
Durante el procesamiento de cambio de nombre o vínculo físico.
Al procesar las operaciones de control del sistema de archivos.
En las secciones posteriores se describe el cambio de nombre del procesamiento y el procesamiento del control del sistema de archivos.
Tenga en cuenta que esta no es una lista exhaustiva de problemas semánticos relacionados con el procesamiento de "crear". La intención de esta sección es llamar la atención sobre estos problemas para los desarrolladores del sistema de archivos. Todos los problemas semánticos deben identificarse para un sistema de archivos específico, implementarse para cumplir la semántica específica y probarse para asegurarse de que la implementación controla los distintos casos.