9P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 커널 모드와 사용자 모드 실행을 모두 지원하는 보안 중심 라이브러리 OS로, 호스트 인터페이스를 최소화해 공격 표면을 줄이는 샌드박싱 환경 제공
  • Rust 기반으로 작성되었으며, nixrustix 스타일의 상위 인터페이스와 다양한 하위 플랫폼 간의 상호 운용을 지원
  • 주요 활용 사례: Windows에서 리눅스 프로그램 실행, 리눅스 애플리케이션 샌드박싱, SEV SNP 및 OP-TEE 환경 실행, LVBS 플랫폼 지원
  • 보안 격리, 가상화, 시스템 인터페이스 최소화를 중점으로 한 차세대 OS 아키텍처 실험 기반
  • Rust 기반의 안전한 시스템 코드와 커널-유저 모드 통합 실행 모델을 결합해, 보안 연구 및 클라우드 격리 기술 개발에 활용 가능

LiteBox 개요

  • LiteBox는 Microsoft가 공개한 오픈소스 보안 중심 라이브러리 OS로, 커널 및 사용자 모드 실행을 모두 지원
    • 핵심 목표는 호스트와의 인터페이스를 최소화하여 공격 표면을 줄이는 것
    • 이를 통해 샌드박스 형태의 격리된 실행 환경을 구현
  • 시스템은 Rust 언어로 작성되어 있으며, 상위 계층에서는 nix/rustix 스타일의 인터페이스를 제공
    • 하위 계층에서는 다양한 플랫폼(Platform 인터페이스)을 연결해 유연한 구성 가능

주요 기능 및 사용 사례

  • LiteBox는 여러 운영 환경 간의 상호 운용을 지원하는 구조로 설계
    • 리눅스 프로그램을 Windows에서 실행
    • 리눅스 내 애플리케이션 샌드박싱
    • SEV SNP 기반 보안 실행 환경 지원
    • OP-TEE 프로그램을 리눅스에서 실행
    • LVBS 플랫폼에서의 실행 지원

현재 단계 및 라이선스

  • 프로젝트는 현재 활발히 발전 중이며, 안정 버전 출시 전 단계
    • API와 인터페이스는 향후 변경될 수 있음
    • 실험적 사용은 가능하나, 장기적 안정성을 요구하는 환경에서는 주의 필요
  • MIT 라이선스
