Capítulo 15. Controle de acesso obrigatório

Praticamente todos os aspectos da configuração do módulo de política de rótulo serão executados usando os utilitários do sistema base. Esses comandos fornecem uma interface simples para a configuração de objeto ou sujeito ou a manipulação e verificação da configuração.

Toda a configuração pode ser feita usando setfmac, que é usado para definir rótulos MAC em objetos do sistema, e setpmac, que é usado para definir os rótulos em sujeitos do sistema. Por exemplo, para definir o rótulo MAC`biba` como high em test:

Se a configuração for bem sucedida, o prompt será retornado sem erro. Um erro comum é Permission denied, que geralmente ocorre quando o rótulo está sendo definido ou modificado em um objeto restrito. Outras condições podem produzir falhas diferentes. Por exemplo, o arquivo pode não ser de propriedade do usuário que está tentando re-rotular o objeto, o objeto pode não existir ou o objeto pode ser somente de leitura. Uma política obrigatória não permitirá que o processo renomeie o arquivo, talvez devido a uma propriedade do arquivo, uma propriedade do processo ou uma propriedade do novo valor de rótulo proposto. Por exemplo, se um usuário que estiver executando com baixa integridade tentar alterar o rótulo de um arquivo de alta integridade, ou um usuário executando com baixa integridade tentar alterar o rótulo de um arquivo de baixa integridade para um rótulo de alta integridade, essas operações falharão.

O administrador do sistema pode usar setpmac para substituir as configurações do módulo de política, atribuindo um rótulo diferente a chamada do processo:

Para processos atualmente em execução, como o sendmail, o getpmac é normalmente usado. Esse comando usa uma ID de processo (PID) no lugar de um nome de comando. Se os usuários tentarem manipular um arquivo que não esteja em seu acesso, sujeito às regras dos módulos de política carregados, o erro Operation not permitted será exibido.

Alguns módulos de política do FreeBSD que suportam o recurso de rotulagem oferecem três rótulos predefinidos: low, equal e high, onde:

Esses módulos de política incluem mac_biba(4), mac_mls(4) e mac_lomac(4). Cada um dos rótulos predefinidos estabelece uma diretiva de fluxo de informações diferentes. Consulte a página de manual do módulo para determinar as características das configurações genéricas de rótulos.

Os módulos de políticas Biba e MLS suportam um rótulo numérico que pode ser configurado para indicar o nível exato de controle hierárquico. Esse nível numérico é usado para particionar ou classificar informações em diferentes grupos de classificação, permitindo apenas o acesso a esse grupo ou a um nível de grupo mais alto. Por exemplo:

pode ser interpretado como "Rótulo de Política Biba/Grau 10:Compartimentos 2, 3 e 6: (grau 5 …​")

Neste exemplo, o primeiro grau seria considerado o grau efetivo com compartimentos efetivos, o segundo grau é o grau baixo e o último é o grau alto. Na maioria das configurações, essas definições refinadas não são necessárias, pois são consideradas configurações avançadas.

Objetos do sistema possuem apenas um grau e compartimento atuais. Os sujeitos do sistema refletem o intervalo de direitos disponíveis no sistema e as interfaces de rede, onde são usados para controle de acesso.

O grau e os compartimentos em um par de sujeito e objeto são usados para construir um relacionamento conhecido como dominance, em que um sujeito domina um objeto, o objeto domina o sujeito, nenhum domina o outro, ou ambos dominam cada um. O caso em que "ambos dominam" ocorre quando dois rótulos são iguais. Devido à natureza do fluxo de informações do Biba, um usuário tem direitos sobre um conjunto de compartimentos que podem corresponder aos projetos, mas os objetos também têm um conjunto de compartimentos. Os usuários podem ter que subconjuntar seus direitos usando su ou setpmac para acessar objetos em um compartimento a partir do qual eles não estão restritos.

