Primeiro, você pode impedir que o SELinux funcione configurando-o incorretamente. Isso não faz nada para desativar qualquer backdoor, no entanto.
Então você pode parar o SELinux de fazer qualquer coisa, configurando-o em tempo de execução. Se você executar setenforce 0 , o SELinux parará de impor restrições de segurança. Ainda está ativo, no entanto. Tudo o que você fez é potencialmente tornar seu sistema menos seguro, removendo as restrições de segurança.
Se você não quiser que o SELinux seja aplicado, você pode desativá-lo no momento da inicialização com o parâmetro de kernel selinux=0 . Desta forma, o SELinux não tomará nenhuma decisão. Você perde qualquer benefício de segurança que possa trazer, é claro. E se houver um backdoor, você não tem como saber que ele ainda não está ativo. O código ainda está presente, afinal.
Ok, você precisa remover o código do kernel. Então, recompile seu kernel, com a opção de configuração CONFIG_SECURITY_SELINUX não definida. Reinicie, e agora o código SELinux não está mais rodando. Vitória?
Ha! Não: como você sabe que o backdoor está no código controlado por essa opção de configuração? Se eu fosse esconder um backdoor, eu me certificaria de que seria parte do código que todo mundo usa.
Se você quiser se livrar de qualquer backdoor que possa ter sido introduzido como parte do SELinux, você precisa voltar a uma versão do kernel que data de antes do SELinux ser introduzido, e avaliar cuidadosamente todos os commits que foram feitos para o kernel desde então e decidir se eles são livres de backdoor. Uma vez feito isso, você terá um sistema sem backdoor. Quero dizer, um kernel livre de backdoor. Quero dizer, um kernel sem esse backdoor específico que você postula.
Psych! Não, o backdoor ainda pode estar lá. E se houvesse um backdoor no kernel que afetasse o compilador, de modo que quando você compilasse o kernel, ele injetaria o backdoor no kernel mesmo que a fonte do backdoor não estivesse presente? Isso seria um backdoor auto-sustentável: compilar com um compilador backdoored ou sob um kernel de backdoor, e o kernel resultante ainda é backdoor. Soa forçado? Você acha que ninguém poderia fazer isso? Desculpe, mas foi concluído. Leia a palestra do Prêmio Turing de Ken Thompson, “Reflexões sobre confiança] .
Ok, ok. Você não pode confiar no software. Então você precisará escrever seu próprio software e seu próprio compilador, e tenha certeza de não usar o compilador ou kernel atual, possivelmente suspeito, para compilar seu próprio sistema sem backdoor. Escrever código de máquina diretamente, eu acho.
Ah, mas cuidado! Um sistema operacional malicioso (ou software mal-intencionado com acesso ao nível do kernel, para esse efeito) poderia ter injetou um backdoor em seu firmware . Então, se você não confia no seu kernel atual, também não pode confiar na sua BIOS.
Não, não, isso não vai. Você precisará criar seu próprio hardware . Boa sorte!