FreeBSD Handbook/Administração/MAC/Rótulos

Origem: Wikilivros, livros abertos por um mundo aberto.


FreeBSD Handbook
Anterior Capítulo 16. Mandatory Access Control Próxima


16.4 Entendendo os Rótulos do MAC

Um rótulo (label) do MAC é um atributo de segurança que pode ser aplicado a sujeitos e objetos do sistema.

Quando se define um rótulo, o usuário deve ser capaz de compreender exatamente o que está sendo feito. Os atributos disponíveis num objeto dependem do módulo de políticas carregado e os módulos interpretam os atributos de maneiras diferentes. Se forem configurados inadequadamente por falta de compreensão ou conhecimento das implicações, os resultados serão imprevisíveis e, provavelmente, haverá um funcionamento indesejado do sistema.

O rótulo de segurança em um objeto é usado por uma política para decidir sobre o controle de acesso. Em algumas políticas o rótulo contém toda a informação necessária para a decisão. Em outros modelos, os rótulos podem ser processados como parte de um conjunto de regras para a decisão.

Como um exemplo, definir o rótulo biba/low para um arquivo representará um rótulo mantido pelo módulo de política de segurança Biba, com o valor “low”.

Alguns módulos de políticas do FreeBSD que suportam a característica de rótulos oferecem três rótulos específicos pré-definidos: low, high e equal. Embora eles forcem o controle de acesso de maneira diferente em cada módulo, você pode ter certeza de que o rótulo “low” será a definição de menor valor, “equal” definirá que o sujeito ou objeto não são afetados ou ficam desabilitados e o rótulo “high” atribuirá o maior valor à configuração nos módulos Biba e MLS.

Em ambientes com sistemas de arquivo de rótulo único, apenas um rótulo pode ser usado em objetos. Isso forçará uma única definição de permissões de acesso através de todo o sistema de arquivos e em muitas situações isso pode atender todas as necessidades. Existem poucos casos em que múltiplos rótulos podem ser definidos em objetos e sujeitos no sistema de arquivos. Para estes casos a opção multilabel deve ser passada via tunefs(8).

Nos módulos Biba e MLS pode ser definido um rótulo numérico para indicar precisamente o nível de controle hierárquico. Este nível numérico é usado para particionar ou ordenar informações classificando-as em diferentes grupos e permitindo acesso apenas a uma classificação ou a um nível mais alto.

Na maioria dos casos o administrador irá configurar apenas um único rótulo para ser usado em todo o sistema de arquivos.

Espere aí, isso é semelhante ao DAC! Eu pensei que o MAC desse controle irrestrito ao administrador. Esta afirmação ainda é verdade, em alguma extensão, já que o root está no controle e é quem configura as políticas, de modo que os usuários são colocados nas categorias e níveis de acesso apropriados. Muitos módulos podem restringir o usuário root também. Controles básicos sobre objetos serão liberados para o grupo, mas o root pode revogá-los ou modificá-los a qualquer tempo. Este é o modelo de hierarquias coberto por políticas como Biba e MLS.

16.4.1 Configuração de Rótulos

Todos os aspectos da configuração de rótulos dos módulos de políticas serão feitos usando-se ferramentas nativas do sistema. Estes comandos fornecem uma interface simples para a configuração de objetos ou sujeitos ou a manipulação e verificação de configurações.

Toda a configuração pode ser feita usando-se as ferramentas setfmac(8) e setpmac(8). O comando setfmac é usado para definir rótulos do MAC nos objetos do sistema, enquanto o setpmac é usado para configurar os rótulos de sujeitos do sistema. Veja:

 # setfmac biba/high test

Se não ocorrerem erros com o comando acima o sistema retornará ao prompt. O único caso em que estes comandos mostram alguma mensagem é quando ocorrem erros, como acontece com os comandos chmod(1) e chown(8). Em alguns casos o erro pode ser de permissão negada (“Permission Denied”) e normalmente acontece quando o rótulo está sendo definido ou modificado em um objeto que está restringido.[1] O administrador do sistema pode usar os seguintes comandos para sobrepujar isso:

 # setfmac biba/high test
 “Permission denied”
 # setpmac biba/low setfmac biba/high test
 # getfmac test
 test: biba/high

