FreeBSD Handbook/Administração/MAC/Resolução de Problemas
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:
- Edite o arquivo /etc/fstab e defina a opção ro para a partição raiz, de modo que fique apenas para leitura.
- Reinicie o sistema em modo mono usuário (single user mode).
- Execute tunefs -l enable no /.
- Reinicie o sistema em modo normal.
- Execute mount -urw / e mude a opção ro de volta para rw no /etc/fstab reiniciando o sistema novamente em seguida.
- 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:
- 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.
- 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.
- 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
|