Estou traçando o perfil de algum software proprietário para construir um conjunto de requisitos de permissão e políticas SELinux para permitir que ele seja instalado e executado no Oracle Linux (ou qualquer derivado do RHEL).
Estou executando o SELinux no modo permissivo, executei semodule -DB para desabilitar "dontaudit" e estou visualizando /var/log/audit/audit.log para ver os resultados.
No entanto, eu gostaria de ver também TUDO o que foi permitido (não apenas negações ou permissão de auditoria), que parece ser a maioria a julgar por isto:
[root@aw-selinuxtest ~]# seinfo --stats
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Classes: 81 Permissions: 237
Sensitivities: 1 Categories: 1024
Types: 3852 Attributes: 291
Users: 9 Roles: 12
Booleans: 228 Cond. Expr.: 268
Allow: 311381 Neverallow: 0
Auditallow: 133 Dontaudit: 0
Type_trans: 38576 Type_change: 38
Type_member: 48 Role allow: 19
Role_trans: 368 Range_trans: 5601
Constraints: 90 Validatetrans: 0
Initial SIDs: 27 Fs_use: 24
Genfscon: 84 Portcon: 471
Netifcon: 0 Nodecon: 0
Permissives: 91 Polcap: 2
Alguém sabe como fazer isso? Estou lutando para encontrar uma resposta até agora.
Responder1
Ao contrário da prática usual, colocar o SELinux no permissivemodo e registrar todas as negações de AVC para desenvolver um módulo de política pode resultar na inclusão de um conjunto errado de permissões em tal política.
Um exemplo disso poderia ser o seguinte: suponha que a operação normal deste software proprietário exija umtransição de domínio, no modo permissivo, a transição não acontece e parece que o domínio de origem requer todas as permissões registradas como negações de AVC (Livro de receitas SELinux de Sven Vermeulencontém várias referências a este problema potencial).
Uma abordagem melhor para criar um módulo de política para um software proprietário seria manter o SELinux em modo de aplicação em primeiro lugar, para garantir aUltimo privilégiopossível está sendo concedido.
A seguir seria pesquisar o software, tanto online (tem documentação?) como offline ( ss, strace, ipcs, ...) para determinar detalhadamente o seu desenho arquitetónico, nomeadamente, mas não limitado a:
arquivos, que também devem ser divididos em subgrupos (configuração, transações, logs, ...)
processos, serviços (o software possui um script systemd/upstart/init?)
conectividade de rede (tráfego de entrada e saída, portas, ...)
usuários, grupos
Com todas essas informações em mãos, você poderá começar a desenvolver uma política para esse software.
Você vai precisar:
crie um arquivo filecontexts definindo o contexto de segurança de todos os arquivos envolvidos
crie um arquivo de interfaces definindo seu domínio em termos de todas as interações entre arquivos, processos, portas, usuários, transições de domínio, ...
crie um arquivo de aplicação de tipo descrevendo quais usuários têm acesso ao domínio acima e as regras reais
Compile e carregue, verifique as negações do AVC, depure e aprimore sua política. Enxague e repita.
Do livro referido acima, uma última citação:
Alguns desenvolvedores de políticas gostam de executar o modo permissivo da aplicação (seja executando todo o sistema em modo permissivo ou marcando este domínio específico como um domínio permissivo), registrando todos os acessos realizados (através das negações do AVC) e aprimorando a política com base nessas informações. Embora isso possa proporcionar uma política de trabalho mais rápida, esses desenvolvedores também correrão o risco de adicionar muitos privilégios a uma política, algo que é muito difícil de desafiar e alterar posteriormente. Em vez disso, deixamos o SELinux impedir acessos e observar como o aplicativo reage. Com base no registro de erros do aplicativo ou no comportamento do aplicativo e nas negações de AVC vistas nos logs, podemos ter uma boa ideia de quais privilégios são realmente necessários.