Como vemos acima, setpmac pode ser usado para passar por cima das definições dos módulos de políticas com a definição de um rótulo diferente ao comando executado. O utilitário getpmac é normalmente usado com processos em execução, como sendmail, embora ele use um ID de processo no lugar de um comando, a lógica é muito similar. Se os usuários tentarem manipular um arquivo que não podem, sujeito às regras dos módulos carregados, o erro “Operation not permitted” será mostrado pela função mac_set_link.

16.4.1.1 Tipos Comuns de Rótulo

É possível definir rótulos simples com os módulos mac_biba(4), mac_mls(4) e mac_lomac(4). Os possíveis valores são “high”, “equal” e “low”. A seguir uma breve descrição do que estes rótulos fornecem:

  • O rótulo “low” é considerado o de valor mais baixo que um objeto ou sujeito pode ter. Definí-lo em objetos ou sujeitos irá bloquear o acesso deles a objetos e sujeitos com rótulos de valor mais alto.
  • O rótulo “equal” deve ser atribuído apenas a objetos considerados excluídos da política.
  • O rótulo “high” garante a um objeto ou sujeito a definição de maior valor possível.

Com relação a cada módulo de política, cada uma destas definições ativará diferentes diretivas de fluxos de informação. Ler as páginas de manual apropriadas esclarecerá mais tarde o tratamento a estas configurações de rótulo genéricas.

16.4.1.1.1 Configuração Avançada de Rótulo

Rótulos numéricos são usados para comparação:compartimento+compartimento, de modo que o seguinte exemplo:

 biba/10:2+3+6(5:2+3-20:2+3+4+5+6)

Pode ser interpretado como:

 “Rótulo de Política Biba”/“Grau 10” :“Compartimentos 2, 3 e 6”: (“grau 5 ...”)

Neste exemplo o primeiro grau deveria ser considerado o “efetivo” com “compartimentos efetivos”, o segundo é o grau mais baixo “low” e o último o grau mais alto, “high”. Na maioria das configurações estas definições não serão usadas, entretanto elas oferecem configurações mais avançadas.

Quando aplicadas a objetos do sistema, elas terão apenas um grau/compartimento corrente, em oposição a sujeitos do sistema, já que eles refletem o range de direitos disponíveis no sistema e interfaces de rede, onde são usados para controle de acesso.

O grau e compartimento em um par sujeito e objeto são usados para construir uma relação denominada “dominance” (dominância), onde um sujeito domina um objeto, o objeto domina o sujeito, nenhum domina o outro ou ambos dominam o outro. O caso de dominância mútua acontece quando dois rótulos são iguais. Devido a natureza do fluxo de informação do módulo Biba você possui direitos a alguns compartimentos que podem corresponder a projetos, mas objetos também tem um conjunto de compartimentos. Os usuários podem ter que subdividir os direitos usando su ou setpmac para acessar objetos em um compartimento a partir do qual eles não são restringidos.

16.4.1.2 Configurações de Usuários e Rótulos

Os próprios usuários são obrigados a ter rótulos, de modo que seus arquivos e processos possam interagir apropriadamente com a política de segurança definida no sistema. Isso é configurado através do arquivo login.conf usando classes de logins. Cada módulo de política que usa rótulos implementará a configuração de classe de usuário.

Um trecho de exemplo contendo cada configuração de módulo de política é mostrado abaixo:

default:\
    :copyright=/etc/COPYRIGHT:\
    :welcome=/etc/motd:\
    :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
    :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\
    :manpath=/usr/share/man /usr/local/man:\
    :nologin=/usr/sbin/nologin:\
    :cputime=1h30m:\
    :datasize=8M:\
    :vmemoryuse=100M:\
    :stacksize=2M:\
    :memorylocked=4M:\
    :memoryuse=8M:\
    :filesize=8M:\
    :coredumpsize=8M:\
    :openfiles=24:\
    :maxproc=32:\
    :priority=0:\
    :requirehome:\
    :passwordtime=91d:\
    :umask=022:\
    :ignoretime@:\
    :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:

