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

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의 장점을 결합한 새로운 보안 프레임워크 개발이 필요할 수 있음
• 컨테이너 보안은 클라우드 네이티브 시대에 매우 중요한 이슈이므로, 모든 배포판은 이 부분에 더 많은 노력을 기울여야 함