# 데비안의 취약성(Insecurity) > Clean Markdown view of GeekNews topic #16628. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=16628](https://news.hada.io/topic?id=16628) - GeekNews Markdown: [https://news.hada.io/topic/16628.md](https://news.hada.io/topic/16628.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2024-09-06T09:52:52+09:00 - Updated: 2024-09-06T09:52:52+09:00 - Original source: [unix.foo](https://unix.foo/posts/insecurity-of-debian/) - Points: 3 - Comments: 2 ## Topic Body ### 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의 장점을 결합한 새로운 보안 프레임워크 개발이 필요할 수 있음 - 컨테이너 보안은 클라우드 네이티브 시대에 매우 중요한 이슈이므로, 모든 배포판은 이 부분에 더 많은 노력을 기울여야 함 ## Comments ### Comment 28680 - Author: koxel - Created: 2024-09-07T11:46:10+09:00 - Points: 1 Apparmor 가 selinux 보다 덜 엄격한것은 맞는데.. 그게 보안이 취약하다곤 하기 힘들어요. Selinux는 너무 엄격해서 서버 세팅하면 거진 다 selinux 꺼버립니다. 그리고 데스크탑은 보안은 selinux의 주요 관심사가 아닙니다. Ui나 사용자 경험에서 필요한 제한 및 적절한 인증 요청 절차 등이 필요하고 이건 selinux 처럼 자원에 대한 격리와는 다른 이야기죠. 그래서 데탑 보안은 레뎃 계열이든 데비안 계열이든 모두 freedesktop 에서 표준화 되는 polkit (policykit) 기반으로 돌아갑니다. ### Comment 28626 - Author: neo - Created: 2024-09-06T09:52:53+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=41446428) - 여러 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 배포판을 피함 - 복잡성은 일반적으로 보안에 매우 나쁨 - 이론적으로 완벽한 보안 시스템도 대부분의 사용자가 비활성화하면 불안전함 - 매달 비밀번호를 변경하는 아이디어는 실제로 보안을 악화시킬 수 있음