▲

GN⁺: 데비안의 취약성(Insecurity)

 (unix.foo)
3P by neo 3달전 | favorite | 댓글 2개

Red Hat의 RHEL 소스 코드 배포 방식 변경

  • 2023년 6월 Red Hat은 Red Hat Enterprise Linux(RHEL) 배후의 소스 코드 배포 방식을 변경하기로 한 논란의 여지가 있는 결정을 내림
  • 이 결정은 Rocky Linux, AlmaLinux, Oracle Linux 등 RHEL의 다운스트림 리빌드의 향후 생존 가능성에 대해 많은 의문을 제기함
  • 각 배포판은 이후 커뮤니티를 진정시키기 위해 발표를 함
  • 많은 오픈 소스 커뮤니티에서는 Red Hat의 결정을 탐욕적인 기업의 영향력으로 해석함
  • 사람들은 Debian으로 이주하거나 이미 이주했다고 말하며 안식처를 찾고 있음

보안의 중요성과 어려움

  • 보안은 어렵고, 지루하며, 불쾌하고, 제대로 하려면 많은 노력이 필요함
  • Debian은 사용자를 보호하기 위해 충분한 노력을 기울이지 않음

Red Hat의 SELinux 채택과 기본 정책 제공

  • Red Hat은 오래전에 SELinux 사용을 수용했으며, 단순히 커널에서 기능을 활성화하는 것 이상으로 나아감
  • 그들은 배포판을 위한 기본 SELinux 정책을 만드는 데 힘든 작업을 수행함
  • 이러한 정책은 RHEL에서 기본적으로 활성화되어 제공되며, RHEL에서 기본적으로 실행되는 다양한 데몬과 서버에서 가장 많이 사용되는 데몬을 보호하는 데 도움이 됨
  • Apache, nginx, MariaDB, PostgreSQL, OpenSSH 등이 모두 RHEL 배포판에 제공되는 SELinux 정책에 의해 보호됨

컨테이너에 대한 SELinux 정책 적용

  • 보호는 컨테이너에까지 확장됨
  • 컨테이너는 개발자가 소프트웨어를 배포하는 데 점점 더 선호하는 방법이 되고 있음
  • 컨테이너에서 무언가를 실행하면 본질적으로 안전하다는 것은 오해임
  • 컨테이너 자체는 보안 문제를 해결하지 않고 소프트웨어 배포 문제를 해결함
  • Red Hat 기반 배포판에서는 데몬 없이 컨테이너를 실행할 수 있고 완전히 루트리스로 실행할 수 있는 장점을 제공하는 Docker 대안인 podman을 사용할 수 있음
  • Red Hat은 한 단계 더 나아가 컨테이너를 호스트 OS 및 다른 컨테이너와 분리하는 강력한 기본 SELinux 정책을 적용함
  • SELinux 정책을 컨테이너에 적용하면 알 수 없는 미래의 취약점 위험을 완화하는 강화된 안전 장치를 제공함

Red Hat의 SELinux 기본 정책 제공 노력

  • Red Hat은 이러한 기본 정책에 대한 작업을 수행하지 않으면 사용자가 기술을 수용하지 않을 것이고 수백만 대의 서버가 취약한 상태로 남아 있을 것임을 알고 있었음
  • SELinux는 어렵고 정책 언어와 도구는 복잡하고 모호하며 세금 신고서를 작성하는 것만큼이나 매력적이지 않음
  • 그러나 Red Hat이 수행한 작업 덕분에 RHEL에서 SELinux 사용은 대부분 투명하며 사용자에게 실질적인 보안 이점을 제공함

Debian의 AppArmor 접근 방식

  • Debian은 안정성과 광범위한 소프트웨어 라이브러리로 유명한 오픈 소스 커뮤니티의 핵심임
  • 그러나 기본 보안 프레임워크는 개선의 여지가 많음
  • Debian 10부터 기본적으로 AppArmor를 활성화하기로 한 결정은 보안 개선을 위한 긍정적인 단계이지만 시스템 전반에 걸쳐 반쯤 구현되어 있어 부족함
  • Debian의 AppArmor 의존과 기본 구성은 보안에 대한 접근 방식에 체계적인 문제가 있음을 보여줌
  • AppArmor는 적절하게 구성된 경우 강력한 보안을 제공할 수 있지만 Debian의 기본 설정은 그 잠재력을 활용하지 못함

