seccomp

3 개의 포스트

figma

서버 사이드 샌드박 (새 탭에서 열림)

VM은 게스트 운영체제마다 CPU·메모리·디스크를 제공해 강한 격리 경계를 만드는 샌드박싱 방식이다. 하지만 보안은 VM 자체만으로 완성되지 않으며, 하이퍼바이저의 취약점으로 인한 VM 탈출과 VM 권한을 악용한 데이터 유출을 함께 고려해야 한다. Figma는 취약점을 완전히 제거하기보다 서버 측 샌드박싱으로 침해 발생 시 피해 범위를 줄이는 접근을 취한다. ## 서버 측 샌드박싱의 목적 - 신뢰할 수 없는 작업이나 악성 작업을 별도의 실행 환경에 격리한다. - 목표는 모든 보안 취약점을 예방하는 것이 아니라, 취약점이 악용되어도 호스트와 다른 시스템으로 피해가 확산되지 않도록 하는 것이다. - 서버 측 샌드박싱의 대표적인 접근 방식으로 VM, 컨테이너, seccomp가 소개된다. - VM은 컨테이너나 seccomp보다 무겁지만, 별도의 게스트 운영체제를 제공해 더 강한 격리 모델을 구성할 수 있다. ## VM의 보안 모델 VM 보안은 크게 하이퍼바이저 경계와 VM 권한이라는 두 요소로 나뉜다. - **VM과 호스트의 분리** - 하이퍼바이저는 물리 서버의 자원을 관리하고 여러 VM을 동시에 실행한다. - 게스트 VM과 호스트 시스템, 그리고 서로 다른 게스트 VM 사이의 접근을 차단한다. - **VM 탈출** - 게스트 내부의 악성 프로그램이 하이퍼바이저 취약점을 이용해 호스트 시스템에 접근하는 공격이다. - VM 탈출이 성공하면 호스트 장악, 다른 VM과의 상호작용, 다른 게스트의 정보 획득 등이 가능해질 수 있다. - **하이퍼바이저의 공격 표면** - 하이퍼바이저는 운영체제와 하드웨어 작업을 폭넓게 중재하므로 코드와 기능이 복잡하다. - 따라서 VM 격리는 강력하지만, 하이퍼바이저 자체가 중요한 보안 경계이자 공격 대상이 된다. - 클라우드 IaaS 사업자 대부분이 테넌트 격리에 VM을 사용하므로, 베어메탈 인스턴스를 사용하지 않는다면 사실상 하이퍼바이저 보안에 의존하게 된다. ## VM 권한과 피해 범위 VM 탈출이 발생하지 않더라도 악성 작업은 VM에 부여된 권한을 이용해 피해를 일으킬 수 있다. - VM 내부 프로세스가 네트워크에 접근하면 민감한 데이터를 외부로 유출할 수 있다. - VM의 인증 정보로 다른 서비스나 시스템 API를 호출할 수도 있다. - 따라서 VM 내부에 작업을 넣는 것만으로는 충분하지 않다. - 네트워크 접근, 서비스 자격 증명, 파일 및 시스템 권한 등을 제한해 침해 시 **blast radius**를 줄여야 한다. - 하이퍼바이저를 직접 수정하기 어려운 환경에서는 VM의 기능과 권한을 세밀하게 구성하는 방어가 특히 중요하다. ## 엔지니어링 관점의 고려사항 - VM은 강한 격리를 제공하지만 컨테이너나 seccomp보다 실행 비용과 운영 복잡성이 크다. - 하이퍼바이저를 직접 개발하거나 공격 표면을 깊이 분석해야 하는 시스템은 구현 난도가 높다. - 보안 설계 시 “VM에서 탈출할 수 있는가?”뿐 아니라 “탈출하지 않고도 어떤 시스템에 접근할 수 있는가?”를 함께 검토해야 한다. - 격리 기술 선택은 보안 강도, 성능, 비용, 운영 편의성, 클라우드 인프라의 신뢰 모델 사이의 절충이다. VM을 사용할 때는 최신 하이퍼바이저 보안 패치와 격리 설정을 유지하는 동시에, 네트워크·자격 증명·서비스 권한을 최소화하는 다층 방어를 적용하는 것이 좋다. VM은 강력한 첫 번째 경계이지만, 권한 제한 없이는 완전한 보안 대책이 될 수 없다.

figma

서버 측 샌드박싱 (새 탭에서 열림)

