8.6. 보안
symlink의 감사 실행 파일이 작동하지 않음
w 옵션이 제공하는 파일 모니터링은 경로를 직접 추적할 수 없습니다. 실행된 프로그램을 비교하려면 장치와 inode의 경로를 확인해야 합니다. 실행 가능한 symlink를 모니터링하는 감시는 symlink 해상도에서 발견되는 메모리에서 실행되는 프로그램이 아닌 symlink 자체의 inode를 모니터링합니다. 감시에서 symlink를 확인하여 결과 실행 프로그램을 가져오더라도 규칙이 다른 symlink에서 호출된 multi-call 바이너리에 대해 트리거됩니다. 이로 인해 잘못된 양의 로그가 급증하게 됩니다. 결과적으로 symlink의 감사 실행 파일 감시가 작동하지 않습니다.
이 문제를 해결하려면 프로그램 실행 파일의 해결 경로를 감시하고 comm= 또는 필드에 나열된 마지막 구성 요소를 사용하여 결과 로그 메시지를 필터링합니다.
proctitle=
(BZ#1421794)
다른 SELinux 컨텍스트로 전환하는 동안 파일을 실행하려면 추가 권한이 필요합니다
RHEL 7.8의 CVE-2019-11190 수정 사항 백포트로 인해 다른 SELinux 컨텍스트로 전환하는 동안 파일을 실행하려면 이전 릴리스보다 더 많은 권한이 필요합니다.
대부분의 경우 domain_entry_file() 인터페이스는 새로 필요한 권한을 SELinux 도메인에 부여합니다. 그러나 실행된 파일이 스크립트인 경우 대상 도메인에 인터프리터의 바이너리를 실행할 수 있는 권한이 없을 수 있습니다. 새로 필요한 권한이 부족하면 AVC 거부로 이어질 수 있습니다. SELinux가 강제 모드로 실행 중인 경우 커널이 SIGSEGV 또는 SIGKILL 신호로 프로세스를 종료할 수 있습니다.
selinux-policy 패키지의 일부인 도메인의 파일에서 문제가 발생하면 이 구성 요소에 대한 버그를 제출하십시오. 사용자 지정 정책 모듈의 일부인 경우 표준 SELinux 인터페이스를 사용하여 누락된 권한을 부여하는 것이 좋습니다.
-
쉘 스크립트의
corecmd_exec_shell() -
Perl 또는 Python과 같이
bin_t로 레이블이 지정된 인터프리터의 경우 corecmd_exec_all_executables()
자세한 내용은 selinux-policy-doc 패키지에서 제공하는 /usr/share/selinux/devel/include/kernel/corecommands.if 파일과 고객 포털에서 RHEL SELinux 정책 API 문서의 안정성을 손상시키는 예외 를 참조하십시오.
(BZ#1832194)
OpenSCAP로 많은 수의 파일을 스캔하면 시스템에 메모리가 부족합니다.
OpenSCAP 스캐너는 검사가 완료될 때까지 수집된 모든 결과를 메모리에 저장합니다. 그 결과 GUI 및 워크스테이션 을 사용한 대규모 패키지 그룹 Server에서 많은 수의 파일을 스캔할 때 시스템에 메모리가 부족해질 수 있습니다.
이 문제를 해결하려면 더 작은 패키지 그룹(예: RAM이 제한된 시스템에 Server 및 Minimal Install )을 사용하십시오. 시나리오에 대규모 패키지 그룹이 필요한 경우 시스템에 가상 또는 스테이징 환경에 충분한 메모리가 있는지 테스트할 수 있습니다. 또는 전체 / 파일 시스템에 대한 재귀가 필요한 규칙을 선택 취소하도록 검사 프로필을 조정할 수 있습니다.
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
file_permissions_unauthorized_world_writable -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_ungroupowned -
dir_perms_world_writable_sticky_bits
이렇게 하면 OpenSCAP 스캐너가 시스템에 메모리가 부족해지는 것을 방지할 수 있습니다.
SHA-1을 사용하는 RSA 서명은 RHEL7에서 완전히 비활성화할 수 없습니다.
새 SHA2( rsa-sha2 알고리즘을 허용해야 하므로 RHEL7에서 SHA1 알고리즘을 완전히 비활성화할 수 없습니다. 이러한 제한 사항을 해결하기 위해 RHEL8로 업데이트하거나 SHA2만 사용하는 ECDSA/Ed25519 키를 사용할 수 있습니다.
-512,rsa-sha2-256) 서명을 사용하려면 OpenSSH에서 ssh -rsa서명
CIS 프로파일에서 rpm_verify_permissions 실패
rpm_verify_permissions 규칙은 파일 권한을 패키지 기본 권한과 비교합니다. 그러나 scap-security-guide 패키지에서 제공하는 CIS(Center for Internet Security) 프로필은 일부 파일 권한을 기본값보다 더 엄격하게 변경합니다. 그 결과 rpm_verify_permissions 를 사용한 특정 파일 확인에 실패했습니다. 이 문제를 해결하려면 이러한 파일에 다음 권한이 있는지 수동으로 확인합니다.
-
/etc/cron.d(0700) -
/etc/cron.hourly(0700) -
/etc/cron.monthly(0700) -
/etc/crontab(0600) -
/etc/cron.weekly(0700) -
/etc/cron.daily(0700)
관련 기능에 대한 자세한 내용은 SCAP Security Guide는 CIS RHEL 7 Benchmark v2.2.0과 일치하는 프로파일을 제공합니다. 을 참조하십시오.
OpenSCAP 파일 소유권 관련 규칙이 원격 사용자 및 그룹 백엔드에서 작동하지 않음
OpenSCAP 제품군에서 구성 확인을 수행하는 데 사용하는 OVAL 언어에는 제한된 기능 세트가 있습니다. 일부 사용자가 원격인 경우 시스템 사용자, 그룹 및 해당 ID의 전체 목록을 얻을 가능성이 부족합니다. 예를 들어, LDAP와 같은 외부 데이터베이스에 저장된 경우.
따라서 사용자 ID 또는 그룹 ID와 함께 작동하는 규칙에는 원격 사용자의 ID에 액세스할 수 없습니다. 따라서 이러한 ID는 시스템과 외부로 식별됩니다. 이로 인해 호환 시스템에서 검사가 실패할 수 있습니다. scap-security-guide 패키지에서 다음 규칙이 영향을 받습니다.
-
xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned -
xccdf_org.ssgproject.content_rule_no_files_unowned_by_user
이 문제를 해결하기 위해 원격 사용자를 정의하는 시스템에서 사용자 또는 그룹 ID를 처리하는 규칙이 실패하는 경우 실패한 부분을 수동으로 확인합니다. OpenSCAP 스캐너를 사용하면 -- report 옵션과 함께 --oval-results 옵션을 지정할 수 있습니다. 이 옵션은 HTML 보고서에 잘못된 파일과 UID를 표시하고 수동 버전 프로세스를 간단하게 만듭니다.
또한 RHEL 8.3에서 scap-security-guide 패키지의 규칙에는 local-user 백엔드만 평가한 경고가 포함되어 있습니다.
Essential Eight 프로파일에서 이 실패합니다.rpm_verify_permissions 및 rpm_verify_ownership
rpm_verify_permissions 규칙은 파일 권한을 패키지 기본 권한과 비교하고 rpm_verify_ownership 규칙은 file owner와 패키지 기본 소유자를 비교합니다. 그러나 scap-security-guide 패키지에서 제공하는 호주 사이버 보안 센터(ACSC) Essential Eight 프로파일은 일부 파일 권한 및 소유권을 기본값보다 엄격하게 변경합니다. 그 결과 rpm_verify_ permissions 및 을 사용한 특정 파일 확인에 실패했습니다. 이 문제를 해결하려면 rpm_verify_ ownership/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache 파일을 root 가 소유하고 suid 및 sgid 비트가 설정되어 있는지 수동으로 확인합니다.