Debian의 AppArmor 문제점

  • 제한된 기본 프로필: Debian은 최소한의 AppArmor 프로필 세트와 함께 제공되어 많은 중요한 서비스를 보호하지 않음
  • 사후 대응 대 사전 예방적 입장: Debian의 보안 모델은 종종 사용자가 더 엄격한 정책을 구현하는 데 의존하며 기본적으로 안전한 구성을 제공하지 않음
  • 일관성 없는 적용: Red Hat 시스템의 SELinux와 달리 Debian의 AppArmor는 부분적으로 적용되어 잠재적인 보안 격차를 초래함
  • 리소스 부족: 커뮤니티 중심 프로젝트인 Debian은 Red Hat에서 제공하는 것과 유사한 포괄적인 보안 정책을 개발하고 유지 관리할 리소스가 부족함

Debian에서 Docker를 통한 컨테이너 워크로드 실행

  • Debian에서 Docker를 통해 컨테이너 워크로드를 실행하는 것은 매우 일반적임
  • Docker는 docker-default라는 컨테이너에 대한 기본 AppArmor 프로필을 자동으로 생성하고 로드함
  • 불행히도 이것은 보안에 매우 강력한 프로필이 아니며 지나치게 허용적임
  • 이 프로필은 어느 정도 보호를 제공하지만 상당한 공격 표면을 노출시킴

AppArmor와 SELinux의 근본적인 차이점

  • AppArmor와 SELinux의 근본적인 차이점은 필수 접근 제어(MAC)에 대한 접근 방식에 있음
  • AppArmor는 경로 기반 모델에서 작동하는 반면 SELinux는 훨씬 더 복잡한 유형 적용 시스템을 사용함
  • 이러한 차이점은 컨테이너 환경에서 특히 두드러짐
  • SELinux는 시스템의 모든 객체(파일, 프로세스, 포트 등)에 유형을 적용함
  • SELinux 지원 RHEL 시스템에서 컨테이너를 시작하면 즉시 엄격한 액세스 제어 메커니즘인 container_t 유형이 할당됨
  • container_t 유형은 컨테이너를 효과적으로 차단하여 컨테이너 사용을 위해 명시적으로 레이블이 지정되지 않은 객체와 상호 작용하지 못하도록 함
  • SELinux는 유형 적용에서 멈추지 않고 다중 범주 보안(MCS) 레이블을 사용하여 컨테이너 격리를 한 단계 더 진행함
  • 이러한 레이블은 동일한 유형(container_t)의 컨테이너 간에도 격리를 유지하는 추가 분리 계층 역할을 함
  • 각 컨테이너는 고유한 MCS 레이블을 받아 더 넓은 container_t 환경 내에서 사설 샌드박스를 만듦

AppArmor의 접근 방식

  • AppArmor는 유형이나 범주에 신경쓰지 않고 미리 정의된 프로필을 기반으로 특정 프로그램의 기능을 제한하는 데 중점을 둠
  • 이러한 프로필은 프로그램이 액세스할 수 있는 파일과 수행할 수 있는 작업을 지정함
  • 이 접근 방식은 구현하고 이해하기 더 간단하지만 SELinux의 유형 적용만큼 세분화되거나 시스템 전반에 걸쳐 일관되지 않음
  • 주류 Linux 배포판은 기본적으로 모든 일반적인 네트워크 지향 데몬에 대한 포괄적인 AppArmor 프로필을 배포하지 않음

실제 영향

  • SELinux 환경에서는 손상된 컨테이너가 유형 적용과 MCS 레이블이라는 이중 장벽 덕분에 호스트 시스템이나 다른 컨테이너에 액세스하거나 영향을 미치는 데 상당한 장애물에 직면함
  • SELinux는 더 강력한 격리를 제공하지만 복잡성 증가와 잠재적인 성능 오버헤드의 대가로 제공함
  • AppArmor는 적절하게 구성된 경우 여전히 매우 효과적일 수 있는 더 간단하고 접근하기 쉬운 보안 모델을 제공함
  • Red Hat은 SELinux와 컨테이너 사용을 원활하고 쉽게 만들기 위해 노력을 기울였음
  • 결국 Debian과 Red Hat 사이의 선택은 단순히 기업의 영향력과 커뮤니티 주도 개발 사이의 선택이 아님
  • 그것은 또한 최선을 가정하는 시스템과 최악의 상황에 대비하는 시스템 사이의 선택임
  • 오늘날의 고도로 연결된 세상에서 불행히도 비관주의는 필수임

