6.5.4. Segurança
Os usuários podem executar comandos sudo como usuários bloqueados
Em sistemas onde as permissões dos sudoers são definidas com a palavra-chave ALL, os usuários sudo com permissões podem executar comandos sudo como usuários cujas contas estão bloqueadas. Consequentemente, as contas bloqueadas e expiradas ainda podem ser usadas para executar comandos.
Para contornar este problema, habilite a opção runas_check_shell recentemente implementada junto com as configurações apropriadas de shells válidas em /etc/shells. Isto impede que os atacantes executem comandos sob contas de sistema, como bin.
(BZ#1786990)
GnuTLS falha em retomar a sessão atual com o servidor NSS
Ao retomar uma sessão TLS (Transport Layer Security) 1,3, o cliente GnuTLS espera 60 milissegundos mais um tempo estimado de ida e volta para o servidor enviar os dados de retomada da sessão. Se o servidor não enviar os dados de retomada dentro deste tempo, o cliente cria uma nova sessão em vez de retomar a sessão atual. Isto não causa efeitos adversos sérios, exceto por um pequeno impacto de desempenho em uma negociação de sessão regular.
libselinux-python só está disponível através de seu módulo
O pacote libselinux-python contém apenas ligas Python 2 para o desenvolvimento de aplicações SELinux e é usado para compatibilidade retroativa. Por esta razão, libselinux-python não está mais disponível nos repositórios padrão RHEL 8 através do comando dnf install libselinux-python.
Para contornar este problema, habilite os módulos libselinux-python e python27, e instale o pacote libselinux-python e suas dependências com os seguintes comandos:
# dnf module enable libselinux-python # dnf install libselinux-python
Alternativamente, instale libselinux-python usando seu perfil de instalação com um único comando:
# módulo dnf instalar libselinux-python:2.8/comum
Como resultado, você pode instalar libselinux-python usando o respectivo módulo.
(BZ#1666328)
udica processa recipientes UBI 8 somente quando iniciada com --env container=podman
Os recipientes Red Hat Universal Base Image 8 (UBI 8) definem a variável de ambiente do recipiente para o valor oci ao invés do valor podman. Isto impede que a ferramenta udica analise um arquivo JavaScript Object Notation (JSON) de um recipiente.
Para contornar este problema, inicie um container UBI 8 usando um comando podman com o parâmetro --env container=podman. Como resultado, a udica pode gerar uma política SELinux para um contêiner UBI 8 somente quando você utiliza o workaround descrito.
Efeitos negativos da configuração padrão de registro sobre o desempenho
A configuração padrão do ambiente de registro pode consumir 4 GB de memória ou até mais e os ajustes dos valores limite de taxa são complexos quando o sistema-journald está rodando com o rsyslog.
Veja os efeitos negativos da configuração de registro padrão da RHEL sobre o desempenho e suas mitigações Artigo da Base de Conhecimento para mais informações.
(JIRA:RHELPLAN-10431)
As permissões de arquivo de /etc/passwd- não estão alinhadas com o Benchmark CIS RHEL 8 1.0.0
Devido a um problema com o CIS Benchmark, a remediação da regra SCAP que garante permissões no arquivo de backup /etc/passwd- configura as permissões para 0644. Entretanto, o Benchmark 1.0.0 do CIS Red Hat Enterprise Linux 8 requer as permissões do arquivo 0600 para esse arquivo. Como consequência, as permissões do arquivo /etc/passwd- não estão alinhadas com o benchmark após a remediação.
SELINUX=desabilitado em /etc/selinux/config não funciona corretamente
Desabilitar o SELinux utilizando a opção SELINUX=disabled no /etc/selinux/config resulta em um processo no qual o kernel inicia com o SELinux habilitado e muda para o modo desabilitado mais tarde no processo de inicialização. Isto pode causar vazamentos de memória e condições de corrida e, conseqüentemente, também pânico no kernel.
Para contornar este problema, desative o SELinux adicionando o parâmetro selinux=0 à linha de comando do kernel, conforme descrito na seção Mudando os modos SELinux no momento da inicialização da seção Utilizando o título SELinux, se seu cenário realmente precisar desativar completamente o SELinux.
(JIRA:RHELPLAN-34199)
o ssh-keyscan não pode recuperar chaves RSA de servidores em modo FIPS
O algoritmo SHA-1 é desativado para assinaturas RSA no modo FIPS, o que impede que o utilitário ssh-keyscan recupere chaves RSA de servidores que operam nesse modo.
Para contornar este problema, use chaves ECDSA, ou recupere as chaves localmente do arquivo /etc/ssh/ssh_host_rsa_chave.pub no servidor.
OpenSSL manipula incorretamente as fichas PKCS #11 que não suportam assinaturas RSA ou RSA-PSS brutas
A biblioteca OpenSSL não detecta as capacidades relacionadas às chaves de fichas PKCS #11. Conseqüentemente, o estabelecimento de uma conexão TLS falha quando uma assinatura é criada com um token que não suporta assinaturas RSA ou RSA-PSS brutas.
Para contornar o problema, adicione as seguintes linhas após a linha .include no final da seção crypto_policy no arquivo /etc/pki/tls/openssl.cnf:
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
Como resultado, uma conexão TLS pode ser estabelecida no cenário descrito.
(BZ#1685470)
OpenSSL no modo FIPS aceita apenas parâmetros D-H específicos
No modo FIPS, os clientes do Transport Security Layer (TLS) que utilizam OpenSSL retornam um erro de valor dh ruim e abortam as conexões TLS a servidores que utilizam parâmetros gerados manualmente. Isto porque OpenSSL, quando configurado para trabalhar em conformidade com FIPS 140-2, trabalha somente com parâmetros D-H em conformidade com NIST SP 800-56A rev3 Apêndice D (grupos 14, 15, 16, 17 e 18 definidos na RFC 3526 e com grupos definidos na RFC 7919). Além disso, os servidores que utilizam OpenSSL ignoram todos os outros parâmetros e selecionam parâmetros conhecidos de tamanho semelhante. Para contornar este problema, use apenas os grupos compatíveis.
(BZ#1810911)
A remoção da embalagem rpm-plugin-selinux leva à remoção de todas as embalagens de selinux-policy do sistema
A remoção do pacote rpm-plugin-selinux desabilita a SELinux na máquina. Também remove todas as embalagens de selinux-policy do sistema. Instalação repetida do pacote rpm-plugin-selinux, então instala a política SELinux-policy-minimum SELinux, mesmo que a política selinux-policy-target estivesse previamente presente no sistema. Entretanto, a instalação repetida não atualiza o arquivo de configuração do SELinux para contabilizar a mudança na política. Como conseqüência, o SELinux é desativado mesmo após a reinstalação do pacote rpm-plugin-selinux.
Trabalhar em torno deste problema:
-
Digite o comando
umount /sys/fs/selinux/. -
Instalar manualmente o pacote
de selinuxque faltava. -
Edite o arquivo
/etc/selinux/configpara que a política seja igual aSELINUX=enforcing. -
Digite o comando
load_policy -i.
Como resultado, a SELinux está habilitada e executando a mesma política que antes.
(BZ#1641631)
o serviçosystemd não pode executar comandos a partir de caminhos arbitrários
O serviço systemd não pode executar comandos de /home/user/bin caminhos arbitrários porque o pacote de políticas da SELinux não inclui nenhuma regra desse tipo. Conseqüentemente, os serviços personalizados que são executados em caminhos que não são do sistema falham e eventualmente registram as mensagens de auditoria de negação de acesso ao Cache Vetor (AVC) quando o SELinux nega o acesso. Para contornar este problema, faça uma das seguintes ações:
Executar o comando usando um script shell com a opção
-c. Por exemplo,bash -c command-
Executar o comando a partir de um caminho comum usando
/bin,/sbin,/usr/sbin,/usr/local/bin, e/usr/local/sbindiretórios comuns.
rpm_verify_permissions fails in the CIS profile
A regra rpm_verify_permissions compara as permissões de arquivo com as permissões padrão de pacote. Entretanto, o perfil do Centro de Segurança da Internet (CIS), que é fornecido pelos pacotes scap-security-guide, altera algumas permissões de arquivo para ser mais rígido do que o padrão. Como conseqüência, a verificação de certos arquivos usando rpm_verify_permissions falha.
Para contornar este problema, verifique manualmente se estes arquivos têm as seguintes permissões:
-
/etc/cron.d(0700) -
/etc/cron.hourly(0700) -
/etc/cron.mensal(0700) -
/etc/crontab(0600) -
/etc/cron.semanal(0700) -
/etc/cron.daily(0700)
Kickstart usa org_fedora_oscap em vez de com_redhat_oscap no RHEL 8
O Kickstart faz referência ao Protocolo de Automação de Conteúdo de Segurança Aberta (OSCAP) Anaconda add-on como org_fedora_oscap em vez de com_redhat_oscap, o que pode causar confusão. Isto é feito para preservar a retrocompatibilidade com o Red Hat Enterprise Linux 7.
(BZ#1665082)
Certos conjuntos de regras interdependentes no SSG podem falhar
A remediação das regras do Guia de Segurança SCAP (SSG) em um padrão de referência pode falhar devido à ordenação indefinida das regras e suas dependências. Se duas ou mais regras precisam ser executadas em uma determinada ordem, por exemplo, quando uma regra instala um componente e outra regra configura o mesmo componente, elas podem ser executadas na ordem errada e a remediação informa um erro. Para contornar este problema, execute a correção duas vezes e a segunda execução corrige as regras dependentes.
OSCAP Anaconda Addon não instala todos os pacotes em modo texto
O plugin OSCAP Anaconda Addon não pode modificar a lista de pacotes selecionados para instalação pelo instalador do sistema se a instalação estiver rodando em modo texto. Conseqüentemente, quando um perfil de política de segurança é especificado usando Kickstart e a instalação está rodando em modo texto, quaisquer pacotes adicionais exigidos pela política de segurança não são instalados durante a instalação.
Para contornar este problema, execute a instalação em modo gráfico ou especifique todos os pacotes que são exigidos pelo perfil da política de segurança na seção %packages em seu arquivo Kickstart.
Como resultado, os pacotes que são exigidos pelo perfil de política de segurança não são instalados durante a instalação da RHEL sem uma das soluções descritas, e o sistema instalado não está de acordo com o perfil de política de segurança dado.
OSCAP Anaconda Addon não lida corretamente com perfis personalizados
O plug-in OSCAP Anaconda Addon não lida adequadamente com perfis de segurança com personalizações em arquivos separados. Conseqüentemente, o perfil personalizado não está disponível na instalação gráfica RHEL, mesmo quando você o especifica corretamente na seção Kickstart correspondente.
Para contornar este problema, siga as instruções na seção Criação de um único fluxo de dados SCAP a partir de um DS original e de um artigo de base de conhecimento de arquivo de personalização. Como resultado deste trabalho, você pode usar um perfil SCAP personalizado na instalação gráfica RHEL.
(BZ#1691305)
Os perfis baseados em OSPP são incompatíveis com os grupos de pacotes GUI.
Os pacotesGNOME instalados pelo grupo de pacotes Server with GUI requerem o pacote nfs-utils que não esteja em conformidade com o Perfil de Proteção do Sistema Operacional (OSPP). Como conseqüência, selecionando o grupo de pacotes Server with GUI durante a instalação de um sistema com perfis baseados em OSPP ou OSPP, por exemplo, o Guia de Implementação Técnica de Segurança (STIG), o OpenSCAP exibe um aviso de que o grupo de pacotes selecionado não é compatível com a política de segurança. Se o perfil baseado em OSPP for aplicado após a instalação, o sistema não é inicializável. Para contornar este problema, não instale o grupo de pacotes Server with GUI ou qualquer outro grupo que instale a GUI ao usar o perfil OSPP e os perfis baseados em OSPP. Ao utilizar os grupos de pacotes Server ou Minimal Install, o sistema se instala sem problemas e funciona corretamente.
Instalação com o Servidor com seleção de software GUI ou Workstation e perfil de segurança CIS não é possível
O perfil de segurança do CIS não é compatível com o Servidor com seleção de software GUI e Workstation. Como consequência, não é possível uma instalação RHEL 8 com o Servidor com seleção de software de GUI e perfil CIS. Uma tentativa de instalação usando o perfil do CIS e qualquer uma destas seleções de software irá gerar a mensagem de erro:
o pacote xorg-x11-server-common foi adicionado à lista de pacotes excluídos, mas ele não pode ser removido da seleção de software atual sem quebrar a instalação.
Para contornar o problema, não utilize o perfil de segurança do CIS com o Servidor com GUI ou com as seleções de software da estação de trabalho.
Regras corretivas relacionadas a serviços durante instalações de kickstart podem falhar
Durante uma instalação de kickstart, o utilitário OpenSCAP às vezes mostra incorretamente que um serviço habilita ou desabilita a correção do estado não é necessário. Conseqüentemente, o OpenSCAP pode colocar os serviços no sistema instalado em um estado não-conforme. Como alternativa, você pode escanear e remediar o sistema após a instalação do kickstart. Isto corrigirá os problemas relacionados aos serviços.
Certas cordas prioritárias rsyslog não funcionam corretamente
O suporte para a cadeia de prioridade GnuTLS para imtcp que permite um controle fino sobre a criptografia não está completo. Conseqüentemente, as seguintes cadeias de prioridade não funcionam corretamente no rsyslog:
NENHUMA: VERS-ALL:-VERS-TLS1.3: MAC-ALL: DHE-RSA: AES-256-GCM: SIGN-RSA-SHA384: COMP-ALL: GROUP-ALL
Para contornar este problema, use apenas cordas de prioridade que funcionem corretamente:
NENHUMA: VERS-ALL:-VERS-TLS1.3: MAC-ALL: ECDHE-RSA: AES-128-CBC: SIGN-RSA-SHA1: COMP-ALL: GROUP-ALL
Como resultado, as configurações atuais devem ser limitadas às cordas que funcionam corretamente.
as políticas criptográficas permitem incorretamente a utilização de cifras de Camellia
As políticas criptográficas do sistema RHEL 8 devem desativar as cifras de Camellia em todos os níveis de políticas, conforme declarado na documentação do produto. Entretanto, o protocolo Kerberos habilita as cifras por padrão.
Para contornar o problema, aplique a subpolítica NO-CAMELLLIA:
# update-crypto-policies --set DEFAULT:NO-CAMELLLIA
No comando anterior, substitua DEFAULT pelo nome de nível criptográfico se você tiver trocado de DEFAULT anteriormente.
Como resultado, as cifras Camellia são corretamente proibidas em todas as aplicações que utilizam políticas de criptografia em todo o sistema somente quando você as desabilita por meio da solução de trabalho.(BZ#1919155)
