SELinux는 새로운 RHEL7 서버 배포로 전환하는 동안 운영 문제를 방지하는 데 도움이 되는 허용 모드입니다. 일부 SELinux 문제는 확인하고 해결하기가 매우 쉽지만 다음 문제는 약간 혼란스럽습니다.
AVC는 다음과 같습니다.
type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
감사 2가 말하는 이유는 다음과 같습니다.
type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
Audit2allow는 다음과 같이 말했습니다.
#============= postfix_postdrop_t ==============
#!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
이 알림은 다음 명령을 실행하여 문제의 일부를 수정해야 함을 의미하는 것 같습니다.
# restorecon -R -v /var/spool/postfix/public/pickup
# ls -lZ /var/spool/postfix/public/pickup
srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup
그러나 SELinux 감사 로깅 문제는 완료 이후에도 변경된 것으로 보이지 않으므로 분명히 더 많은 작업이 수행되어야 합니다. 아마도 일부 문제는 중재와 관련이 있을 것입니다.
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
postfix만큼 잘 확립된 서비스에 관리자 개입이 필요한 SELinux 문제가 있다는 것은 이상해 보입니다.
이 문제에 대한 해결책은 다음과 같습니다.
# echo 'type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
| audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp
그렇긴 하지만, 그러한 변경이 합법적인 것으로 간주되어야 하는 이유에 대한 더 나은 이해 없이 단순히 감사 문제를 제거하기 위한 조치를 취하는 것은 현명하지 못한 것 같습니다.
이것이 정말 태그 문제인가요, 아니면 단지 "허용" 부족으로 인한 부작용인가요? 그리고 이것이 Postfix 설치가 원활하게 실행되기 위해 관리자가 수행해야 하는 합법적이고 예상되는 변경인지에 대해 누구든지 의견을 제시할 수 있습니까? SELinux?
SELinux를 끄는 것을 제안하지 마십시오. 물론 선택 사항이지만, 오히려 이를 지키는 방법을 배우고, 이런 성격의 문제가 생겼을 때 올바른 행동 방침을 분별하는 방법을 배우고 싶습니다.
참고: 위 명령 audit2allow -M ..
과 semanage -i
명령은 레이블을 다시 지정하지 않고도 SELinux 문제를 해결하지만 레이블을 다시 지정하면 정책을 생성할 필요가 없는지 확실하지 않습니다. 이러한 방식으로 문제를 해결하는 것이 예상되는지 또는 정상적인지 확실하지 않습니다.
#============= postfix_postdrop_t ==============
#!!!! This avc is allowed in the current policy
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
답변1
실제로 restorecon
사용 이후 SELinux 문제를 해결하는 데 이러한 명령이 더 이상 필요하지 않습니다.
# echo 'type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
| audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp
다음은 SELinux 감사 문제를 해결할 때 도움이 되기를 바라는 이유입니다.
완화 단계 이전의 유형을 참고하세요. 이 경우:
unix_stream_socket
불행히도 이해를 돕는 데 도움이 될 것이므로 명령을 실행하기
ls -lZ /var/spool/postfix/public/pickup
전에 실행하지 않았습니다 .restorecon
힌트: 변경하기 전에 SELinux 컨텍스트를 확인하세요.
restorecon -R -v /var/spool/postfix/public/pickup
실행 후 SELinux 유형을 참고하세요.suffix_public_t
장르가 변한다는 점은 주목할 가치가 있습니다.
힌트: 권장
restorecon
명령과 개별allow
규칙이 모두 나열되면 완화 제안이 대체 솔루션(둘 중 하나라도 문제를 해결함)이 될 가능성이 적습니다.audit2allow
출력이 변경되었으며 제안된 명령restorecon
이 더 이상 존재하지 않습니다.audit2allow
출력에 두 명령이 모두 포함되고 변경 사항이restorecon
하나만 포함rule
된 경우 .restorecon
여기서 핵심은rule
더 이상 사용되지 않는 유형에 대해 규칙을 만들 이유가 더 이상 없기 때문에 AVC 표시가 더 이상 관련이 없다는 점을 인식하는 것입니다.postfix_postdrop_t
예를 들어, 이 특별한 경우 해당 소켓이 이제 의 최상위에 있으면 에 대한 액세스 권한을 부여할 이유가 없습니다 .unix_stream_socket
postfix_public_t
다른 유사한 상황에서는 AVC가 그 자체로 역사적인 사건이었다는 점을 기억하는 것이 중요합니다. AVC는 역사적인 사건을 위한 것이기 때문에 대체 솔루션의 세부 사항이 이벤트 당시의 시스템 상태와 더 이상 동일하지 않으면 오래된 문제에 대한 대체 솔루션이 필요하지 않을 수도 있다는 점을 명심해야 합니다. 즉, 이 명령을 사용하면 restorecon
제안이 더 이상 존재하지 않을 때 "현재 정책에서 허용됨" 메시지를 기대할 필요가 없습니다.restorecon
이 두 가지 완화 방법을 사용하지 않는 것이 현명한지 여전히 궁금하다면 이 두 가지 완화 방법이 실제로 필요한 경우 향후 감사 이벤트가 발생할 것이라는 점을 확신하십시오.
실제로 여러 완화를 사용하지 않으면 부수적인 이점이 있습니다. SELinux의 전체 목적은 프로세스가 실제로 필요한 것에 액세스하지 못하도록 제한하는 것입니다. 불필요한 유형 강제 변경이 이루어진 경우 postfix_postdrop_t
실행 파일은 더 이상 unix_stream_socket
run 과 관련되지 않은 다른 리소스에 액세스하는 것이 제한되지 않으며 postfix
합법적인 런타임 제약 조건이 postfix
깨집니다.
이 질문에 대한 더 적절한 제목은 다음과 같습니다.audit2allow가 복원 및 규칙 변경을 제안하면 두 가지 완화 조치가 모두 필요합니까?"