Aplicación de descriptores de seguridad en el objeto Device

La mayoría de los controladores usan los controles de acceso aplicados por el administrador de E/S en sus objetos de dispositivo para protegerse contra el acceso inadecuado. El enfoque más sencillo para la mayoría de los controladores es aplicar un descriptor de seguridad explícito cuando se instala el controlador. En un archivo INF, estos descriptores de seguridad se describen mediante la entrada "Seguridad" en la sección AddReg. Para obtener más información sobre el lenguaje completo que se usa para describir los descriptores de seguridad, consulte Lenguaje de definición de descriptores de seguridad en la documentación de Microsoft Windows SDK.

El formato básico de un descriptor de seguridad mediante el Lenguaje de definición de descriptores de seguridad (SDDL) incluye las siguientes partes distintas de un descriptor de seguridad estándar:

• SiD del propietario.

• El SID del grupo.

• Lista de control de acceso discrecional (DACL, Discretionary Access Control List).

• Lista de control de acceso al sistema (SACL, System Access Control List).

Por lo tanto, la descripción de un script INF para un descriptor de seguridad es:

O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)

Las entradas de control de acceso individuales describen el acceso que se va a conceder o denegar a un grupo o usuario determinado según lo especificado por el identificador de seguridad o el SID. Por ejemplo, un archivo INF podría contener una línea como:

"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;NS)(A;CI;GA;;;LS)(A;CI;CCDCLCSWRPSDRC;;;S-1-5-32-556)"

El ejemplo anterior procede de un NETTCPIP. Archivo INF desde un sistema de Microsoft Windows XP Service Pack 1 (SP1).

En este caso, no hay ningún propietario o grupo especificado, por lo que el valor predeterminado es los valores predefinidos o predeterminados. La D indica que se trata de una DACL. La P indica que se trata de una ACL protegida y no hereda ningún derecho del descriptor de seguridad del objeto contenedor. La ACL protegida impide que se herede la seguridad más lenciente en el elemento primario. La expresión entre paréntesis indica una única entrada de control de acceso (ACE). Una entrada de control de acceso que usa el SDDL se compone de varios componentes separados por punto y coma distintos. En orden, son los siguientes:

• Indicador de tipo para la ACE. Hay cuatro tipos únicos para las DACL y cuatro tipos diferentes para las SACL.

• Campo flags usado para describir la herencia de esta ACE para objetos secundarios o auditoría y directiva de alarma para SACL.

• El campo de derechos indica qué derechos concede o deniega la ACE. Este campo puede especificar un valor numérico específico que indique los derechos genéricos, estándar y específicos aplicables a esta ACE o usar una descripción de cadena de los derechos de acceso comunes.

• GUID de objeto si la DACL es una estructura ACE específica del objeto.

• GUID de objeto heredado si la DACL es una estructura ACE específica del objeto

• SID que indica la entidad de seguridad a la que se aplica esta ACE.

Por lo tanto, la interpretación del descriptor de seguridad de ejemplo, la "A" que conduce a la ACE indica que se trata de una entrada de "acceso permitido". La alternativa es una entrada "acceso denegado", que solo se usa con poca frecuencia y se denota mediante un carácter "D" inicial. El campo flags especifica Container Inherit (CI), que indica que este ACE se hereda por sub-objetos.

Los valores del campo de derechos codifican derechos específicos que incluyen derechos genéricos y derechos estándar. Por ejemplo, "GR" indica el acceso "lectura genérica" y "GA" indica el acceso "todos genéricos", ambos son derechos genéricos. Varios derechos especiales siguen estos derechos genéricos. En el ejemplo anterior, "CC" indica crear acceso secundario, que es específico de los derechos de archivo y directorio. En el ejemplo anterior también se incluyen otros derechos estándar después de la cadena "CC", incluido "DC" para eliminar el acceso secundario, "LC" para el acceso secundario de lista, "SW" para el acceso de autoservicio, "RP" para el acceso de propiedad de lectura, "SD" para el acceso de eliminación estándar y "RC" para el acceso de control de lectura.

