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
.
(BZ#1746398)
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.
Esta atualização dos pacotes selinux-policy
adiciona a regra que falta, e a auditd
pode agora parar e desligar corretamente o sistema somente com SELinux em modo de aplicação.
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.
(BZ#1659383)
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.
Com o lançamento do RHBA-2020:5242 advisory, fapolicyd
ignora o sufixo no caminho binário para que o binário possa combinar com o banco de dados de confiança. Como resultado, fapolicyd
aplica as regras corretamente e o processo de atualização pode terminar.
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
.
(BZ#1816199)