A opção “label” é utilizada para definir o rótulo da classe default que será usado pelo MAC. Os usuários nunca poderão mudar este valor, portanto isso pode ser considerado não opcional para o usuário. Numa configuração real, contudo, o administrador nunca desejará ativar todos os módulos de políticas. É recomendável que o restante deste capítulo seja revisto antes de se implementar qualquer configuração.

Nota: Os usuários podem alterar seus rótulos depois do login inicial, porém esta mudança está sujeita às limitações da política. O exemplo acima indica à política Biba que a integridade mínima de um processo é 5, a máxima é 15, mas o rótulo padrão efetivo é 10. O processo será executado no nível 10 até escolher trocar o rótulo, talvez pelo uso do comando setpmac pelo usuário, o que será limitado pelo Biba ao intervalo definido no login.

Em todos os casos, após alterar o login.conf, a base de compatibilidade das classes de login deve ser reconstruída usando-se o comando cap_mkdb e isso se refletirá em todo o exemplo ou discussão subseqüente.

É interessante notar que muitos ambientes podem ter um número de usuários particularmente grande, sendo necessárias muitas classes de usuário diferentes. É preciso planejar isso a fundo, já que pode se tornar extremamente difícil de se gerenciar.

Versões futuras do FreeBSD incluirão novas maneiras de lidar com o mapeamento de usuários e rótulos, mas isso não estará disponível até algum tempo depois do FreeBSD 5.3.

16.4.1.3 Interfaces de Rede e Configurações de Rótulos

Rótulos também podem ser definidos para interfaces de rede de modo a ajudar no controle de fluxo de dados pela rede. Em todos os casos eles funcionam da mesma maneira que as políticas com relação a objetos. Usuários com definições de maior nível no Biba, por exemplo, não terão permissão de acessar interfaces de rede com um rótulo de menor nível.

O maclabel deve ser passado ao ifconfig quando definindo o rótulo MAC nas interfaces de rede. Por exemplo:

 # ifconfig bge0 maclabel biba/equal

irá definir o rótulo MAC biba/equal na interface bge(4). Quando se usa uma definição similar a biba/high(low-high), todo o rótulo deve estar entre aspas ou haverá uma mensagem de erro.

Cada módulo de política que suporta rotulação tem um ajuste que pode ser usado para desabilitar o rótulo MAC em interfaces de rede. Definir o rótulo como “equal” tem o mesmo efeito. Veja a saída do sysctl, as páginas de manual das políticas ou mesmo as informações encontradas mais adiante neste capítulo para saber sobre estes ajustes.

16.4.2 Singlelabel ou Multilabel?

Por padrão o sistema usará a opção singlelabel. Mas o que isso significa para o administrador? Existem várias diferenças que, em cada caso, oferecem prós e contras à flexibilidade nos modelos de segurança dos sistemas.

O singlelabel permite apenas um rótulo, o “biba/high”, para ser usado em cada sujeito ou objeto. Isso permite menor trabalho administrativo mas diminui a flexibilidade das políticas que trabalham com rótulos. Muitos administradores podem querer usar a opção multilabel em suas políticas de segurança.

A opção multilabel permitirá que cada sujeito ou objeto tenha seu próprio rótulo MAC independente, ao invés de uma única opção padrão como no singlelabel, que permite apenas um rótulo em toda a partição. As duas opções só são necessárias para políticas que implementam a função de rotulação, o que inclui as políticas Biba, Lomac, MLS e SEBSD.

Em muitos casos a opção multilabel realmente não precisa ser definida. Considere a seguinte situação e modelo de segurança:

  • Servidor web FreeBSD usando o framework MAC e um mix de várias políticas.
  • Esta máquina requer apenas um rótulo, biba/high, para tudo no sistema. Neste caso o sistema de arquivos não precisará da opção multilabel, já que a singlelabel sempre atenderá.
  • Mas esta máquina será um servidor web e deve executar o servidor web como biba/low para prevenir escritas indevidas. A política Biba e como ela funciona será visto mais tarde, de modo que se o comentário anterior foi de difícil interpretação, apenas continue lendo e volte depois. O servidor pode usar uma partição separada definida com biba/low para a maior parte, senão toda a sua execução. Está faltando um maior detalhamento deste exemplo, como as restrições de dados, configurações e definições de usuário, porém isso foi apenas um rápido exemplo para esclarecer o ponto-de-vista mencionado.

