Lobste.rs 의견들

• 공개된 익스플로잇보다 취약점이 가능하게 하는 원시 동작에 초점을 맞춰야 함
  이 취약점은 읽기 전용 여부와 관계없이 페이지 캐시에 쓸 수 있게 하므로, 악성 컨테이너가 overlayfs의 베이스 이미지 파일에 속한 페이지를 변조할 수 있고, 컨테이너 배포 방식에 따라 다른 컨테이너로도 영향이 넘어갈 수 있음
  여기서의 rootless 구성이라면 호스트 시스템에서 같은 사용자로 실행되는 다른 컨테이너가 대상이 됨
  다른 익스플로잇 방식으로는, 이미 사용 중인 것으로 알려진 베이스 이미지 기반 컨테이너를 실행하거나 찾아서 그 컨테이너 안의 페이지 캐시를 변조한 뒤, 같은 런타임과 overlayfs 데이터를 공유하는 다른 컨테이너가 그 코드를 실행하게 만들 수 있음
  rootless와 사용자 네임스페이스는 중요하지만 여기서는 별 도움이 되지 않으며, copy.fail 사이트가 말하듯 컨테이너에서는 seccomp로 socket(AF_ALG, ...) 시스템 호출을 막는 쪽을 검토해야 함

  • 기본 원시 동작까지는 깊게 생각하지 못했고, rootless 컨테이너가 제공하는 네임스페이스와 capability를 정리해 침해된 컨테이너의 노출 범위를 평가하는 데 더 신경 썼음
    “컨테이너 배포 방식에 따라”가 구체적으로 무엇을 뜻하는지 더 설명해 주면 좋겠음
    rootless Podman의 장점은 워크로드에 따라 호스트에서 같은 사용자로 컨테이너를 실행할 필요가 없다는 점임
    주 워크스테이션 사용자로 여러 rootless 컨테이너를 돌리는 경우를 말한 거라면 동의하지만, 서버에서는 각각을 별도 사용자로 분리할 수 있고 같은 컨테이너 이미지도 서로 다른 비권한 사용자로 실행 가능함
    대부분을 root로 실행하는 Docker 기본값과는 꽤 다르지만, 이것이 궁극적인 보안 경계가 아니라는 점도 글 말미에 적었고, 여러 비권한 사용자에 rootless 컨테이너를 나눠 쓰는 방식이 적절한지는 용도에 따라 달라짐
    특정 워크로드는 VM으로 분리해 쓰고 있음
    rootless와 사용자 네임스페이스가 여기서 도움이 되지 않는다는 말이 익스플로잇 방지를 뜻하는지 궁금함
    seccomp는 아직 컨테이너에 명시적 정책을 써본 적이 없어 다루지 않았지만, 더 살펴볼 좋은 계기임

• Podman과 rootless 컨테이너를 좋아하지만, CopyFail을 보고 형제 댓글과 같은 결론에 도달했음
  podman+rootless의 추가 접근 제어 이점이 있어도 결국 컨테이너는 보안 경계가 아니다라는 고전적 조언을 다시 확인하게 됐고, 커널 익스플로잇 하나면 전부 뚫릴 수 있음
  취미로 시스템 관리를 하는 수준이지만, 이 영역의 새로운 흐름으로 libkrun backend for crun with podman을 봤음
  대부분의 컨테이너화된 워크로드를 그대로 다루면서도 내부적으로는 별도 게스트 커널을 가진 MicroVM에서 실행된다는 약속인데, 성숙도·실전 검증·보안 감사 수준은 잘 모르겠고 일부는 상당히 최첨단으로 보임
  MicroVM이 LLM 코딩 도구에서 적극적으로 채택되고 있어 그런 상태가 오래갈 수도 있음
  podman machine도 유망해 보였지만, 아쉽게도 개발자 워크스테이션 용도만 염두에 둔 것이고 호스트 시스템당 컨테이너 실행 VM을 하나만 두는 모델이었음
  그래도 “컨테이너는 보안 경계가 아니다”라는 말은 너무 단순하다고 봄. 컨테이너는 분명 보안 경계이지만, 우리가 믿고 싶은 만큼 강하지 않을 뿐임

  • 대부분의 클라우드 컨테이너 배포가 VM을 쓰는 이유도 같음. VM은 방어 가능한 경계임
    로컬 배포에서는 이 선이 좀 더 흐릿함
    하드웨어 관점에서 VM이 프로세스보다 본질적으로 더 안전한 것은 아니지만, 세 가지 이유로 경계가 더 방어 가능함
    VM 탈출은 시스템 호출보다 덜 흔하므로 성능 손상 없이 더 많은 부채널 완화를 적용할 여지가 있음
    VM의 호스트 인터페이스는 훨씬 단순함. 블록 장치는 블록 단위 읽기·쓰기 인터페이스가 있고, 네트워크 장치는 프레임을 보내고 받음
    Linux나 *BSD가 소켓에 제공하는 setsockopt 호출은 대부분의 에뮬레이션·반가상화 드라이버보다 훨씬 큰 공격 표면이고, 그조차 커널 전체 공격 표면의 아주 작은 일부임
    VM 인터페이스는 상태도 훨씬 적은 편임. 요청-응답 모델의 링에 진행 중인 트랜잭션은 있지만 그 외에는 거의 없음
    자격 증명, UID, GID, 파일 디스크립터 테이블 같은 것들은 커널에 상태 기반 복잡성을 추가하고, 버그가 있으면 프로세스가 이를 악용할 수 있음
    워크스테이션 변형의 어려움은 이런 복잡성을 다시 들여오게 된다는 점임
    예를 들어 컨테이너 베이스 레이어는 불변 파일시스템을 담은 블록 장치로 노출될 수 있지만, 볼륨과 공유 폴더는 아마 9pfs나 VirtIO-FS, 즉 VirtIO 위의 9p 또는 FUSE로 마운트될 것임
    그러면 공격 표면이 다시 커짐
    운이 좋다면 익스플로잇 체인이 필요함
    FreeBSD 쪽에 더 익숙한데, 보통 반가상화·에뮬레이션 장치를 제공하는 구성요소를 Capsicum으로 샌드박스 처리하므로 먼저 호스트 프로세스를 장악하고, 그다음 VM이 접근 권한이 없던 것에 접근하려면 커널까지 뚫어야 함
    하지만 이런 추가 샌드박싱을 하지 않으면 컨테이너 탈출이 사용자가 할 수 있는 모든 일을 할 수 있는 세계로 돌아가며, 데스크톱에서 root가 뚫린 것보다 크게 낫지 않음
  • Kata Containers와 Firecracker는 이미 꽤 오래된 기술이고, 연구자들이 검토해 왔기 때문에 합리적으로 성숙했다고 봄
    개인적으로는 gVisor를 더 선호함. VMM 런타임은 아니지만 몇 년째 존재했고, Tencent 같은 회사에서도 쓰이며, 모든 컨테이너를 이미 Proxmox VM 안에서 돌리는 내 환경에서는 잘 맞음
    또 테스트 중인 것은 syd-oci인데, MicroVM이나 gVisor라는 기본 추천지에 비해 다소 주목을 덜 받은 것 같음
  • 그 표현이 내 경험과도 맞고, 이 글을 쓰는 과정도 그 사실을 받아들이는 연습에 가까웠음
    libkrun 참고 자료도 고맙고, 유망한 가능성으로 보임
  • LLM 코딩 도구 쪽의 적극적인 채택은 MicroVM을 더 성숙하게 만들고, 실전 검증과 강화로 이어질 가능성이 큼
    보안 감사로 이어질 가능성도 높아 보임