Partilhar via

Aplicando descritores de segurança no objeto device

  • Artigo

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

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

  • O SID proprietário.

  • O SID do grupo.

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

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

Portanto, 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. Arquivo INF de um sistema Microsoft Windows XP Service Pack 1 (SP1).

Nesta instância, não há nenhum proprietário ou grupo especificado, portanto, eles são padrão para os valores predefinidos ou padrão. O D indica que este é um DACL. O P indica que essa é uma ACL protegida e não herda nenhum direito do descritor de segurança do objeto que contém. A ACL protegida impede que a segurança mais branda no pai seja herdada. A expressão parêntese indica uma ACE (entrada de controle de acesso único). Uma entrada de controle de acesso que usa o SDDL é composta por vários componentes separados por ponto e vírgula distintos. Na ordem, eles são os seguintes:

  • O indicador de tipo para o ACE. Há quatro tipos exclusivos para DACLs e quatro tipos diferentes para SACLs.

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

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

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

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

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

Assim, interpretando o descritor de segurança de exemplo, o "A" que lidera o ACE indica que essa é uma entrada "permitida para acesso". A alternativa é uma entrada "acesso negado", que é usada com pouca frequência e é indicada por um caractere "D" à esquerda. O campo sinalizadores especifica o CI (Container Inherit), que indica que esse ACE é herdado por subpropósitórios.

Os valores do campo de direitos codificam direitos específicos que incluem direitos genéricos e direitos padrão. Por exemplo, "GR" indica acesso de "leitura genérica" e "GA" indica acesso "genérico a todos", ambos direitos genéricos. Vários direitos especiais seguem esses direitos genéricos. No exemplo acima, "CC" indica criar acesso filho, 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 o acesso filho, "LC" para acesso filho de lista, "SW" para acesso de auto-direita, "RP" para acesso à propriedade de leitura, "SD" para acesso de exclusão padrão e "RC" para acesso de controle de leitura.

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. Portanto, no exemplo acima, os usuários recebem acesso de leitura genérico no objeto . Por outro lado, os administradores internos, a conta de serviço local, o sistema local e o serviço de rede recebem todo o 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 no Windows Server 2003 e posterior. Usando IoCreateDeviceSecure, o descritor de segurança a ser aplicado ao objeto do dispositivo é descrito usando um subconjunto da Linguagem de Definição completa do Descritor de Segurança apropriada para objetos do dispositivo.

A finalidade de aplicar descritores de segurança específicos a objetos de dispositivo é garantir que as verificações de segurança apropriadas sejam feitas no 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 do gerenciamento de acesso a esse namespace de dispositivo pertencem ao driver, não ao gerenciador de E/S.

Um problema 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 do dispositivo de driver e o driver do 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á um acesso completo marcar no 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 só marcar para garantir que o acesso de passagem seja concedido ao objeto do dispositivo. Normalmente, esse direito de passagem é concedido porque a maioria dos threads recebeu SeChangeNotifyPrivilege, o que corresponde à concessão do direito de passagem para o diretório. Um dispositivo que não dá suporte à estrutura de nomes normalmente solicitaria que o gerente de E/S executasse uma marcar de segurança completa. Isso é feito definindo o bit FILE_DEVICE_SECURE_OPEN no campo características do dispositivo. Um driver que inclui uma combinação desses objetos de dispositivo deve definir essa característica para os dispositivos que não dão suporte à estrutura de nomes. Por exemplo, um sistema de arquivos definiria essa opção em seu objeto de dispositivo nomeado (que não dá suporte a uma estrutura de nomenclatura), mas não definiria essa opção em seus objetos de dispositivo sem nome (um volume, por exemplo), que dão suporte à estrutura de nomenclatura. Falha ao definir esse bit corretamente é um bug comum em drivers e pode permitir acesso inadequado ao dispositivo. Para drivers que usam a interface de anexo (IoAttachDeviceToDeviceStackSafe, por exemplo), o bit FILE_DEVICE_SECURE_OPEN será definido se esse campo estiver definido no dispositivo ao qual o driver está anexando. Portanto, os drivers de filtro não precisam se preocupar com esse aspecto específico da verificação de segurança.