6.4.3. Segurança

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.

A SELinux não impede mais o Tomcat de enviar e-mails

Antes desta atualização, a política SELinux não permitia que os domínios tomcat_t e pki_tomcat_t se conectassem às portas SMTP. Consequentemente, o SELinux negou aplicações no servidor Tomcat de enviar e-mails. Com esta atualização dos pacotes da política selinux, a política permite que processos dos domínios Tomcat acessem as portas SMTP, e o SELinux não mais impede que aplicações no Tomcat enviem e-mails.

lockdev agora funciona corretamente com a SELinux

Anteriormente, a ferramenta lockdev não podia transitar para o contexto lockdev_t, embora a política SELinux para o lockdev_t estivesse definida. Como conseqüência, o lockdev podia ser executado no domínio 'unconfined_t' quando utilizado pelo usuário root. Isto introduziu vulnerabilidades no sistema. Com esta atualização, a transição para o lockdev_t foi definida, e o lockdev pode agora ser usado corretamente com o SELinux no modo de aplicação.

iotop agora funciona corretamente com a SELinux

Anteriormente, a ferramenta iotop não podia transitar para o contexto iotop_t, embora a política SELinux para o iotop_t estivesse definida. Como conseqüência, o iotop podia ser executado no domínio 'unconfined_t' quando utilizado pelo usuário root. Isto introduziu vulnerabilidades no sistema. Com esta atualização, a transição para iotop_t foi definida, e o iotop pode agora ser usado corretamente com o SELinux no modo de aplicação.

SELinux agora lida apropriadamente com NFS 'crossmnt'

O protocolo NFS com a opção crossmnt cria automaticamente montagens internas quando um processo acessa um subdiretório já utilizado como um ponto de montagem no servidor. Anteriormente, isto fazia com que o SELinux verificasse se o processo de acesso a um diretório montado em NFS tinha uma permissão de montagem, o que causava negações de AVC. Na versão atual, a verificação de permissão do SELinux salta estas montagens internas. Como resultado, acessar um diretório NFS que está montado no lado do servidor não requer permissão de montagem.

Uma recarga da política SELinux não causa mais falsos erros ENOMEM

A recarga da política SELinux anteriormente fez com que a tabela de pesquisa do contexto de segurança interna não respondesse. Consequentemente, quando o núcleo encontrou um novo contexto de segurança durante uma recarga da política, a operação falhou com um falso erro "Out of memory" (ENOMEM). Com esta atualização, a tabela de pesquisa do Identificador de Segurança interno (SID) foi redesenhada e não congela mais. Como resultado, o núcleo não retorna mais erros ENOMEM enganosos durante uma recarga da política SELinux.

Domínios não definidos agora podem usar smc_socket

Anteriormente, a política SELinux não tinha as regras de permissão para a classe smc_socket. Consequentemente, a SELinux bloqueou um acesso ao smc_socket para os domínios não-confinados. Com esta atualização, as regras de permissão foram adicionadas à política do SELinux. Como resultado, os domínios não-confinados podem utilizar smc_socket.

Os procedimentos de limpeza Kerberos são agora compatíveis com GSSAPIDelegateCredentials e o cache padrão do krb5.conf

Anteriormente, quando a opção default_ccache_name era configurada no arquivo krb5.conf, as credenciais kerberos não eram limpas com as opções GSSAPIDelegateCredentials e GSSAPICleanupCredentials definidas. Este bug agora é corrigido atualizando o código fonte para limpar os caches de credenciais nos casos de uso descritos. Após a configuração, o cache de credenciais é limpo na saída, caso o usuário o configure.

OpenSSH agora maneja corretamente o PKCS #11 URIs para chaves com rótulos não correspondentes

Anteriormente, especificar PKCS #11 URIs com a parte do objeto (etiqueta chave) poderia impedir o OpenSSH de encontrar objetos relacionados no PKCS #11. Com esta atualização, a etiqueta é ignorada se os objetos correspondentes não forem encontrados, e as chaves são combinadas somente por suas identificações. Como resultado, o OpenSSH agora é capaz de usar chaves em cartões inteligentes referenciados usando o PKCS #11 URIs completo.

As conexões SSH com sistemas hospedados em VMware-hosted agora funcionam corretamente

A versão anterior da suíte OpenSSH introduziu uma mudança da bandeira padrão de Qualidade de Serviço IP (IPQoS) nos pacotes SSH, que não era tratada corretamente pela plataforma de virtualização VMware. Conseqüentemente, não era possível estabelecer uma conexão SSH com sistemas na VMware. O problema foi corrigido na estação de trabalho VMWare 15, e as conexões SSH com sistemas hospedados em VMware agora funcionam corretamente.

curve25519-sha256 é agora suportado por padrão no OpenSSH

Anteriormente, faltava o algoritmo de troca de chaves SSH curva25519-sha256 nas configurações de políticas criptográficas de todo o sistema para o cliente e servidor OpenSSH, apesar de estar em conformidade com o nível padrão da política. Como consequência, se um cliente ou um servidor usasse a curva25519-sha256 e este algoritmo não fosse suportado pelo host, a conexão poderia falhar. Esta atualização do pacote crypto-policies corrige o bug, e as conexões SSH não falham mais no cenário descrito.

Livros de jogo possíveis para perfis OSPP e PCI-DSS não saem mais após encontrar uma falha

Anteriormente, as remediações possíveis para o Protocolo de Automação de Conteúdo de Segurança (OSPP) e os perfis do PCI-DSS (Payment Card Industry Data Security Standard) falharam devido a pedidos incorretos e outros erros nas remediações. Esta atualização corrige os pedidos e erros nos playbooks de remediações possíveis, e as remediações possíveis agora funcionam corretamente.

Transporte de auditoria=KRB5 agora funciona corretamente

Antes desta atualização, o modo de transporte Audit KRB5 não funcionava corretamente. Conseqüentemente, a Auditoria de registro remoto utilizando a autenticação por pares Kerberos não funcionava. Com esta atualização, o problema foi resolvido e a Auditoria de registro remoto agora funciona corretamente no cenário descrito.