Aplicando descritores de segurança no objeto Device

A maioria dos drivers usa os controlos de acesso aplicados pelo gestor de E/S nos seus objetos de dispositivo para se proteger de acesso inadequado. A abordagem mais simples para a maioria dos drivers é aplicar um descritor de segurança explícito quando o driver é instalado. Em um arquivo INF, esses descritores de segurança são descritos pela entrada "Security" na seção AddReg. Para obter mais informações sobre a linguagem completa usada para descrever os descritores de segurança, consulte Security Descriptor Definition Language na documentação do SDK do Microsoft Windows.

O formato básico de um descritor de segurança usando a linguagem de definição de descritor de segurança (SDDL) inclui as seguintes partes distintas de um descritor de segurança padrão:

• O proprietário SID.

• O grupo SID.

• A lista de controle de acesso discricionário (DACL).

• A lista de controle de acesso do sistema (SACL).

Assim, a descrição dentro de um script INF para um descritor de segurança é:

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

As entradas de controle de acesso individuais descrevem o acesso a ser concedido ou negado a um determinado grupo ou usuário, conforme especificado pelo identificador de segurança ou SID. Por exemplo, um arquivo INF pode conter uma linha 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)"

O exemplo acima veio de um NETTCPIP. INF de um sistema Microsoft Windows XP Service Pack 1 (SP1).

Neste caso, não há proprietário ou grupo especificado, então eles são atribuídos aos valores predefinidos. O D indica que se trata de uma DACL. O P indica que esta é uma ACL protegida e não herda nenhum direito do descritor de segurança do objeto que contém. A ACL protegida impede que uma segurança mais branda no pai seja herdada. A expressão entre parênteses indica uma única entrada de controle de acesso (ACE). Uma entrada de controle de acesso que usa o SDDL é composta por vários componentes distintos separados por ponto-e-vírgula. Pela ordem, são os seguintes:

• O indicador de tipo para a ACE. Existem quatro tipos exclusivos para DACLs e quatro tipos diferentes para SACLs.

• O campo de sinalizadores usado para descrever a herança dessa ACE para objetos filho ou a política de auditoria e alarme para SACLs.

• O campo direitos indica quais direitos são concedidos ou negados pela ACE. Este campo pode especificar um valor numérico específico indicando os direitos genéricos, padrão e específicos aplicáveis a esta ACE ou usar uma descrição de cadeia de caracteres de direitos de acesso comuns.

• Um GUID de objeto se a DACL for uma estrutura ACE específica do objeto.

• Um GUID de objeto herdado, caso a DACL seja uma estrutura ACE específica para aquele objeto

• Um SID que indica a entidade de segurança à qual esta ACE se aplica.

Assim, ao interpretar o descritor de segurança de exemplo, o "A" que lidera o ACE indica que esta é uma entrada de "acesso permitido". A alternativa é uma entrada "acesso negado", que é usada apenas com pouca frequência e é indicada por um caractere "D" no início. O campo de sinalizadores especifica Container Inherit (CI), o que indica que essa ACE é herdada por subobjetos.

Os valores do campo de direitos codificam direitos específicos que incluem direitos genéricos e direitos padrão. Por exemplo, "GR" indica "leitura genérica" e "GA" indica "acesso genérico total", ambos são direitos genéricos. Estes direitos genéricos são regidos por uma série de direitos especiais. No exemplo acima, "CC" indica acesso para criação de filhos, que é específico para direitos de arquivo e diretório. O exemplo acima também inclui outros direitos padrão após a cadeia de caracteres "CC", incluindo "DC" para excluir acesso a filhos, "LC" para acesso a lista de filhos, "SW" para acesso ao próprio direito, "RP" para acesso de leitura a propriedades, "SD" para acesso de exclusão padrão e "RC" para acesso de leitura a controle.

As cadeias de caracteres de entrada SID no exemplo acima incluem "PU" para usuários avançados, "BU" para usuários internos, "BA" para "administradores internos", "LS" para a conta de serviço local, "SY" para o sistema local e "NS" para a conta de serviço de rede. Assim, no exemplo acima, os usuários recebem acesso de leitura genérico no objeto. Em contraste, os administradores internos, a conta de serviço local, o sistema local e o serviço de rede recebem acesso genérico (leitura, gravação e execução). O conjunto completo de todos os direitos possíveis e cadeias de caracteres SID padrão estão documentados no SDK do Windows.

Essas ACLs serão aplicadas a todos os objetos de dispositivo criados por um determinado driver. Um driver também pode controlar as configurações de segurança de objetos específicos usando a nova função, IoCreateDeviceSecure, ao criar um objeto de dispositivo nomeado. A função IoCreateDeviceSecure está disponível no Windows XP Service Pack 1 e Windows Server 2003 e posterior. Usando IoCreateDeviceSecure, o descritor de segurança a ser aplicado ao objeto de dispositivo é descrito usando um subconjunto da linguagem de definição de descritor de segurança completa que é apropriada para objetos de dispositivo.

O objetivo da aplicação de descritores de segurança específicos a objetos de dispositivo é garantir que verificações de segurança apropriadas sejam feitas em relação ao dispositivo sempre que um aplicativo tentar acessar o próprio dispositivo. Para objetos de dispositivo que contêm uma estrutura de nome (o namespace de um sistema de arquivos, por exemplo), os detalhes de gerenciamento de acesso a esse namespace de dispositivo pertencem ao driver, não ao gerenciador de E/S.

Uma questão interessante nesses casos é como lidar com a segurança no limite entre o gerente de E/S responsável por verificar o acesso ao objeto de dispositivo do driver e o driver de dispositivo, que implementa qualquer política de segurança apropriada para o driver. Tradicionalmente, se o objeto que está sendo aberto for o nome do próprio dispositivo, o gerenciador de E/S executará uma verificação de acesso total em relação ao objeto do dispositivo diretamente usando seu descritor de segurança. No entanto, se o objeto que está sendo aberto indicar um caminho dentro do próprio driver, o gerenciador de E/S verificará apenas se o acesso transversal é concedido ao objeto do dispositivo. Normalmente, esse direito de travessia é concedido porque a maioria dos threads recebeu SeChangeNotifyPrivilege, o que corresponde à concessão do direito de travessia para o diretório. Um dispositivo que não suporta a estrutura de nomes normalmente solicitaria que o gerenciador de E/S executasse uma verificação de segurança completa. Isso é feito definindo o bit de FILE_DEVICE_SECURE_OPEN no campo de características do dispositivo. Um driver que inclua uma combinação desses objetos de dispositivo deve definir essa característica para os dispositivos que não suportam estrutura de nomes. Por exemplo, um sistema de arquivos definiria essa opção em seu objeto de dispositivo nomeado (que não suporta uma estrutura de nomenclatura), mas não definiria essa opção em seus objetos de dispositivo sem nome (um volume, por exemplo), que suportam a estrutura de nomenclatura. Não conseguir definir este bit corretamente é um bug comum nos drivers e pode permitir o acesso inadequado ao dispositivo. Para controladores que usam a interface de anexo (IoAttachDeviceToDeviceStackSafe, por exemplo), o bit de FILE_DEVICE_SECURE_OPEN é definido se este campo estiver definido no dispositivo ao qual o controlador está a ligar-se. Assim, os drivers de filtro não precisam se preocupar com esse aspeto específico da verificação de segurança.