FreeBSD Handbook/Administração/MAC/Resolução de Problemas

Origem: Wikilivros, livros abertos por um mundo aberto.


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


16.16 Resolução de Problemas do Framework MAC

Durante o estágio de desenvolvimento, alguns usuários reportaram problemas com configurações normais. Alguns destes problemas estão listados abaixo:

16.16.1 A opção multilabel não pode ser habilitada no /

A configuração multilabel não fica habilitada na minha partição raiz (/)!

Parece que um em cada cinqüenta usuários tem este problema, nós inclusive o experimentamos durante nossa configuração inicial. Uma nova observação deste dito “bug” me levou a acreditar que isto é o resultado seja de documentação incorreta ou mal interpretada. Independente de por que isso acontece, os seguintes passos devem ser seguidos para resolver:

  1. Edite o arquivo /etc/fstab e defina a opção ro para a partição raiz, de modo que fique apenas para leitura.
  2. Reinicie o sistema em modo mono usuário (single user mode).
  3. Execute tunefs -l enable no /.
  4. Reinicie o sistema em modo normal.
  5. Execute mount -urw / e mude a opção ro de volta para rw no /etc/fstab reiniciando o sistema novamente em seguida.
  6. Confira novamente a saída do mount para assegurar-se de que a opção multilabel foi corretamente definida no sistema de arquivos raiz.

16.16.2 Não é possível iniciar um servidor X11 depois do MAC

Depois de estabelecer um ambiente seguro com o MAC eu não consigo mais iniciar o X!

Isso pode ser causado pela política MAC partition ou pelo rotulamento incorreto em uma das políticas do MAC que trabalham com rótulos. Para depurar, tente o seguinte:

  1. Cheque a mensagem de erro. Se o usuário estiver na classe “insecure”, a política partition pode ser a culpada. Tente colocar novamente o usuário na classe “default” e reconstruir a base de dados com o comando cap_mkdb. Se isso não resolver o problema vá para o passo 2.
  2. Revise novamente as políticas de rótulo. Assegure-se de que estas estão configuradas corretamente para o usuário em questão, a aplicação X11 e as configurações de /dev.
  3. Se nenhuma destas opções resolver o problema, envie a mensagem de erro e uma descrição do seu ambiente para a lista de discussão do TrustedBSD localizada no website do TrustedBSD ou para a lista de discussão de questões gerais do FreeBSD (FreeBSD general questions mailing list).

16.16.3 Erro: _secure_path(3) cannot stat .login_conf

Quando tento trocar do usuário root para outro no sistema obtenho a mensagem de erro “_secure_path: unable to state .login_conf”.

Esta mensagem normalmente é obtida quando o usuário tem uma definição de rótulo maior que a do usuário no qual ele está tentando se tornar. Por exemplo, um usuário no sistema, joe, tem um rótulo padrão biba/low. O usuário root, que tem um rótulo biba/high, não pode ver o diretório pessoal do usuário joe. Isso vai acontecer independente do root ter usado o comando su para se tornar joe ou não. Neste cenário, o modelo de integridade do Biba não permitirá que o root veja objetos definidos num nível de integridade menor.

16.16.4 O usuário root está corrompido!

O root não é reconhecido nem em modo normal nem em mono usuário. O comando whoami retorna 0 (zero) e su retorna “who are you?”. O que pode estar acontecendo?

Isso pode acontecer se uma política de rótulos tiver sido desabilitada, seja pelo sysctl(8) ou o módulo do kernel foi descarregado. Se a política está sendo desativada ou foi temporariamente desligada, então as bases de dado de login tem que ser reconfiguradas com a remoção das opções de rótulo. Revise o arquivo login.conf para se assegurar de que todas as opções de rótulo foram removidas e reconstrua a base de dados com o comando cap_mkdb.

Isso pode acontecer também se uma política restringe acesso ao arquivo master.passwd ou à base de dados. Normalmente é causado por um administrador alterando o arquivo sob um rótulo que conflita com a política geral que está sendo usada no sistema. Nestes casos a informação de usuário seria lida pelo sistema e o acesso seria bloqueado, já que o arquivo teria herdado o novo rótulo. Desabilite a política via sysctl(8) e tudo deve voltar ao normal.



Anterior Índice Próxima
Amarração de Usuários Topo Capítulo 17 - Auditoria de Eventos de Segurança
Última edição desta página: 31/08/2010 (20100831124518)