O problema
Estou criando uma imagem de instalação do RHEL 7.3 com um arquivo de kickstart personalizado.
Eu posso adicionar isso ao meu arquivo de kickstart para ativar a configuração do SCAP durante a instalação:
%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-gui-upstream
%end
Quando o faço, no entanto, acabo com nousb
no cmdline do meu kernel, o que desativa todas as interfaces USB, incluindo o teclado e o mouse.
(Eu fiz a mesma coisa antes com uma imagem do RHEL 7.2, e "apenas funciona", então eu sei que a abordagem básica é boa. Mas isso está usando um perfil de segurança mais antigo e, aparentemente, menos completo).
Agora, entendo perfeitamente por que: há uma regra que é especificamente configurá-lo . Preciso "adaptar" as regras para que a ferramenta SCAP não desative todos os meus dispositivos USB.
O que eu descobri até agora
De acordo com vermelho A documentação do kickstart do Hat e do site do OSCAP Anaconda , eu posso suspender este uma regra fornecendo meu próprio arquivo de alfaiataria:
tailoring-path - Path to a tailoring file which should be used, given as a relative path in the archive.
Então, eu corro scap-workbench, desabilito a regra afetada e salvo minhas alterações como um arquivo tailoring.xml
Então, eu posso adicionar uma linha na configuração do kickstart, assim:
%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-gui-upstream
tailoring-path = ssg-rhel7-ds-tailoring.xml
%end
Com base em tentativa e erro, concluí que o arquivo tailoring.xml deve ser colocado em / root / openscap_data (caminhos absolutos absolutamente não funcionam - você recebe um prompt de depuração de parada de show durante instalação).
O que eu não consigo descobrir
Mesmo depois de gerar o arquivo de adaptação, ainda estou recebendo um kernel com nousb
quando faço uma nova instalação.
-
Estou realmente colocando o tailoring.xml no lugar certo?
-
Existe um log detalhado que eu possa usar para diagnosticar o que o add-on está fazendo? (Encontrei apenas informações realmente básicas em /var/log/anaconda/journal.log.)
-
Se a abordagem de adaptação falhar por qualquer motivo, o que é uma maneira limpa e consistente de aplicar uma solução alternativa para esse problema, sem descartar completamente a configuração automática de STIG? (Por exemplo, posso usar outro módulo complementar para limpar meus argumentos de kernel depois que o OSCAP os quebra?)