Ao contrário da prática usual, configurar o SELinux para o modo permissive e registrar todas as negações do 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 pode ser o seguinte: suponha que essa operação normal do software proprietário exija uma transiçã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 ( SELinux Cookbook de Sven Vermeulen contém várias referências a este problema em potencial).
Uma abordagem melhor para criar um módulo de política para um software proprietário seria manter o SELinux em modo de execução em primeiro lugar, para garantir que o privilégio mínimo possível seja concedido.
O próximo passo seria pesquisar o software, tanto on-line (tem documentação?) como off-line ( ss , strace , ipcs , ...) para determinar detalhadamente seu projeto arquitetônico, ou seja, 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ê poderia começar a desenvolver uma política para esse software.
Você precisará:
-
crie um arquivo filecontexts definindo o contexto de segurança de todos os arquivos envolvidos
-
crie um arquivo de interfaces que defina 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 execução de tipo descrevendo quais usuários têm acesso ao domínio acima e às regras reais
Compile e carregue, verifique as negações do AVC, depure e melhore sua política. Enxagúe e repita.
Do livro acima, uma última citação:
Some policy developers like to run application permissive mode (either by running the entire system in permissive mode or by marking this particular domain as a permissive domain), registering all accesses performed (through the AVC denials) and enhancing the policy based on that information. Although this might give a faster working policy, these developers will also risk that they add too many privileges to a policy, something that is very difficult to challenge and change later. Instead, we let SELinux prevent accesses and look at how the application reacts. Based on the error logging of the application or the behavior of the application and the AVC denial(s) seen through the logs, we can have a good picture of what privileges are really needed.