Os usuários precisam ter rótulos para que seus arquivos e processos interajam adequadamente com a política de segurança definida no sistema. Isso é configurado no /etc/login.conf usando classes de login. Todo módulo de política que usa rótulos implementará a configuração da classe de usuário.

Para definir o rótulo padrão da classe de usuário que será imposto pelo MAC, adicione uma entrada label. Um exemplo de entrada label contendo todos os módulos de política é exibida abaixo. Observe que, em uma configuração real, o administrador nunca habilitaria todos os módulos de política. Recomenda-se que o restante deste capítulo seja revisado antes que qualquer configuração seja implementada.

Embora os usuários não possam modificar o valor padrão, eles podem alterar seu rótulo após o login, sujeito às restrições da política. O exemplo acima diz à política do Biba que a integridade mínima de um processo é 5, seu máximo é 15 e o rótulo efetivo padrão é 10. O processo será executado em 10 até que ele escolha alterar o rótulo, talvez devido ao usuário usar setpmac, que será restringido pelo Biba ao intervalo configurado.

Após qualquer alteração no login.conf, o banco de dados de recursos da classe de login deve ser reconstruído usando o cap_mkdb.

Muitos sites têm um grande número de usuários que exigem várias classes de usuário diferentes. Um planejamento detalhado é necessário, pois isso pode dificultar o gerenciamento.

Os rótulos podem ser definidos em interfaces de rede para ajudar a controlar o fluxo de dados através da rede. Políticas que usam rótulos de interface de rede funcionam da mesma maneira que as políticas funcionam em relação aos objetos. Usuários com configurações altas no Biba, por exemplo, não terão permissão para acessar interfaces de rede com um rótulo low.

Ao definir o rótulo MAC em interfaces de rede, maclabel pode ser passado para o ifconfig:

Este exemplo irá definir o rótulo MAC de biba/equal na interface bge0. Ao usar uma configuração semelhante a biba/high(low-high), o rótulo inteiro deve ser citado para evitar que um erro seja retornado.

Cada módulo de política que suporta rotulagem tem um ajuste que pode ser usado para desativar o rótulo MAC em interfaces de rede. Configurar o rótulo para equal terá um efeito semelhante. Reveja a saída do sysctl, as páginas do manual de políticas e as informações no restante deste capítulo para obter mais informações sobre esses ajustes.

Nome do módulo: mac_seeotheruids.ko

Linha de configuração do kernel: options MAC_SEEOTHERUIDS

Opção de inicialização: mac_seeotheruids_load="YES"

O módulo mac_seeotheruids(4) amplia os ajustes security.bsd.see_other_uids e security.bsd.see_other_gids do sysctl. Esta opção não requer que nenhum rótulo seja definido antes da configuração e pode operar de forma transparente com outros módulos.

Depois de carregar o módulo, os seguintes ajustes sysctl podem ser usados para controlar seus recursos:

Nome do módulo: mac_bsdextended.ko

Linha de configuração do kernel: options MAC_BSDEXTENDED

Opção de inicialização: mac_bsdextended_load="YES"

O módulo mac_bsdextended(4) aplica um firewall no sistema de arquivos. Ele fornece uma extensão para o modelo de permissões do sistema de arquivos padrão, permitindo que um administrador crie um conjunto de regras semelhante a um firewall para proteger arquivos, utilitários e diretórios na hierarquia do sistema de arquivos. Quando se tenta acessar um objeto do sistema de arquivos, a lista de regras é iterada até que uma regra correspondente seja localizada ou o final seja atingido. Esse comportamento pode ser alterado usando security.mac.bsdextended.firstmatch_enabled. Semelhante a outros módulos de firewall no FreeBSD, um arquivo contendo as regras de controle de acesso pode ser criado e lido pelo sistema no momento da inicialização usando uma variável do rc.conf(5).

A lista de regras pode ser inserida usando o ugidfw(8) que possui uma sintaxe similar ao ipfw(8). Mais ferramentas podem ser escritas usando as funções da biblioteca libugidfw(3).