Se alguma das políticas não rotuláveis forem usadas, então a opção multilabel jamais será necessária. Isso inclui as políticas seeotheruids, portacl e partition.

Deve ainda ser notado que o uso de multilabel com uma partição e estabelecendo-se um modelo de segurança baseado na funcionalidade multilabel pode acarretar uma sobrecarga administrativa, já que tudo no sistema de arquivos deverá ter um rótulo. Isso inclui diretórios, arquivos e até mesmo arquivos de dispositivos (device nodes).

O seguinte comando definirá a opção multilabel no sistema de arquivos para se ter múltiplos rótulos. Isso só pode ser feito em modo mono usuário (single user mode):

 # tunefs -l enable /

Não é necessário fazer isso para a partição de swap.

Nota: Alguns usuários tiveram problemas com a definição do multilabel na raiz do sistema. Se este for seu caso, por favor veja a Seção 16.16 deste capítulo.

16.4.3 Controlando o MAC com Ajustes do Sistema

Sem qualquer módulo carregado, ainda pode se configurar algumas partes do MAC usando-se a interface sysctl. Estes ajustes estão descritos abaixo e em todos os casos o número um (1) significa habilitado enquanto zero (0) significa desabilitado:

  • security.mac.enforce_fs assume (1) como padrão e e força as políticas de sistema de arquivos MAC nos discos.
  • security.mac.enforce_kld assume (1) como padrão e força as políticas de conexões de kernel no conector dinâmico de kernel (kld(4)).
  • security.mac.enforce_network assume (1) como padrão e força as políticas de rede do MAC.
  • security.mac.enforce_pipe assume (1) como padrão e força as políticas de pipe do MAC.
  • security.mac.enforce_process assume (1) como padrão e força as políticas de processos do MAC para processos que utilizam comunicação entre processos.
  • security.mac.enforce_socket assume (1) como padrão e força as políticas de sockets do MAC (veja a página de manual socket(2)).
  • security.mac.enforce_system assume (1) como padrão e força as políticas do MAC de atividades do sistema como a gestão de contas de usuários e o processo de reboot.
  • security.mac.enforce_vm assume (1) como padrão e força as políticas do MAC no sistema de memória virtual.

Nota: Todas as políticas ou opções do MAC tem ajustes pelo sistema. Isso normalmente fica numa estrutura tipo security.mac.<nomedapolítica>. Para ver todas as opções ajustáveis do MAC use o seguinte comando:

 # sysctl -da | grep mac

Isso pode ser interpretado como se todas as políticas básicas do MAC fossem forçadas por padrão. Se os módulos forem construídos dentro do kernel o sistema ficará extremamente fechado e possivelmente impossibilitado de se comunicar com a rede local, conectar com a Internet, etc. Por isso não é muito recomendável a construção de módulos no kernel. Não por que isso limite a habilidade de desabilitar funcionalidades em tempo real com o sysctl, mas permite ao administrador trocar instantaneamente as políticas de um sistema sem a necessidade de reconstrução e reinstalação de um novo sistema.

Notas
[1] Outras condições podem causar diferentes falhas. Por exemplo, o arquivo pode não ser do usuário que está tentando modificar o rótulo do objeto, o objeto pode não existir ou pode ter permissão de leitura apenas. Uma política mandatória não permitirá o processo de modificação de rótulo do objeto talvez por causa de uma propriedade do arquivo, uma propriedade do processo ou uma propriedade do novo valor do rótulo proposto. Por exemplo: um novo usuário rodando em modo “low” tenta mudar o rótulo de um arquivo em modo “high”. Ou talvez um um usuário rodando em modo “low” tenta mudar o rótulo de um arquivo em modo “low” para um valor maior.



Anterior Índice Próxima
Explicação do MAC Topo Planejando a Configuração de Segurança
Última edição desta página: 31/08/2010 (20100831124529)