서버 측 샌드박싱은 악성 입력을 처리하는 애플리케이션의 취약점이 전체 인프라로 확산되는 것을 막는 방어 계층이다. 이미지·데이터 처리 라이브러리처럼 메모리 안전성이 낮고 취약점이 반복적으로 발견되는 소프트웨어를 완전히 제거하거나 재작성하기는 현실적으로 어렵기 때문에, VM·컨테이너·seccomp 등을 이용해 실행 환경과 접근 가능한 자원을 제한해야 한다. 중요한 것은 특정 기술 하나를 선택하는 것이 아니라 보안성, 운영 복잡도, 성능, 격리 수준 사이의 트레이드오프를 workload 특성에 맞게 평가하는 것이다. ## 사용자 입력을 처리할 때 발생하는 위험 - 이미지 처리, 파싱, 압축, 썸네일 생성은 SaaS 애플리케이션에서 흔히 필요한 작업이다. - 이러한 기능은 C++ 같은 메모리 비안전 언어로 작성된 라이브러리에 의존하는 경우가 많다. - 해당 라이브러리는 원래 악의적인 입력을 처리하도록 설계되지 않았으며, 메모리 손상 취약점이 반복적으로 발견되어 왔다. - 대표적인 사례가 2016년 ImageMagick에서 발견된 **ImageTragick**이다. - 사용자가 제공한 이미지를 서버에서 처리하는 서비스가 원격 코드 실행 공격에 노출될 수 있었다. - 모든 버그와 취약점을 사전에 제거하는 것은 사실상 불가능하므로, 취약점이 발생하더라도 피해 범위를 제한하는 방어책이 필요하다. ## 서버 측 샌드박싱의 역할 - 샌드박싱은 애플리케이션이나 작업을 제한된 환경에서 실행하는 **workload isolation** 기법이다. - 공격자가 취약한 작업을 장악하더라도 다음과 같은 접근을 제한하는 것이 목표다. - 다른 작업의 사용자 데이터 - 운영 환경의 내부 서비스 - 파일 시스템과 네트워크 자원 - 추가 시스템으로의 lateral movement - Figma는 C++로 작성된 서버 측 렌더링 시스템인 RenderServer와 사용자 생성 그래픽 데이터를 처리하는 서드파티 라이브러리를 사용한다. - 이러한 작업을 인프라 내부에서 직접 실행하면 단 하나의 심각한 버그가 다른 사용자 데이터나 운영 시스템 침해로 이어질 수 있다. - 모든 unsafe 코드를 메모리 안전 언어로 다시 작성하고 정적 분석으로 정확성을 증명하는 방법도 있지만, 비용과 시간이 크며 완벽한 보안을 보장하지도 않는다. - 따라서 취약점 예방과 함께, 취약점이 악용되었을 때 영향 범위를 줄이는 격리 전략을 병행한다. ## VM, 컨테이너, seccomp - 글에서는 서버 측 샌드박싱의 대표적인 구현 방식으로 다음 세 가지를 소개한다. - **가상 머신(VM)**: 하이퍼바이저 위에서 각 게스트 운영체제를 실행한다. 인프라와 작업 사이에 하이퍼바이저 및 게스트 OS 계층이 존재한다. - **컨테이너**: 호스트 운영체제의 기능과 커널을 공유하면서 컨테이너 엔진을 통해 작업을 분리한다. VM보다 가볍게 실행할 수 있지만 격리 특성이 다르다. - **seccomp**: 프로세스가 호출할 수 있는 시스템 콜을 제한하는 Linux 보안 기능이다. - 각 방식은 격리 강도, 실행 비용, 성능, 시작 시간, 운영 편의성, 설정 복잡도 등에서 서로 다른 특성을 가진다. - 실제 환경에서는 단일 기술만 사용하기보다 workload의 신뢰 수준과 필요한 권한에 따라 여러 샌드박싱 primitive를 조합할 수 있다. ## 샌드박싱 선택 시 고려할 점 - 샌드박싱은 보안 취약점을 없애는 기술이 아니라, 취약점이 발생했을 때 공격의 범위와 피해를 제한하는 방어 계층이다. - 선택 과정에서는 다음을 함께 검토해야 한다. - 처리 대상이 사용자 입력인지, 내부에서 신뢰할 수 있는 데이터인지 - 작업이 필요한 파일·네트워크·시스템 콜의 범위 - 강한 격리에 필요한 성능 및 비용 - 샌드박스의 생성·폐기와 패치·모니터링 운영 부담 - 샌드박스 자체의 탈출 가능성과 호스트에 미치는 영향 - 샌드박싱 기술은 과거보다 안정적이고 실용적으로 발전했지만, 여전히 보안 연구와 운영 경험이 중요한 분야다. 악성 입력을 처리하는 기능은 메모리 안전 언어로의 전환만으로 보호하려 하기보다, 최소 권한과 강한 실행 격리를 함께 적용하는 것이 현실적이다. 특히 사용자 데이터를 다루는 고위험 작업은 VM이나 컨테이너 격리를 검토하고, 불필요한 시스템 콜은 seccomp로 추가 제한하는 접근이 유용하다.

figma

서버 측 샌드박싱 (새 탭에서 열림)