Depois que o módulo mac_bsdextended(4) tiver sido carregado, o seguinte comando poderá ser usado para listar a configuração atual da regra:

Por padrão, nenhuma regra é definida e tudo está completamente acessível. Para criar uma regra que bloqueia todo o acesso dos usuários, mas que não afeta o ` root `:

Embora essa regra seja simples de implementar, é uma idéia muito ruim, pois impede que todos os usuários emitam comandos. Um exemplo mais realista bloqueia todo o acesso do user1, incluindo listagens de diretórios, ao diretório inicial do usuário user2 :

Em vez de user1, not uid_user2 poderia ser usado para impor as mesmas restrições de acesso para todos os usuários. No entanto, o usuário root não é afetado por essas regras.

Nome do módulo: mac_ifoff.ko

Linha de configuração do kernel: options MAC_IFOFF

Opção de inicialização: mac_ifoff_load="YES"

O módulo mac_ifoff(4) é usado para desabilitar as interfaces de rede e evitar que as interfaces de rede sejam ativadas durante a inicialização do sistema. Ele não usa rótulos e não depende de nenhum outro módulo MAC.

A maior parte do controle deste módulo é realizada através destes ajustes sysctl:

Um dos usos mais comuns do mac_ifoff(4) é o monitoramento de rede em um ambiente onde o tráfego de rede não deve ser permitido durante a sequência de inicialização. Outro uso seria escrever um script que usa um aplicativo como o security/aide para bloquear automaticamente o tráfego da rede se encontrar arquivos novos ou alterados em diretórios protegidos.

Nome do módulo: mac_portacl.ko

Linha de configuração do kernel: MAC_PORTACL

Opção de inicialização: mac_portacl_load="YES"

O módulo mac_portacl(4) é usado para limitar a ligação a portas TCP e UDP locais , tornando possível permitir que usuários non-root sejam vinculados a portas privilegiadas especificadas abaixo de 1024.

Uma vez carregado, este módulo habilita a política MAC em todos os sockets. Os seguintes ajustes estão disponíveis:

Por padrão, as portas abaixo de 1024 só podem ser usadas por processos privilegiados que são executados como root. Para que o mac_portacl(4) permita que processos não privilegiados se vinculem a portas abaixo de 1024, defina os seguintes ajustes da seguinte forma:

Para evitar que o usuário root seja afetado por esta política, configure security.mac.portacl.suser_exempt para um valor diferente de zero.

Para permitir que o usuário www com UID 80 seja vinculado à porta 80 sem precisar do privilégio root:

Este próximo exemplo permite que o usuário com o UID de 1001 se vincule às portas TCP 110 (POP3) e 995 (POP3):

Nome do módulo: mac_partition.ko

Linha de configuração do kernel: options MAC_PARTITION

Opção de inicialização: mac_partition_load="YES"

