containers/bubblewrapFlatpak 및 유사한 프로젝트에서 사용하는 저수준 비특권 샌드박싱 도구
systemd-nspawn, docker 등 많은 컨테이너 런타임 도구는 시스템 관리자와 오케스트레이션 도구(예: Kubernetes)가 컨테이너를 실행할 수 있도록 인프라를 제공하는 데 초점을 맞춥니다.
이러한 도구는 권한이 없는 사용자에게 제공하기에 적합하지 않습니다. 그러한 접근 권한을 호스트에서 완전한 권한을 가진 루트 셸로 바꾸는 것은 사소한 일이기 때문입니다.
Linux 커널에는 사용자 네임스페이스라는 기능이 있습니다. 이 기능은 권한이 없는 사용자도 컨테이너 기능을 사용할 수 있게 해줍니다. Bubblewrap은 이 기능을 사용하여 샌드박스를 구축하므로 모든 사용자가 이 도구를 사용할 수 있습니다.
과거에는 bubblewrap이 권한이 없는 사용자 네임스페이스를 지원하지 않는 시스템을 위해 setuid 모드도 지원했습니다. 그러나 이 모드는 제거되었습니다.
원래 bubblewrap 코드는 사용자 네임스페이스 이전에 존재했습니다. 이 코드는 xdg-app helper에서 파생되었으며, 이는 다시 linux-user-chroot에서 유래한 것입니다.
이 도구의 관리자들은 이 도구가 해당 배포판에 설치된 일반적인 소프트웨어와 함께 사용되더라도 권한 상승(privilege escalation)을 허용하지 않는다고 믿습니다. 다만 로그인한 사용자가 서비스 거부(denial of service) 공격을 수행할 수 있는 능력은 증가시킬 수 있습니다.
특히 bubblewrap은 PR_SET_NO_NEW_PRIVS를 사용하여 setuid 바이너리를 끄는데, 이는 chroot과 같은 환경에서 벗어나는 전통적인 방법입니다.
bubblewrap은 샌드박스 환경을 구축하기 위한 도구입니다. bubblewrap은 특정 보안 정책을 가진 완전하고 즉시 사용 가능한 샌드박스가 아닙니다.
bubblewrap의 일부 사용 사례는 샌드박스와 실제 시스템 사이의 보안 경계를 원합니다. 다른 사용 사례는 샌드박스 내부 프로세스를 위해 파일시스템 레이아웃을 변경하는 기능을 원하지만 보안 경계를 목표로 하지는 않습니다. 결과적으로 샌드박스 프로세스와 호스트 시스템 사이의 보호 수준은 전적으로 bubblewrap에 전달되는 인자에 의해 결정됩니다.
bubblewrap의 명령줄 인자를 구성하는 프로그램(종종 Flatpak, libgnome-desktop, sandwine 같은 더 큰 프레임워크 또는 임시 스크립트)은 자체 보안 모델을 정의하고 해당 보안 모델을 구현하기 위한 적절한 bubblewrap 명령줄 인자를 선택할 책임이 있습니다.
특별한 주의가 필요한 샌드박스 보안의 일부 측면은 아래의 제한 사항 섹션에 설명되어 있습니다.
이 프로그램은 루트가 아닌 사용자로 실행되는 모든 컨테이너 도구가 공유할 수 있습니다. 예를 들어 다음과 같습니다.
또한 이 도구가 Kubernetes/OpenShift 클러스터에서 사용 가능해지기를 바랍니다. 권한이 없는 사용자가 컨테이너 기능을 사용할 수 있게 되면 대화형 디버깅 시나리오 등을 훨씬 더 쉽게 수행할 수 있습니다.
bubblewrap은 대부분의 Linux 배포판 패키지 저장소에서 제공되며 그곳에서 설치할 수 있습니다.
소스에서 bubblewrap을 빌드해야 한다면 meson을 사용하여 다음과 같이 할 수 있습니다:
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap은 호스트에서 보이지 않는 tmpfs에 루트가 있는 새롭고 완전히 비어 있는 마운트 네임스페이스를 생성하여 동작합니다. 이 네임스페이스는 마지막 프로세스가 종료되면 자동으로 정리됩니다. 그런 다음 명령줄 옵션을 사용하여 루트 파일시스템, 프로세스 환경, 네임스페이스에서 실행할 명령을 구성할 수 있습니다.
소스 코드에는 더 큰 데모 스크립트가 있습니다. 여기서는 호스트의 /usr을 재사용하여 새 셸을 실행하는 간략한 버전을 보여드립니다.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
이 예제는 완전하지 않지만 설명을 위한 용도로 유용합니다. 호스트의 파일시스템 트리를 사용하여 컨테이너를 만드는 대신 chroot를 대상으로 하는 경우가 더 많습니다. 그런 경우 tmpfs에 lib64 -> usr/lib64 심볼릭 링크를 만드는 대신 대상 rootfs에 이미 만들어 두었을 수도 있습니다.
bubblewrap의 목표는 애플리케이션을 샌드박스 안에서 실행하는 것입니다. 이 샌드박스에서는 운영 체제의 일부 또는 홈 디렉터리와 같은 사용자 데이터에 대한 접근이 제한됩니다.
bubblewrap은 항상 새 마운트 네임스페이스를 생성하며, 사용자는 샌드박스에 표시할 파일시스템 부분을 정확히 지정할 수 있습니다. 지정한 디렉터리는 기본적으로 nodev로 마운트되며 읽기 전용으로 만들 수 있습니다.
또한 다음과 같은 커널 기능을 사용할 수 있습니다:
사용자 네임스페이스 (CLONE_NEWUSER): 샌드박스에서 현재 uid와 gid를 제외한 모든 것을 숨깁니다. 샌드박스에서 uid/gid 값을 변경할 수도 있습니다.
IPC 네임스페이스 (CLONE_NEWIPC): 샌드박스는 SysV 공유 메모리나 세마포어와 같은 모든 형태의 IPC 복사본을 갖게 됩니다.
PID 네임스페이스 (CLONE_NEWPID): 샌드박스는 샌드박스 외부의 프로세스를 볼 수 없습니다. 또한 bubblewrap은 샌드박스에서 자식 프로세스를 수거해야 하는 요구 사항을 처리하기 위해 컨테이너 내부에서 간단한 pid1을 실행합니다. 이로 인해 현재 Docker pid 1 문제로 알려진 문제를 피할 수 있습니다.
네트워크 네임스페이스 (CLONE_NEWNET): 샌드박스는 네트워크를 볼 수 없습니다. 대신 루프백 장치만 있는 자체 네트워크 네임스페이스를 갖게 됩니다.
UTS 네임스페이스 (CLONE_NEWUTS): 샌드박스는 자체 호스트 이름을 갖게 됩니다.
Seccomp 필터: 샌드박스에서 수행할 수 있는 시스템 호출을 제한하는 seccomp 필터를 전달할 수 있습니다. 자세한 내용은 Seccomp를 참조하십시오.
위의 샌드박스 보안 섹션에서 언급했듯이 샌드박스 프로세스와 호스트 시스템 사이의 보호 수준은 전적으로 bubblewrap에 전달되는 인자에 의해 결정됩니다. 특별한 주의가 필요한 몇 가지 측면은 다음과 같습니다.
seccomp 필터를 사용하여 TIOCSTI 명령을 필터링하지 않는 경우 샌드박스 외부에서 명령이 실행되는 것을 방지하려면 --new-session 인자가 필요합니다(CVE-2017-5226 참조).
샌드박스에 마운트된 모든 것은 잠재적으로 권한 상승에 사용될 수 있습니다. 예를 들어 D-Bus 소켓을 샌드박스에 바인드하면 systemd를 통해 명령을 실행하는 데 사용될 수 있습니다. xdg-dbus-proxy를 사용하여 D-Bus 통신을 필터링할 수 있습니다.
일부 애플리케이션은 자체 샌드박싱 메커니즘을 사용하는데, 이는 bubblewrap의 샌드박싱이 부과하는 제약에 의해 제한될 수 있습니다. 예를 들어 일부 웹 브라우저는 seccomp를 통해 자식 프로세스가 파일시스템에 접근할 수 없도록 구성합니다. 시스템 호출을 제한하고 seccomp 시스템 호출을 허용하지 않으면 브라우저는 이러한 제한을 적용할 수 없습니다. 마찬가지로 이러한 규칙이 샌드박스에서 사용할 수 없는 파일로 컴파일된 경우 브라우저는 이 파일에서 규칙을 로드할 수 없으므로 이러한 제한을 적용할 수 없습니다.
Firejail은 bubblewrap이 분리되기 전의 Flatpak과 유사하게 setuid 도구와 많은 데스크톱 특화 샌드박싱 기능을 결합합니다. 예를 들어 Firejail은 Pulseaudio를 알고 있지만 bubblewrap은 그렇지 않습니다.
bubblewrap 개발자들은 작은 setuid 프로그램을 감사하는 것이 훨씬 쉽고, 현재 Flatpak에서와 같이 Pulseaudio 필터링과 같은 기능을 권한이 없는 프로세스로 유지하는 것이 낫다고 생각합니다.
또한 @cgwalters는 사용자가 경로를 조작할 수 있는 무수한 방법과 시스템 관리자가 시스템을 구성할 수 있는 무수한 방법을 고려할 때 파일 경로 화이트리스트를 시도하는 것은 나쁜 생각이라고 생각합니다. bubblewrap의 접근 방식은 CAP_SYS_ADMIN과 같은 몇 가지 특정 Linux 기능만 유지하고, 파일시스템에는 항상 호출한 uid로 접근하는 것입니다. 이를 통해 TOCTTOU 공격 등을 완전히 차단합니다.
Sandstorm.io은 샌드박스를 설정하기 위해 권한이 없는 사용자 네임스페이스가 필요하지만, setuid 모드로 작동하도록 쉽게 조정할 수도 있습니다. @cgwalters는 그들의 코드가 상당히 좋다고 생각하지만 bubblewrap으로 통합하는 것이 여전히 합리적일 수 있다고 봅니다. 그러나 Sandstorm의 @kentonv는 원칙적으로는 타당하지만 현재로서는 전환 비용이 실질적인 이점보다 크다고 생각합니다. 이 결정은 향후 재평가될 수 있지만 현재 적극적으로 추진되지는 않고 있습니다.
runC는 현재 루트리스 컨테이너(rootless containers) 지원을 위해 작업 중입니다. 이는 runC를 설치하고 컨테이너를 생성 및 관리하는 동안 setuid나 다른 권한이 필요하지 않습니다(setuid 대신 권한이 없는 사용자 네임스페이스 사용). 그러나 runC의 표준 사용 방식은 systemd nspawn과 유사하게 루트가 호출하도록 만들어진 도구입니다.
bubblewrap 개발자들은 runc와 systemd-nspawn이 setuid로 만들어지도록 설계되지 않았으며 그러한 모드를 지원하기에는 아직 멀었다고 생각합니다. 그러나 루트리스 컨테이너를 통해 runC는 bubblewrap이 지원하는 특정 사용 사례를 충족할 수 있게 될 것입니다(표준화되고 완전한 OCI 런타임이라는 추가 이점도 있습니다).
binctr은 단지 runC용 래퍼일 뿐이므로 runC의 모든 설계 트레이드오프를 그대로 물려받습니다.
bubblewrap이라는 이름은 이 도구가 애플리케이션의 부모 프로세스로 실행되어(어떤 의미에서는 애플리케이션을 감싸고) 그 주위에 보호 계층(샌드박스)을 만든다는 것을 나타내기 위해 선택되었습니다.
(Bubblewrap 고양이 by dancing_stupidity)