컨테이너와 seccomp는 가상 머신보다 가볍게 서버 측 작업을 격리할 수 있지만, 기본 설정만으로 안전한 샌드박스가 되는 것은 아니다. 컨테이너 탈출 위험은 런타임 구현, 운영체제 커널 기능, 런타임 설정에 좌우되며, 침해된 컨테이너가 호스트나 다른 시스템에 미치는 영향까지 함께 제한해야 한다. Figma는 컨테이너의 OS 수준 격리 기능과 seccomp를 활용해 성능과 보안 사이의 균형을 맞추고 있다. ## 컨테이너와 가상 머신의 차이 - 가상 머신은 하이퍼바이저를 통해 운영체제 수준에서 격리한다. - 컨테이너는 호스트 OS의 커널 기능을 공유하며, 다음과 같은 기능을 이용해 격리한다. - Linux namespaces - cgroups - 권한 강등(privilege dropping) - seccomp - SELinux, AppArmor 같은 필수 접근 제어(MAC) - 컨테이너는 VM보다 가볍고 효율적이지만, 격리 수준을 사용자가 직접 세밀하게 설정해야 한다. - 설정 자유도가 높은 만큼 잘못된 구성으로 인해 보안 취약점이 발생할 가능성도 크다. ## 샌드박싱이 필요한 이유 - 이미지 처리와 데이터 파싱처럼 애플리케이션에 필수적인 기능은 외부 입력을 다루므로 취약점 위험을 포함한다. - 모든 보안 취약점을 사전에 제거하는 것은 비용이 많이 들고 현실적으로 어렵다. - 따라서 취약한 작업이 실행되더라도 호스트와 다른 시스템으로 피해가 확산되지 않도록 서버 측 샌드박싱, 즉 workload isolation을 적용한다. - 격리 설계에서는 두 가지 질문을 중심으로 보안성을 평가한다. - 악성 작업이 컨테이너에서 탈출해 호스트를 변경하거나 장악할 수 있는가? - 컨테이너를 탈출하지 못하더라도 컨테이너 권한으로 다른 시스템에 접근하거나 피해를 줄 수 있는가? ## 컨테이너에서 호스트로 이어지는 공격 표면 컨테이너 탈출 가능성은 컨테이너 자체보다 여러 구성 요소의 조합에 의해 결정된다. - 주요 공격 표면은 다음 세 가지다. - 컨테이너 런타임 구현의 버그 - 런타임이 사용하는 운영체제 커널 기능과 인터페이스 - 런타임 보안 설정 및 구성 오류 - Linux 환경에서 Docker는 일반적으로 runC 런타임을 사용한다. - runC와 Docker는 namespaces, cgroups, 권한 강등, seccomp, SELinux, AppArmor 등을 조합해 격리를 제공한다. - 커널 취약점이나 런타임 구현 오류, 잘못된 설정이 있으면 악성 작업이 다음과 같은 행위를 할 수 있다. - 호스트 파일 수정 - 호스트에서 코드 실행 - 컨테이너 탈출 - 컨테이너의 기본 설정이 과거보다 안전해졌더라도, 특정 샌드박싱 용도에 충분한지는 사용자가 직접 검증해야 한다. ## 침해된 컨테이너의 피해 제한 컨테이너 내부에서 작업이 침해되었다고 가정하고, 호스트뿐 아니라 주변 시스템에 대한 접근도 차단해야 한다. - 컨테이너 설정을 강화해 호스트 장악을 방지해야 한다. - 컨테이너에 다음 자원을 불필요하게 제공하지 않는 것이 중요하다. - 네트워크 장치 - 인증 자격 증명 - 다른 작업의 데이터 - 컨테이너를 별도의 격리된 네트워크에 배치할 수 있다. - 오케스트레이션 시스템을 사용해 입력은 통제된 채널로 전달하고, 출력도 검증·제한된 방식으로 수집한다. - 핵심은 “컨테이너가 침해되지 않을 것”이 아니라 “침해되더라도 피해 범위를 제한할 것”이라는 방어적 설계다. ## seccomp의 역할 - seccomp(secure computing mode)는 프로그램이 호출할 수 있는 시스템 콜을 제한하는 Linux 기능이다. - 시스템 콜을 허용 목록 또는 제한 정책으로 관리하면, 컨테이너 프로세스가 커널과 상호작용할 수 있는 범위를 줄일 수 있다. - 컨테이너 격리는 런타임, 커널 기능, 설정의 결합으로 구현되므로 seccomp 역시 다른 보안 기능과 함께 사용해야 한다. - 제공된 글 내용은 seccomp 보안 모델을 소개하는 부분에서 중단되어 있어, 이후 Figma의 구체적인 nsjail 구성과 운영 방식은 확인할 수 없다. 컨테이너를 서버 측 샌드박스로 사용할 때는 기본 설정을 그대로 신뢰하지 말고, 최소 권한·제한된 시스템 콜·격리된 네트워크·자격 증명 차단을 함께 적용하는 것이 좋다. 특히 컨테이너 탈출 방지와 침해 이후 피해 제한을 별개의 보안 목표로 보고 설계해야 한다.