11.6. 보안

OpenSSL 은 PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명 생성을 지원하는지 탐지하지 않습니다.

TLS 1.3 프로토콜은 RSA-PSS 서명을 지원해야 합니다. PKCS #11 토큰이 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 경우, OpenSSL 라이브러리를 사용하는 서버 애플리케이션은 PKCS #11 토큰에서 키를 보유하는 경우 RSA 키로 작동하지 않습니다. 따라서 설명된 시나리오에서는 TLS 통신이 실패합니다.

이 문제를 해결하려면 TLS 버전 1.2를 사용 가능한 최고 TLS 프로토콜 버전으로 사용하도록 서버 및 클라이언트를 구성합니다.

(BZ#1681178)

OpenSSL 이 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 PKCS #11 토큰을 잘못 처리

OpenSSL 라이브러리는 PKCS #11 토큰의 키 관련 기능을 감지하지 않습니다. 결과적으로 원시 RSA 또는 RSA-PSS 서명을 지원하지 않는 토큰을 사용하여 서명이 생성되면 TLS 연결을 설정하지 못합니다.

이 문제를 해결하려면 /etc/pki/tls/openssl.cnf 파일의 crypto_policy 섹션 끝에 .include 행 뒤에 다음 행을 추가합니다.

SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384
MaxProtocol = TLSv1.2

결과적으로 설명된 시나리오에서는 TLS 연결을 설정할 수 있습니다.

(BZ#1685470)

SCP empties 파일은 특정 구문이 사용될 때 자체적으로 복사됩니다.

scp 유틸리티는 보안 복사 프로토콜(SCP)에서 더 안전한 SSH 파일 전송 프로토콜(SECDHE)으로 변경되었습니다. 결과적으로, 위치에서 동일한 위치에 파일을 복사하면 파일 내용이 삭제됩니다. 이 문제는 다음 구문에 영향을 미칩니다.

SCP localhost:/myfile localhost:/myfile

이 문제를 해결하려면 이 구문을 사용하여 소스 위치와 동일한 대상에 파일을 복사하지 마십시오.

다음 구문에 대해 문제가 해결되었습니다.

SCP /myfile localhost:/myfile
SCP localhost:~/myfile ~/myfile

(BZ#2056884)

PSK 암호화 제품군은 FUTURE 암호화 정책에서 작동하지 않습니다.

PSK(Pre-shared key) 암호가 완전한 전달 보안(PFS) 키 교환 방법을 수행하는 것으로 인식되지 않습니다. 결과적으로 ECDHE-PSK 및 DHE-PSK 암호화 적합성은 예를 들어 FUTURE 암호화 정책과 같이ECDHE LEVEL=3 으로 구성된 OpenSSL에서 작동하지 않습니다. 해결 방법으로 PSK 암호를 사용하는 애플리케이션에 대해 덜 제한적인 암호화 정책을 설정하거나 더 낮은 보안 수준(ECDHELEVEL)을 설정할 수 있습니다.

(BZ#2060044)

GnuPG는 crypto-policies에서 허용하지 않더라도 SHA-1 서명을 잘못 사용할 수 있음

GnuPG(GNU 개인 정보 보호 ECDHE) 암호화 소프트웨어는 시스템 전체의 암호화 정책에 정의된 설정과 관계없이 SHA-1 알고리즘을 사용하는 서명을 생성하고 확인할 수 있습니다. 결과적으로 DEFAULT 암호화 정책의 암호화 목적으로 SHA-1을 사용할 수 있으며, 이는 서명에 대해 이 비보안 알고리즘의 사용 중단과 일치하지 않습니다.

이 문제를 해결하려면 SHA-1과 관련된 GnuPG 옵션을 사용하지 마십시오. 결과적으로 GnuPG는 비보안 SHA-1 서명을 사용하여 기본 시스템 보안을 낮추지 않습니다.

(BZ#2070722)

GPG-agent 가 FIPS 모드에서 SSH 에이전트로 작동하지 않음

gpg-agent 툴은 FIPS 모드가 MD5 다이제스트를 비활성화하더라도 ssh-agent 프로그램에 키를 추가할 때 MD5 지문을 생성합니다. 결과적으로 ssh-add 유틸리티에서 인증 에이전트에 키를 추가하지 못합니다.

이 문제를 해결하려면 gpg-agent --daemon --enable-ssh-support 명령을 사용하지 않고 ~/.gnupg/sshcontrol 파일을 만듭니다. 예를 들어 < FINGERPRINT> 0 형식의 gpg --list-keys 명령의 출력을 ~/.gnupg/sshcontrol 에 붙여넣을 수 있습니다. 결과적으로 gpg-agent 는 SSH 인증 에이전트로 작동합니다.

(BZ#2073567)

기본 SELinux 정책을 사용하면 제한되지 않은 실행 파일이 스택을 실행할 수 있습니다.

SELinux 정책에서 selinuxuser_execstack 부울의 기본 상태는 on입니다. 즉, 제한되지 않은 실행 파일이 스택을 실행할 수 있습니다. 실행 파일은 이 옵션을 사용하지 않아야 하며, 잘못 코딩된 실행 파일 또는 가능한 공격을 나타낼 수 있습니다. 그러나 Red Hat은 다른 도구, 패키지 및 타사 제품과의 호환성으로 인해 기본 정책에서 부울 값을 변경할 수 없습니다. 시나리오가 이러한 호환성 측면에 의존하지 않는 경우 setsebool -P selinuxuser_execstack 명령을 입력하여 로컬 정책에서 부울을 해제할 수 있습니다.

(BZ#2064274)

Kickstart 설치 중 서비스 관련 규칙 수정에 실패할 수 있습니다.

Kickstart 설치 중에 OpenSCAP 유틸리티에서 서비스 활성화 또는 비활성화 상태 수정이 필요하지 않은 것으로 잘못 표시되는 경우가 있습니다. 그 결과 OpenSCAP에서 설치된 시스템의 서비스를 비준수 상태로 설정할 수 있습니다. 이 문제를 해결하려면 Kickstart 설치 후 시스템을 스캔하고 수정할 수 있습니다. 이렇게 하면 서비스 관련 문제가 해결됩니다.

(BZ#1834716)

SCAP 감사 규칙을 잘못 수정하지 못했습니다.

감사 구성과 관련된 일부 SCAP 규칙의 Bash 수정은 수정 시 감사 키를 추가하지 않습니다. 이는 다음 규칙에 적용됩니다.

audit_rules_login_events
audit_rules_login_events_faillock
audit_rules_login_events_lastlog
audit_rules_login_events_tallylog
audit_rules_usergroup_modification
audit_rules_usergroup_modification_group
audit_rules_usergroup_modification_gshadow
audit_rules_usergroup_modification_opasswd
audit_rules_usergroup_modification_passwd
audit_rules_usergroup_modification_shadow
audit_rules_time_watch_localtime
audit_rules_mac_modification
audit_rules_networkconfig_modification
audit_rules_sysadmin_actions
audit_rules_session_events
audit_rules_sudoers
audit_rules_sudoers_d

결과적으로 관련 감사 규칙이 이미 존재하지만 OVAL 검사를 완전히 따르지 않는 경우 수정은 감사 규칙의 기능적 부분, 즉 경로 및 액세스 비트이지만 감사 키는 추가하지 않습니다. 따라서 결과 감사 규칙이 올바르게 작동하지만 SCAP 규칙이 FAIL를 잘못 보고합니다. 이 문제를 해결하려면 감사 규칙에 올바른 키를 수동으로 추가합니다.

(BZ#2120978)

STIG 프로파일의 SSH 타임아웃 규칙으로 잘못된 옵션을 구성합니다.

OpenSSH의 업데이트는 다음과 같은 정보 시스템 기관 보안 기술 구현 가이드(DISA STIG) 프로필의 규칙에 영향을 미쳤습니다.

RHEL 9 용 DISA STIG (xccdf_org.ssgproject.content_profile_stig)
DISA STIG with GUI for RHEL 9 (xccdf_org.ssgproject.content_profile_stig_gui)

이러한 각 프로필에서 다음 두 가지 규칙이 영향을 받습니다.

Title: Set SSH Client Alive Count Max to zero
CCE Identifier: CCE-90271-8
Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0

Title: Set SSH Idle Timeout Interval
CCE Identifier: CCE-90811-1
Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout

SSH 서버에 적용하면 이러한 각 규칙이 더 이상 이전처럼 작동하지 않는 옵션(clientAliveCountMax 및 ClientAliveInterval)을 구성합니다. 결과적으로 OpenSSH는 이러한 규칙으로 구성된 시간 초과에 도달하면 유휴 SSH 사용자의 연결을 해제하지 않습니다. 해결 방법으로 솔루션이 개발될 때까지 RHEL 9용 DISA STIG 및 RHEL 9 프로파일용 GUI를 사용하는 DISA STIG에서 이러한 규칙이 일시적으로 제거되었습니다.

(BZ#2038978)

Keylime은 여러 IMA 측정 파일에 액세스하는 시스템을 검증하지 못할 수 있습니다.

Keylime 에이전트를 실행하는 시스템에서IMA( Integrity Measurement Architecture)에 의해 측정된 여러 파일에 빠른 연속으로 액세스하면 Keylime 검증기가 IMA 로그 추가를 잘못 처리할 수 있습니다. 결과적으로 실행 중인 해시가 올바른 PCR(Platform Configuration Register) 상태와 일치하지 않으며 시스템을 검증하지 못합니다. 현재는 해결방법이 없습니다.

(BZ#2138167)

Keylime 측정 부팅 정책 생성 스크립트로 인해 세그먼트 오류 및 코어 덤프가 발생할 수 있습니다.

Keylime에서 부팅시 측정 정책을 생성하는 create_mb_refstate 스크립트는 제공된 입력에 따라 tpm2_eventlog 툴의 출력을 처리할 때 LengthOf DevicePath 필드의 값을 사용하는 대신 DevicePath 필드의 데이터 길이를 잘못 계산할 수 있습니다. 결과적으로 스크립트는 잘못 계산된 길이를 사용하여 잘못된 메모리에 액세스하려고 시도하여 세그먼트 오류와 코어 덤프가 발생합니다. Keylime의 주요 기능은 이 문제의 영향을 받지 않지만 측정된 부팅 정책을 생성할 수 없습니다.

이 문제를 해결하려면 측정된 부팅 정책을 사용하거나 tpm2-tools 패키지의 tpm2_eventlog 툴을 사용하여 얻은 데이터에서 정책 파일을 수동으로 쓰지 마십시오.

(BZ#2140670)

일부 TPM 인증서로 인해 Keylime 등록 기관 충돌

프로덕션 배포에서 활성화해야 하는 tenant.conf 의 require_ek_cert 구성 옵션은 TPM(Relime) 테넌트에 TPM(Trusted Platform Module)의 승인 키(EK) 인증서가 필요한지 여부를 결정합니다. require_ek_cert 가 활성화된 초기 ID 인용을 수행할 때 Kelime은 에이전트의 TPM 장치를 Keylime TPM 인증서 저장소에 있는 신뢰할 수 있는 인증서와 비교하여 EK 인증서를 유효한지 여부를 확인합니다. 그러나 저장소의 일부 인증서는 잘못된 형식의 x509 인증서이며 Keylime 등록 기관이 충돌하게 됩니다. 현재 require_ek_cert 를 false 로 설정하고 EK 검증을 수행할 ek_check_script 옵션에 사용자 지정 스크립트를 정의하는 것을 제외하고 이 문제에 대한 간단한 해결 방법이 없습니다.

(BZ#2142009)

11.6. 보안

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links