Las cadenas de entrada de SID del ejemplo anterior incluyen "PU" para usuarios avanzados, "BU" para usuarios integrados, "BA" para "administradores integrados, "LS" para la cuenta de servicio local, "SY" para el sistema local y "NS" para la cuenta de servicio de red. Por lo tanto, en el ejemplo anterior, a los usuarios se les asigna acceso de lectura genérico en el objeto . En cambio, los administradores integrados, la cuenta de servicio local, el sistema local y el servicio de red tienen acceso genérico (lectura, escritura y ejecución). El conjunto completo de todos los derechos posibles y cadenas de SID estándar se documentan en Windows SDK.

Estas ACL se aplicarán a todos los objetos de dispositivo creados por un controlador determinado. Un controlador también puede controlar la configuración de seguridad de objetos específicos mediante la nueva función , IoCreateDeviceSecure, al crear un objeto de dispositivo con nombre. La función IoCreateDeviceSecure está disponible en Windows XP Service Pack 1 y Windows Server 2003 y versiones posteriores. Con IoCreateDeviceSecure, el descriptor de seguridad que se va a aplicar al objeto de dispositivo se describe mediante un subconjunto del lenguaje completo de definición de descriptores de seguridad que es adecuado para los objetos de dispositivo.

El propósito de aplicar descriptores de seguridad específicos a objetos de dispositivo es asegurarse de que las comprobaciones de seguridad adecuadas se realizan en el dispositivo cada vez que una aplicación intenta acceder al propio dispositivo. En el caso de los objetos de dispositivo que contienen una estructura de nombres (el espacio de nombres de un sistema de archivos, por ejemplo), los detalles de la administración del acceso a este espacio de nombres de dispositivo pertenecen al controlador, no al administrador de E/S.

Un problema interesante en estos casos es cómo controlar la seguridad en el límite entre el administrador de E/S responsable de comprobar el acceso al objeto de dispositivo del controlador y al controlador del dispositivo, que implementa cualquier directiva de seguridad adecuada para el controlador. Tradicionalmente, si el objeto que se abre es el nombre del propio dispositivo, el administrador de E/S realizará una comprobación de acceso completa en el objeto de dispositivo directamente mediante su descriptor de seguridad. Sin embargo, si el objeto que se abre indica una ruta de acceso dentro del propio controlador, el administrador de E/S solo comprobará para asegurarse de que se concede acceso de recorrido al objeto de dispositivo. Normalmente, se concede este derecho de recorrido porque a la mayoría de los subprocesos se les ha concedido SeChangeNotifyPrivilege, que se corresponde con la concesión del derecho de recorrido al directorio. Normalmente, un dispositivo que no admite la estructura de nombres solicitaría que el administrador de E/S realice una comprobación de seguridad completa. Para ello, establezca el bit FILE_DEVICE_SECURE_OPEN en el campo de características del dispositivo. Un controlador que incluya una combinación de estos objetos de dispositivo debe establecer esta característica para los dispositivos que no admiten la estructura de nombres. Por ejemplo, un sistema de archivos establecería esta opción en su objeto de dispositivo con nombre (que no admite una estructura de nomenclatura), pero no establecería esta opción en sus objetos de dispositivo sin nombre (un volumen, por ejemplo), que admiten la estructura de nomenclatura. No se puede establecer correctamente este bit es un error común en los controladores y puede permitir el acceso inadecuado al dispositivo. Para los controladores que usan la interfaz de datos adjuntos (IoAttachDeviceToDeviceStackSafe, por ejemplo), el bit de FILE_DEVICE_SECURE_OPEN se establece si este campo está establecido en el dispositivo al que está conectado el controlador. Por lo tanto, los controladores de filtro no necesitan preocuparse por este aspecto concreto de la comprobación de seguridad.