selinux를 비활성화하면 무엇이 잘못 될 수 있습니까?

9

우리는 다른 팀으로부터 사용 된 서버를 계승했습니다. 그들 중 일부는 SELinux를 사용하도록 설정했으며 일부는 그렇지 않습니다. SELinux로 인해 비밀번호가없는 ssh, 웹 서버 등을 설정하는 데 문제가 있습니다. 이 stackexchange 사이트 에서 해결 방법을 찾았습니다 .

restorecon -R -v ~/.ssh

그러나 SELinux를 실행할 필요가 없으므로 권한이 필요한 모든 디렉토리에서 모든 사람이 위의 cmd를 실행하는 것을 기억하는 것보다 해제하는 것이 더 쉽습니다.

도로상의 영향없이 SELinux를 끌 수 있습니까? 아니면 서버를 다시 이미지로 만드는 것이 더 낫습니까? 한가지주의 할 점; 우리의 IT 그룹은 매우 바쁘기 때문에 절대적으로 필요한 경우가 아니면 (매우 훌륭한 비즈니스 사례가 필요하지 않은) 누군가가 스카치 나 위스키 한 병으로 상사에게 뇌물을 제공하지 않는 한 서버 재 이미징은 목록에 올라 있지 않습니다.

업데이트 : 모든 사람의 제안과 조언에 감사드립니다. 이 서버는 모두 내부 개발자 서버로 사용됩니다. 이러한 머신에 대한 외부 액세스는 없을 것이므로 보안은 우리에게 큰 관심사가 아닙니다. 현재 사용중인 모든 서버 (내가 아는 한)는 SELinux를 사용할 수 없습니다. 관리자가 방금 획득 한 것 중 일부는 비활성화하려는 중이므로 클러스터의 모든 것이 균일합니다.

linux ssh selinux

— 분류
소스

1

Android.se에서 비슷한 질문에 답변했습니다. SELinux가“허용”모드에 있다는 것은 얼마나 위험합니까? 내가 무엇에주의해야합니까? . "허용"모드와 SELinux 비활성화의 주요 차이점은 더 이상 AVC 로그 메시지를받지 않으며 SELinux에서 파일 레이블을 최신 상태로 유지하지 않으므로 파일을 다시 활성화하기 전에 파일의 레이블을 다시 지정해야한다는 것입니다.

— WhiteWinterWolf

"무엇이 잘못 될 수 있습니까?"

— scai

3

@scai 실제로 좋은 질문입니다. 로 사토 카츠라는 지적, SELinux를 효과적으로 사용하기 어렵다. 잘못된 보안 감각은 보안에 해 롭습니다.

— Rhymoid

14

SELinux는 운영 체제 의 보안 기능 입니다. 서버의 일부를 다른 부분으로부터 보호하도록 설계되었습니다.

예를 들어, 웹 서버를 실행하고 공격자가 임의의 명령을 실행할 수있는 "취약한"코드가있는 경우 SELinux는 웹 서버가 볼 수없는 파일에 액세스하지 못하도록하여이를 완화 할 수 있습니다.

이제 SELinux 를 비활성화 할 수 있으며 아무것도 깨지 않아야합니다. 서버는 정상적으로 작동합니다.

그러나 보안 기능 중 하나를 비활성화했습니다.

— 스티븐 해리스
소스

10

SELinux는 올바르게 구성된 경우에만 잘 작동합니다. 그러나 SELinux는 너무 복잡하여이를 제대로 구성 할 시간과 지식이 없기 때문에 결국 장애가되거나 관리자에게 끊임없는 고통을 안겨줍니다. 그러나 여러분은 보안 기능 으로 계속 믿음을 투자 합니다.

— Satō Katsura

3

selinux가 관리해야 할 PITA라는 데 동의하지만 보안 기능이라고 부르는 것은 여전히 공정하고 정확합니다. 시간을 배우고 관리하는 데 시간을 투자하고 싶거나 필요 로 하는 사람들에게는 (나가 아니라) 귀중한 가치가 있습니다.

— cas

2

@SatoKatsura 간단하게 구성하기 어렵거나 이해하기 어렵다고해서 보안 메커니즘을 비활성화하는 것은 아닙니다. 항상 결정하기 쉽지 않은이 보안 메커니즘이 필요한 경우.

— scai

@ scai 나는 그것이 비활성화되어야한다고 말하지 않았다. 내가 말하는 것은 SELinux의 기본 모델에 결함이 있다는 것입니다. 어떤 사람들은 주장 하는 것이 모두 사용할 수있는 보안 메커니즘에 결함이 있습니다.