A política mac_partition(4) coloca os processos em "partições" específicas com base no rótulo MAC. A maioria das configurações para esta política é feita usando setpmac(8). Uma vari[avek sysctl está disponível para esta política:

Quando essa política esta ativada, os usuários só poderão ver seus processos e quaisquer outros em sua partição, mas não terão permissão para trabalhar com utilitários fora do escopo dessa partição. Por exemplo, um usuário na classe insecure não terá permissão para acessar top, bem como muitos outros comandos que devem fazer spawn de um processo.

Este exemplo adiciona o top ao conjunto de rótulos dos usuários na classe insecure. Todos os processos gerados por usuários na classe insecure permanecerão no rótulo partition/13.

Este comando exibe o rótulo da partição e a lista de processos:

Esse comando exibe o rótulo da partição de processo de outro usuário e os processos atualmente em execução desse usuário:

Nome do módulo: mac_mls.ko

Linha de configuração do kernel: options MAC_MLS

Opção de inicialização: mac_mls_load="YES"

A política mac_mls(4) controla o acesso entre sujeitos e objetos no sistema, aplicando uma diretiva de fluxo de informações restrita.

Em ambientes MLS, um nível de "clearance" é definido no rótulo de cada sujeito ou objeto, juntamente com os compartimentos. Como esses níveis de liberação podem atingir números maiores que vários milhares, seria uma tarefa difícil configurar completamente cada sujeito ou objeto. Para facilitar essa sobrecarga administrativa, três rótulos são incluídos nesta política: mls/low, mls/equal e mls/high, onde:

O MLS fornece:

Os seguintes ajustes sysctl estão disponíveis:

Para manipular os rótulos MLS, use setfmac(8). Para atribuir um rótulo a um objeto:

Para obter o rótulo MLS para o arquivo test:

Outra abordagem é criar um arquivo de política mestre em /etc/, que especifica as informações de política de MLS e alimentar o setfmac com esse arquivo.

Ao usar o módulo de política do MLS, um administrador planeja controlar o fluxo de informações confidenciais. O padrão block read up block write down define tudo para um estado baixo. Tudo é acessível e um administrador aumenta lentamente a confidencialidade das informações.

Além das três opções básicas de rótulo, um administrador pode agrupar usuários e grupos conforme necessário para bloquear o fluxo de informações entre eles. Pode ser mais fácil olhar as informações em níveis de clearance usando palavras descritivas, como classificações de Confidential, Secret e Top Secret. Alguns administradores criam grupos diferentes com base nos níveis do projeto. Independentemente do método de classificação, um plano bem pensado deve existir antes de implementar uma política restritiva.

Alguns exemplos de situações para o módulo de política MLS incluem um servidor Web de e-commerce, um servidor de arquivos com informações críticas sobre a empresa e ambientes de instituições financeiras.

Nome do módulo: mac_biba.ko

Linha de configuração do kernel: options MAC_BIBA

Opção de inicialização: mac_biba_load="YES"

O módulo mac_biba(4) carrega a política MAC Biba. Essa política é semelhante à política MLS, com a exceção de que as regras para o fluxo de informações são levemente revertidas. Isso evita o fluxo descendente de informações confidenciais, enquanto a política MLS impede o fluxo ascendente de informações confidenciais.

Nos ambientes do Biba, um rótulo "integrity" é definido em cada sujeito ou objeto. Esses rótulos são compostos de classes hierárquicas e componentes não hierárquicos. Como um grau ascende, o mesmo acontece com a sua integridade.

Rótulos suportados são biba/low, biba/equal e biba/high, onde:

O Biba fornece:

Os seguintes ajustes podem ser usados para manipular a política Biba:

Para acessar a configuração de política Biba em objetos do sistema, use setfmac e getfmac:

Integridade, que é diferente de sensibilidade, é usada para garantir que a informação não seja manipulada por partes não confiáveis. Isso inclui informações passadas entre sujeitos e objetos. Ele garante que os usuários só poderão modificar ou acessar as informações para as quais receberam acesso explícito. O módulo de política de segurança mac_biba(4) permite que um administrador configure quais arquivos e programas um usuário pode ver e invocar enquanto assegura que os programas e arquivos sejam confiáveis pelo sistema para esse usuário.

Durante a fase de planejamento inicial, um administrador deve estar preparado para particionar os usuários em graus, níveis e áreas. O sistema terá como padrão um rótulo alto assim que esse módulo de política for ativado e cabe ao administrador configurar as diferentes classificações e níveis para os usuários. Em vez de usar níveis de liberação, um bom método de planejamento pode incluir tópicos. Por exemplo, permita apenas que os desenvolvedores modifiquem o acesso ao repositório do código-fonte, ao compilador do código-fonte e a outros utilitários de desenvolvimento. Outros usuários seriam agrupados em outras categorias, como testadores, designers ou usuários finais, e somente o acesso de leitura seria permitido.

Um sujeito de integridade inferior é incapaz de escrever para um sujeito de integridade superior e um sujeito de integridade superior não pode listar ou ler um objeto de integridade inferior. Definir um rótulo com o grau mais baixo possível pode torná-lo inacessível aos sujeitos. Alguns ambientes em potencial para esse módulo de política de segurança incluiriam um servidor Web restrito, uma máquina de desenvolvimento e teste e um repositório de código-fonte. Uma implementação menos útil seria uma estação de trabalho pessoal, uma máquina usada como roteador ou um firewall de rede.

Nome do módulo: mac_lomac.ko

Linha de configuração do kernel: options MAC_LOMAC

Opção de inicialização: mac_lomac_load="YES"

Diferentemente da política do MAC Biba, a política mac_lomac(4) permite acesso a objetos de baixa integridade somente após diminuir o nível de integridade para não interromper nenhuma regra de integridade.

A política de integridade de marca d’água baixa funciona de forma quase idêntica ao Biba, com a exceção do uso de rótulos flutuantes para suportar o rebaixamento do sujeito por meio de um compartimento auxiliar de classificação. Este compartimento secundário assume o formato [auxgrade]. Ao atribuir uma política com um grau auxiliar, use a sintaxe lomac/10[2], onde 2 é o grau auxiliar.

Essa política se baseia na rotulagem onipresente de todos os objetos do sistema com rótulos de integridade, permitindo que os sujeitos leiam objetos de baixa integridade e fazendo o downgrade do rótulo no sujeito para evitar gravações futuras em objetos de alta integridade usando [auxgrade] . A política pode fornecer maior compatibilidade e exigir menos configuração inicial do que o Biba.

Como as políticas Biba e MLS, setfmac e setpmac são usadas para colocar rótulos nos objetos do sistema:

Um grau auxiliar low é uma funcionalidade fornecida apenas pela política MACLOMAC.

Comece o procedimento adicionando a seguinte classe de usuário ao /etc/login.conf:

Em seguida, adicione a seguinte linha a seção de classe de usuário padrão:

Salve as edições e rode o seguinte comando para reconstruir o banco de dados:

Configure o usuário root para a classe padrão usando:

Todas as contas de usuário que não são root agora exigirão uma classe de login. A classe de login é necessária, caso contrário, os usuários terão acesso recusado aos comandos comuns. O seguinte script sh deve resolver:

Em seguida, altere as contas nagios e www para a classe insegura:

Um arquivo de contexto deve agora ser criado como /etc/policy.contexts:

Essa política impõe segurança ao definir restrições no fluxo de informações. Nesta configuração específica, os usuários, incluindo O root, nunca devem ter permissão para acessar o Nagios. Arquivos de configuração e processos que fazem parte do Nagios serão completamente auto-contidos ou presos.

Este arquivo será lido depois da execução do setfsmac em cada sistema de arquivos. Este exemplo define a política no sistema de arquivos raiz:

Em seguida, adicione estas edições a seção principal do /etc/mac.conf:

Para finalizar a configuração, adicione as seguintes linhas ao /boot/loader.conf:

E a seguinte linha para a configuração da placa de rede armazenada em /etc/rc.conf. Se a configuração de rede principal for feita via DHCP, talvez seja necessário configurá-la manualmente após cada inicialização do sistema:

Primeiro, certifique-se de que o servidor Web e o Nagios não iniciarão na inicialização e reinicialização do sistema. Assegure-se de que o root não possa acessar nenhum dos arquivos no diretório de configuração do Nagios. Se o root puder listar o conteúdo de /var/spool/nagios, algo está errado. Em vez disso, um erro "permission denied" deve ser retornado.

Se tudo parecer bem, o Nagios, o Apache e o Sendmail agora poderão ser iniciados:

Verifique novamente para garantir que tudo esteja funcionando corretamente. Caso contrário, verifique os arquivos de log em busca de mensagens de erro. Se necessário, use o sysctl(8) para desativar o módulo de política de segurança mac_biba(4) e tente iniciar tudo novamente.