Hacker News 의견들
  • GitHub 페이지에 따르면 LiteBox는 호스트 인터페이스를 최소화해 공격 표면을 줄이는 샌드박싱 라이브러리 OS
    Rust 스타일의 nix/rustix 기반 “North” 인터페이스와 다양한 “South” 플랫폼을 연결할 수 있게 설계되었음
    예시로는 Linux 프로그램을 Windows에서 실행하거나, Linux 앱을 샌드박싱하거나, SEV SNP·OP-TEE·LVBS 위에서 구동하는 경우가 있음

    • “수정 없는 Linux 프로그램을 Windows에서 실행”하는 부분이 가장 흥미로움
      예전부터 WSL2는 임시방편 같았고, WSL1이야말로 Windows NT의 “personality modules” 개념을 잘 구현한 예라고 생각했음
    • 관련 논의는 Reddit 스레드James Morris의 발표 글에서도 볼 수 있음
    • 혹시 이게 WSLv1.2 같은 개념으로, 좀 더 범용적인 크로스플랫폼 라이브러리형 방화벽이 된 것인지 궁금함
    • README의 기술 마케팅 용어가 너무 많아서 실제로 뭘 하는 프로젝트인지 이해하는 데 시간이 걸렸음
      Microsoft가 기존 개념을 새 이름으로 포장해 마치 혁신처럼 보이게 하는 전형적인 사례 같음
  • 요즘 Microsoft의 주력 OS가 너무 버그투성이라, 새로 내놓는 프로젝트를 신뢰하기 어렵다는 생각임

    • Microsoft에는 10만 명이 넘는 엔지니어가 있으니, Windows의 버그 때문에 모든 제품을 싸잡아 나쁘다고 보는 건 무리라고 생각함
    • Windows의 UI는 불안정하지만, 커널과 저수준 부분은 꽤 안정적이고 훌륭함
    • LiteBox는 Windows 대체용이 아니고, GUI 데스크톱 OS도 아님
      이걸 개발하는 팀은 현대 Windows UX와는 전혀 관련이 없을 것 같음
    • Windows 11이 버그와 Copilot 문제로 욕을 먹는 건 알지만, 이런 포럼에서는 Microsoft라는 이유만으로 제품을 평가절하하는 에코 챔버 현상이 있는 듯함
    • Windows는 폐쇄적이고 복잡하지만, LiteBox는 Linux 생태계 위에서 동작하므로 엔지니어링 문화가 다를 것이라 기대함
  • LiteBox 저장소에 Copilot 관련 설정 파일이 포함되어 있음
    copilot-instructions.md

    • 요즘 많은 조직이 OKR 달성을 위해 AI 사용을 요구하니, 이런 설정이 있는 건 자연스러움
    • 사실상 대부분의 프로젝트가 어느 정도 AI 생성 코드를 포함하고 있음
      이건 단지 명시적으로 설정을 드러낸 것뿐임
    • “아주 단순한 변경은 단위 테스트가 필요 없다”는 문구가 있는데, 이런 예외 규칙을 명확히 정의하지 않으면 LLM이 직관적으로 따르지 못하는 경우가 많음
  • Library OS’가 뭔지 궁금했음

    • OS가 제공하던 인터페이스(syscall, ioctl 등)를 라이브러리 형태로 앱에 직접 링크하는 구조임
      즉, OS 기능이 애플리케이션 주소 공간에 통합되고 외부 인터페이스는 하드웨어 접근이나 하이퍼콜로 바뀜
      Unikernel이 이런 방식으로 동작하며, Wine도 넓은 의미에서 Library OS로 볼 수 있음
      예를 들어 Linux 앱을 LiteBox에 링크해 SEV-SNP 위에서 실행하거나, OP-TEE TA를 Linux에서 돌릴 수 있음
      핵심은 POSIX syscall 수백 개를 감사하는 대신, 중간 표현의 몇 가지 원시 연산만 제어하도록 단순화했다는 점임
    • 쉽게 말해 OS를 라이브러리처럼 링크해, 실제 시스템의 API를 축소된 형태로 노출시켜 공격 표면을 줄이는 샌드박스
    • Wikipedia의 설명도 참고할 만함
  • 외계인에게 Library OS와 커널 기반 앱의 차이를 설명해야 한다면, 진지하게 설명하기 어려울 정도로 미묘한 차이라고 느껴짐

    • 진짜 Library OS라면 시스템 콜이 없고, 사용자/커널 공간 구분 없이 동일한 공간에서 동작함
  • 처음엔 ‘Library OS’가 도서관용 운영체제인 줄 알았음

    • 나도 그랬음. 예전의 Dynix 같은 걸 떠올리며 잠시 향수에 젖었음
    • 사실상 OS를 링크하면 별도의 OS 없이 슈퍼바이저 위에서 직접 실행할 수 있는 구조로 이해함
    • “공공 도서관용 OS라니 흥미롭다”고 생각했는데, 아니어서 조금 아쉬웠음
  • Library OS 개념이 생소했는데, 설명을 듣고 보니 Unikernel과 유사
    프로그램이 커널 모드 호출 없이 하이퍼바이저 위에서 직접 실행되며, LiteBox는 Linux·Windows·BSD 프로세스로도 동작 가능함

    • 또 다른 관점에서는, 프로그램이 직접 OS를 쓰지 않고 공통 인터페이스 안에서 격리 실행되는 샌드박스처럼 보임
      다만 자체 ABI를 쓰는지, 호스트 OS의 ABI를 쓰는지는 불분명함
      설명을 보면 약간 ‘vibe-coded’ 프로젝트 느낌도 있음
  • 만약 Microsoft가 LiteBox를 통해 WFP 콜아웃 드라이버를 서명 없이 작성할 수 있게 한다면 흥미로울 것 같음
    여전히 커널 모드에서 동작하겠지만, MacOS의 NetworkExtensions보다 유연할 수 있음

  • 설계 명세와 형식 검증(formal verification) 을 기반으로 한 개발 절차가 언급되지 않은 점이 아쉬움
    흥미로운 시도이긴 하지만, 이런 접근이 없으면 Windows에서 반복된 보안 취약점이 다시 나타날 위험이 있음

    • 요즘은 Rust로 작성됐다는 이유만으로 자동으로 안전하다고 믿는 경향이 있는 듯함
  • “Library OS”라는 개념을 처음 들었는데, 혹시 gVisor도 여기에 포함되는지 궁금함
    비슷한 구조처럼 보이지만, 정확히 같은 범주인지는 잘 모르겠음