GN⁺의 의견

  • Red Hat의 RHEL 소스 코드 배포 정책 변경은 논란의 여지가 있지만, 보안 관점에서는 합리적인 결정일 수 있음
  • 기업용 Linux 배포판에서는 SELinux와 같은 강력한 보안 기능 제공이 필수적임
  • 그러나 Red Hat의 정책 변경은 오픈 소스 생태계에 부정적인 영향을 미칠 수 있으며, Debian과 같은 커뮤니티 기반 배포판의 역할이 더욱 중요해질 것임
  • Debian은 사용자 친화적이고 유연한 배포판으로 알려져 있지만, 기본 보안 기능 강화가 필요함
  • AppArmor는 SELinux만큼 강력하지는 않지만, 적절히 구성하면 효과적인 보안 솔루션이 될 수 있음
  • 장기적으로는 SELinux와 AppArmor의 장점을 결합한 새로운 보안 프레임워크 개발이 필요할 수 있음
  • 컨테이너 보안은 클라우드 네이티브 시대에 매우 중요한 이슈이므로, 모든 배포판은 이 부분에 더 많은 노력을 기울여야 함
▲
koxel 3달전  [-]

Apparmor 가 selinux 보다 덜 엄격한것은 맞는데..
그게 보안이 취약하다곤 하기 힘들어요.
Selinux는 너무 엄격해서 서버 세팅하면 거진 다 selinux 꺼버립니다.
그리고 데스크탑은 보안은 selinux의 주요 관심사가 아닙니다.
Ui나 사용자 경험에서 필요한 제한 및 적절한 인증 요청 절차 등이 필요하고 이건 selinux 처럼 자원에 대한 격리와는 다른 이야기죠.
그래서 데탑 보안은 레뎃 계열이든 데비안 계열이든 모두 freedesktop 에서 표준화 되는 polkit (policykit) 기반으로 돌아갑니다.

답변달기
▲
neo 3달전  [-]
Hacker News 의견
  • 여러 RedHat 환경에서 SELinux를 비활성화하는 것이 일반적임
  • Debian의 업데이트가 느리다는 내용 대신 SELinux에 대해 배움
  • Debian이 일반적으로 덜 안전하다는 결론은 공정하지 않음
  • Debian은 컨테이너와 서버 사용에 덜 안전할 수 있음
  • 데스크탑 사용자에게는 Red Hat의 SELinux 구현이 큰 보호를 제공하지 않음
  • 커뮤니티 주도 프로젝트가 본질적으로 덜 안전하다는 암시를 좋아하지 않음
  • 자원 부족: Debian은 Red Hat과 비교하여 포괄적인 보안 정책을 개발하고 유지할 자원이 부족함
  • 컨테이너는 소프트웨어 배포 문제를 해결하지만 보안 문제를 해결하지 않음
  • 컨테이너는 보안 악몽이 될 수 있음
  • Red Hat의 결정이 오픈 소스 커뮤니티에서 부정적으로 해석됨
  • Red Hat 모델이 작은 기업에게는 어려움을 줌
  • IBM이 Red Hat을 인수한 후 생태계가 더 어려워짐
  • SELinux가 기본적으로 활성화되지 않은 Debian을 비판하는 것은 공정하지 않음
  • Linux는 Microsoft와 비교하여 포괄적인 보안 정책을 개발하고 유지할 자원이 부족함
  • SELinux의 복잡성 때문에 Debian으로 이동한 사용자도 있음
  • SELinux Coloring Book PDF를 통해 SELinux 기본을 학습할 수 있음
  • Debian에서도 SELinux를 활성화할 수 있음
  • SELinux에 열정적인 사람을 만나본 적이 없음
  • SELinux 정책을 설명할 수 있는 사람을 만나본 적이 없음
  • 많은 사람들이 SELinux를 비활성화함
  • 많은 사람들이 RedHat 배포판을 피함
  • 복잡성은 일반적으로 보안에 매우 나쁨
  • 이론적으로 완벽한 보안 시스템도 대부분의 사용자가 비활성화하면 불안전함
  • 매달 비밀번호를 변경하는 아이디어는 실제로 보안을 악화시킬 수 있음
답변달기