— Satō Katsura

@SatoKatsura 그렇기 때문에 암호를 사용하는 것이 비활성화 될 수 있기 때문에 (예 : pam 또는 nss 또는 빈 암호를 사용하여) 완전히 무의미합니다. BTW, 나는 당신이 selinux를 비활성화해야한다고 주장하지 않았다. 나는 그것이 실제 보안 기능이 아니라고 주장했다.

— cas

8

SELinux에 대한 다양한 견해가 있습니다. 대부분의 경우 일부 응용 프로그램은 SELinux와 잘 작동하지 않으므로이 결정이 무의미합니다 (Oracle이 한 예입니다).
일반적으로 SELinux는 악의적 인 사용자가 시스템을 파괴하려는 방식으로 또 다른 장애물을 놓는 보호 메커니즘입니다.

대기업의 시스템 관리자로서의 이전 역할에서 ... 나는 일반적으로 SELinux를 비활성화했습니다. 사용자, 개발자 및 관리자가 사용하는 모든 시스템에서 모든 SELinux 오류를 추적 할 시간이 없었습니다.

사물을 비활성화하기 전에 시스템의 파일을 원래 상태로 다시 레이블 지정하여 시작할 수 있습니다. 내가 찾은 가장 쉬운 방법은 명령을 입력하는 것입니다.

 # /sbin/fixfiles onboot

또는

 # touch /.autorelabel

그런 다음, 시스템을 다시 부팅하여 시스템에서 잘못된 SELinux 레이블을 확인하고 재설정하는 데 거의 같은 시간이 소요됩니다. 그 후에는 서버 관리를 시도하기 전에 수정되었을 수있는 부적합한 SELinux 레이블을 수정하고 정정 할 수 있습니다.

그러나 그렇지 않은 경우 SELinux를 적용 모드로 설정하지 않아도 시스템이 손상되지 않습니다. 추가 보호 계층 일뿐입니다.

— mdpc
소스

3

음소거하지 마십시오. 그러나 완벽하게 맞습니다. 모든 시스템에 selinux가 필요한 것은 아닙니다.

— phyrfox

SELinux를 폴백으로 비활성화하기 전에 파일의 전역 레이블을 다시 지정하도록 조언하는 +1 SELinux는 예기치 않은 소프트웨어 및 사용자 동작을 방지하기위한 것입니다. 잘 정의 된 예상 동작이없는 시스템에서 SELinux는 실제로는 선보다 더 많은 피해를 야기 할 수 있습니다 (OS 제공 정책은 최대한 일반적으로 시도하지만 때로는 충분하지 않음).

— WhiteWinterWolf

감사합니다! /sbin/fixfiles onbootCentOS에서 나를 위해 일하지 않았습니다 touch /.autorelabel. Running sealert -a /var/log/audit/audit.log은 0 개의 경고를 표시합니다. @mdpc이 두 명령의 차이점은 무엇입니까?

— Joseph K.

5

간단히 말해 SELinux 와 같은 필수 액세스 제어 (MAC) 메커니즘을 비활성화 하는 것은 좋은 생각이 아니며 나쁜 사람이 DAC (임의 액세스 제어)에 의해 구현 된 이름 기반 액세스 제어를 성공적으로 우회하는 경우 보안 상 불이익을 줄 수 있습니다.

나였 어, 나는 같은 것을 할 것이다.

semanage fcontext -a -t ssh_home_t ~/.ssh # Adding the policy
restorecon -R -v ~/.ssh # Applying the policy

재귀 적으로 할당 된 유형 레이블 에 대해 더 확실하게~/.ssh

— j
소스

1

양식화 된 "SELinux"입니다. Linux는 약어가 아니며 "SE"부분은 초기입니다.

— Rhymoid

@Rhymoid : 참 좋은 메모입니다. 실제로 제가 쓴 것은 우연입니다.

— sjsam

2

일반적으로 SELinux를 비활성화해서는 안됩니다. 무엇이 잘못되었는지 이해하는 데 도움이되는 도구가 있습니다. 내가 가장 좋아하는 것은 실런트 예제 사용법입니다.

sealert -a /var/log/audit/audit.log

OFC는 디버그를 위해 항상 SELinux를 허용 모드로 설정할 수 있지만 SELinux를 비활성화하거나 허용하는 것은 Red Hat에 의해 심각한 보안 결함으로 간주됩니다.

— 알렉스 바라 노프 스키
소스