6.2.4. Segurança

SELinux não impede mais que o systemd-journal-gatewayd chame newfstat() em /dev/shm/ arquivos usados pela corosync

Anteriormente, a política SELinux não continha uma regra que permitisse que o daemon do sistema-journal-gatewayd acessasse arquivos criados pelo serviço corosync. Como consequência, o SELinux negou o systemd-journal-gatewayd para chamar a função newfstat() nos arquivos de memória compartilhada criados pela corosync. Com esta atualização, o SELinux não mais impede que o systemd-journal-gatewayd ligue para newfstat( ) em arquivos de memória compartilhada criados pela corosync.

Libreswan agora trabalha com seccomp=enabled em todas as configurações

Antes desta atualização, o conjunto de syscalls permitidos na implementação do suporte de Libreswan SECCOMP não correspondia ao novo uso das bibliotecas RHEL. Consequentemente, quando a SECCOMP foi habilitada no arquivo ipsec.conf, a filtragem da syscall rejeitou até mesmo os syscalls necessários para o funcionamento adequado do daemon pluto; o daemon foi morto e o serviço ipsec foi reiniciado. Com esta atualização, todos os novos syscalls necessários foram permitidos, e Libreswan agora trabalha com a opção seccomp=enabled corretamente.

A SELinux não impede mais que a auditoria interrompa ou desligue o sistema

Anteriormente, a política SELinux não continha uma regra que permitisse que o daemon de Auditoria iniciasse uma unidade do sistema power_unit_file_t. Conseqüentemente, a Auditd não podia parar ou desligar o sistema mesmo quando configurada para fazê-lo em casos como o de não sobrar espaço em uma partição de disco de registro.

IPTABLES_SAVE_ON_STOP agora funciona corretamente

Anteriormente, o recurso IPTABLES_SAVE_ON_STOP do serviço iptables não funcionava porque arquivos com conteúdo de tabelas IP salvas receberam contexto SELinux incorreto. Isto impediu que o script iptables mudasse as permissões, e o script posteriormente falhou em salvar as mudanças. Esta atualização define um contexto apropriado para os arquivos iptables.save e ip6tables.save e cria uma regra de transição de nomes de arquivos. Como conseqüência, o recurso IPTABLES_SAVE_ON_STOP do serviço iptables funciona corretamente.

Os bancos de dados NSCD podem agora usar diferentes modos

Os domínios no atributo nsswitch_domain têm acesso aos serviços de Name Service Cache Daemon (NSCD). Cada banco de dados do NSCD é configurado no arquivo nscd.conf, e a propriedade compartilhada determina se o banco de dados usa memória compartilhada ou modo Socket. Anteriormente, todas as bases de dados NSCD tinham que usar o mesmo modo de acesso, dependendo do valor booleano do nscd_use_shm. Agora, o uso do soquete Unix é sempre permitido e, portanto, bancos de dados NSCD diferentes podem usar modos diferentes.

O utilitário oscap-ssh agora funciona corretamente ao digitalizar um sistema remoto com --sudo

Ao realizar um scan do Protocolo de Automação de Conteúdo de Segurança (SCAP) de um sistema remoto usando a ferramenta oscap-ssh com a opção --sudo, a ferramenta oscap no sistema remoto salva os arquivos de resultados do scan e os arquivos de relatório em um diretório temporário como usuário root. Anteriormente, se as configurações umask na máquina remota fossem alteradas, o oscap-ssh poderia ter sido impedido o acesso a estes arquivos. Esta atualização corrige o problema e, como resultado, o oscap salva os arquivos como usuário alvo, e o oscap-ssh acessa os arquivos normalmente.

OpenSCAP agora lida corretamente com sistemas de arquivos remotos

Anteriormente, o OpenSCAP não detectava de forma confiável sistemas de arquivos remotos se sua especificação de montagem não começasse com dois cortes. Como conseqüência, OpenSCAP lidou com alguns sistemas de arquivos baseados em rede como locais. Com esta atualização, o OpenSCAP identifica os sistemas de arquivo usando o tipo de sistema de arquivo em vez da especificação de montagem. Como resultado, o OpenSCAP agora lida corretamente com sistemas de arquivo remotos.

OpenSCAP não remove mais linhas em branco das cordas multi-linhas YAML

Anteriormente, o OpenSCAP removeu linhas em branco das cordas multi-linhas da YAML dentro de um fluxo de dados gerado. Isto afetou as remediações possíveis e fez com que o utilitário openscap falhasse nas verificações correspondentes de Vulnerabilidade Aberta e Linguagem de Avaliação (OVAL), produzindo resultados falsos positivos. O problema agora está resolvido e, como resultado, o openscap não remove mais as linhas em branco das cadeias de caracteres de várias linhas da YAML.

OpenSCAP agora pode escanear sistemas com grande número de arquivos sem esgotar a memória

Anteriormente, ao digitalizar sistemas com baixa RAM e grande número de arquivos, o scanner OpenSCAP às vezes fazia com que o sistema ficasse sem memória. Com esta atualização, o gerenciamento da memória do scanner OpenSCAP foi melhorado. Como resultado, o scanner não fica mais sem memória em sistemas com pouca memória RAM ao digitalizar um grande número de arquivos, por exemplo, grupos de pacotes Servidor com GUI e Estação de Trabalho.

config.enabled agora controla as declarações corretamente

Anteriormente, o rsyslog avaliou incorretamente a diretiva config.enable durante o processamento da configuração de uma declaração. Como conseqüência, o parâmetro erros não conhecidos eram exibidos para cada declaração, exceto para a declaração include(). Com esta atualização, a configuração é processada para todas as afirmações igualmente. Como resultado, o config.enabled agora desativa ou habilita corretamente as declarações sem exibir nenhum erro.

fapolicyd não impede mais as atualizações da RHEL

Quando uma atualização substitui o binário de uma aplicação em execução, o kernel modifica o caminho binário da aplicação na memória anexando o sufixo " (excluído). Anteriormente, o daemon da política de acesso a arquivos fapolicyd tratava tais aplicações como não confiáveis, e as impedia de abrir e executar quaisquer outros arquivos. Como conseqüência, o sistema às vezes era incapaz de inicializar após a aplicação de atualizações.

O perfil e8 agora pode ser usado para remediar os sistemas RHEL 8 com Servidor com GUI

Usando o OpenSCAP Anaconda Add-on para endurecer o sistema no Servidor Com GUI grupo de pacotes com perfis que selecionam regras do grupo Verify Integrity with RPM não requer mais uma quantidade extrema de RAM no sistema. A causa deste problema foi o scanner OpenSCAP. Para mais detalhes, veja Digitalizando um grande número de arquivos com OpenSCAP faz com que os sistemas fiquem sem memória. Como conseqüência, o endurecimento do sistema usando o perfil RHEL 8 Essential Eight (e8) agora funciona também com o Server With GUI.