15.5. Políticas MAC Disponíveis

O kernel padrão do FreeBSD inclui a diretiva options MAC. Isso significa que todos os módulos incluídos no framework MAC podem ser carregados com o comando kldload como um módulo do kernel em tempo de execução. Depois de testar o módulo, adicione o nome do módulo ao arquivo /boot/loader.conf para que ele seja carregado durante a inicialização. Cada módulo também fornece uma opção de kernel para os administradores que escolhem compilar seu próprio kernel personalizado.

O FreeBSD inclui um grupo de políticas que cobrirá a maioria dos requisitos de segurança. Cada política é resumida abaixo. As três últimas políticas suportam configurações inteiras no lugar dos três rótulos padrão.

15.5.1. O MAC vê a Política de Outros UIDs

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:

  • O security.mac.seeotheruids.enabled ativa o módulo e implementa as configurações padrões que impedem que os usuários visualizem processos e soquetes pertencentes a outros usuários.

  • security.mac.seeotheruids.specificgid_enabled permite que grupos especificados sejam isentos desta política. Para isentar grupos específicos, use a variável security.mac.seeotheruids.specificgid=XXX do sysctl, substituindo XXX pelo ID numérico do grupo a ser isento.

  • security.mac.seeotheruids.primarygroup_enabled é usado para isentar grupos primários específicos desta política. Ao usar este ajuste, o security.mac.seeotheruids.specificgid_enabled não pode estar definido.

15.5.2. A Política Estendida do BSD MAC

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:

# ugidfw list
0 slots, 0 rules

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 :

# ugidfw add subject not uid root new object not uid root mode n

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 :

# ugidfw set 2 subject uid user1 object uid user2 mode n
# ugidfw set 3 subject uid user1 object gid user2 mode n

Em vez de user1, not uiduser2 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.

Nota:

Deve-se ter extremo cuidado ao trabalhar com este módulo, pois o uso incorreto pode bloquear o acesso a certas partes do sistema de arquivos.

15.5.3. A política de silenciamento da interface MAC

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:

  • security.mac.ifoff.lo_enabled ativa ou desativa todo o tráfego na interface de loopback, lo(4).

  • security.mac.ifoff.bpfrecv_enabled ativa ou desativa todo o tráfego na interface do Filtro de Pacotes Berkeley, bpf(4).

  • security.mac.ifoff.other_enabled ativa ou desativa o tráfego em todas as outras interfaces.

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.

15.5.4. A política de lista de controle de acesso da porta MAC

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:

  • security.mac.portacl.enabled ativa ou desativa a política completamente.

  • A security.mac.portacl.port_high configura o número de porta mais alto que o mac_portacl(4) protege.

  • A security.mac.portacl.suser_exempt, quando configurada para um valor diferente de zero, isenta o usuário root desta política.

  • A security.mac.portacl.rules especifica a política como uma cadeia de texto no formato rule [, rule, ...], com tantas regras quantas forem necessárias, e onde cada regra esta na forma idtype:id:protocol:port. O idtype é uid ou gid. O parâmetro protocol pode ser tcp ou udp. O parâmetro port é o número da porta para permitir que o usuário ou grupo especificado se vincule. Somente valores numéricos podem ser usados para os parâmetros ID do usuário, ID do grupo e porta.

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:

# sysctl security.mac.portacl.port_high=1023
# sysctl net.inet.ip.portrange.reservedlow=0
# sysctl net.inet.ip.portrange.reservedhigh=0

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.

# sysctl security.mac.portacl.suser_exempt=1

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

# sysctl security.mac.portacl.rules=uid:80:tcp:80

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

# sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995

15.5.5. A Política de Partição MAC

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:

  • A security.mac.partition.enabled permite a aplicação de partições de processo MAC.

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.

# setpmac partition/13 top

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

# ps Zax

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:

# ps -ZU trhodes

Nota:

Os usuários podem ver processos no rótulo root, a menos que a política mac_seeotheruids(4) esteja carregada.

15.5.6. O módulo de segurança multinível MAC

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:

  • Qualquer coisa rotulada com mls/low terá um nível de folga baixo e não será permitido acessar informações de um nível superior. Esse rótulo também evita que objetos de nível de liberação mais alto gravem ou transmitam informações para um nível inferior.

  • mls/equal deve ser colocado em objetos que devem ser isentos da política.

  • mls/high é o nível mais alto de permissão possível. Objetos atribuídos a esse rótulo terão domínio sobre todos os outros objetos no sistema; no entanto, eles não permitirão o vazamento de informações para objetos de classe baixa.

O MLS fornece:

  • Um nível de segurança hierárquico com um conjunto de categorias não hierárquicas.

  • Regras fixas de no read up, no write down. Isso significa que um sujeito pode ter acesso de leitura a objetos em seu próprio nível ou abaixo, mas não acima. Da mesma forma, um sujeito pode ter acesso de gravação a objetos em seu próprio nível ou acima, mas não abaixo dele.

  • Sigilo, ou a prevenção de divulgação inadequada de dados.

  • Uma base para o projeto de sistemas que lidam simultaneamente com dados em múltiplos níveis de sensibilidade sem vazar informações entre secretas e confidenciais.

Os seguintes ajustes sysctl estão disponíveis:

  • security.mac.mls.enabled é usado para habilitar ou desabilitar a política MLS.

  • security.mac.mls.ptys_equal todos os dispositivos pty(4) como mls/equal durante a criação.

  • security.mac.mls.revocation_enabled revoga o acesso a objetos depois que seu rótulo é alterado para um rótulo de nível inferior.

  • security.mac.mls.max_compartments define o número máximo de níveis de compartimentos permitidos em um sistema.

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

# setfmac mls/5 test

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

# getfmac 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.

15.5.7. O Módulo MAC Biba

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:

  • biba/low é considerado a integridade mais baixa que um sujeito ou objeto pode ter. Definir isso em sujeitos ou objetos bloqueia o acesso de gravação a objetos ou sujeitos marcados como biba/high, mas não impede o acesso de leitura.

  • biba/equal só deve ser colocado em objetos considerados como isentos da política.

  • biba/high permite gravar objetos em um rótulo inferior, mas não permite a leitura desse objeto. Recomenda-se que esse rótulo seja colocado em objetos que afetam a integridade de todo o sistema.

O Biba fornece:

  • Níveis de integridade hierárquica com um conjunto de categorias de integridade não hierárquicas.

  • As regras fixas são no write up, no read down, o oposto do MLS. Um sujeito pode ter acesso de gravação a objetos em seu próprio nível ou abaixo, mas não acima. Da mesma forma, um sujeito pode ter acesso de leitura a objetos em seu próprio nível ou acima, mas não abaixo.

  • Integridade, impedindo a modificação inadequada de dados.

  • Níveis de integridade em vez dos níveis de sensibilidade do MLS.

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

  • security.mac.biba.enabled é usado para ativar ou desativar a imposição da política Biba na máquina de destino.

  • O security.mac.biba.ptys_equal é usado para desabilitar a política Biba em dispositivos pty(4).

  • security.mac.biba.revocation_enabled força a revogação do acesso a objetos se o rótulo for alterado para dominar o sujeito.

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

# setfmac biba/low test
# getfmac test
test: biba/low

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.

15.5.8. O módulo MAC de marca d'água baixa

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:

# setfmac /usr/home/trhodes lomac/high[low]
# getfmac /usr/home/trhodes lomac/high[low]

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

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.