| chroot | |
| 원저자 | Bill Joy 외(AT&T 벨 연구소) |
| 최초 출시 | 1979년[1] |
| 운영체제 | Unix, Unix 계열, Plan 9, Inferno |
| 플랫폼 | 크로스 플랫폼 |
| 종류 | 셸 명령어 / 시스템 콜 |
1. 개요
chroot(change root)는 유닉스 및 유닉스 계열 운영체제에서, 현재 실행 중인 프로세스와 그 자식 프로세스들이 인식하는 루트 디렉터리를 다른 위치로 바꿔주는 셸 명령이자 시스템 콜이다. chroot로 지정된 환경 안에서 실행되는 프로그램은 지정된 디렉터리 트리 바깥에 있는 파일의 경로 자체를 지칭할 수 없게 되고, 그 결과 보통은 그 바깥 파일에 접근할 수도 없게 된다.chroot라는 이름은 문맥에 따라 chroot(2) 시스템 콜 자체를 가리키기도 하고, chroot(8) 명령줄 유틸리티를 가리키기도 한다. 이렇게 수정된 실행 환경은 흔히 chroot 감옥(chroot jail)이라고 부른다.
2. 역사
chroot 시스템 콜은 1979년 Version 7 Unix(7th Edition Unix) 개발 과정에서 처음 도입되었다. 벨 연구소가 만든 V7 커널 소스 안에서 시스템 콜 61번으로 구현되었으며, 당시엔 슈퍼유저만 사용할 수 있는 기능이었다. 함께 제공된 chroot(1) 명령은 보통 `/etc` 아래에 위치했고, 사용자가 지정한 새 루트 디렉터리 안에서 명령이나 대화형 셸을 실행할 수 있게 해 주는 초창기 형태의 환경 격리 도구였다.BSD 계열로의 도입 시점에 대해서는 한동안 혼선이 있었다. 초기 BSD 개발자인 Marshall Kirk McKusick은 소스 코드 관리 시스템(SCCS)의 로그를 근거로, 빌 조이가 1982년 3월 18일[4.2BSD] 에 4.2BSD의 테스트 빌드를 만들기 위해 chroot를 커널에 추가했다고 설명한 바 있다. 그러나 이후 Warner Losh는 chroot가 실제로는 1979년 벨 연구소의 7th Edition Unix에서 이미 도입되어 있었으며, BSD 커널 소스가 이후 재정리되는 과정에서 이 사실이 혼동을 낳았을 뿐이라고 정정했다. 다만 Bill Joy가 4.2BSD 빌드 디렉터리 안으로 chroot해서, 그 트리에 포함된 파일만을 이용해 시스템을 빌드해 보려는 목적으로 BSD 쪽 chroot 활용을 개척한 것은 사실로 여겨진다.
이후 chroot에 "감옥(jail)"이라는 표현을 적용한 초기 사례로는, 1991년 AT&T 연구원 Bill Cheswick이 시스템에 침입한 해커의 행동을 감시하기 위한 허니팟(honeypot)을 만들면서 이를 "chroot jail"이라 부른 것이 꼽힌다. 이후 chroot의 보안적 취약성 및 이를 우회하는 기법을 다루는 논의가 1990년대 후반부터 여러 보안 칼럼을 통해 본격적으로 다뤄지기 시작했다.
2000년에는 FreeBSD 4.0이 chroot 개념을 대폭 확장한 jail 기능을 도입했고, 2002년경에는 리눅스에서도 유사한 격리 환경을 구성하는 방법이 소개되는 등, chroot는 이후 등장하는 다양한 운영체제 수준 가상화·격리 기술들의 개념적 출발점 역할을 했다.
3. 동작 방식
chroot는 프로세스가 파일 경로를 해석할 때 기준으로 삼는 루트(`/`)를 지정된 디렉터리로 바꿔치기하는 방식으로 작동한다. 예를 들어 `/opt/fake-root`라는 디렉터리를 대상으로 chroot를 실행하면, 이후 해당 프로세스 입장에서는 `/opt/fake-root`가 곧 자기 세계의 `/`가 되고, 그 바깥에 있는 실제 파일시스템의 나머지 부분은 아예 존재하지 않는 것처럼 보이게 된다. 다만 이는 어디까지나 경로 해석 방식을 바꾸는 것일 뿐이라, chroot 대상 디렉터리 안에는 프로세스가 정상 작동하는 데 필요한 라이브러리·바이너리·설정 파일 등을 미리 갖춰 둬야 한다.4. 활용 사례
- 소프트웨어 테스트 및 빌드 환경 격리: 호스트 시스템의 라이브러리 버전이나 설정에 영향을 받지 않는 독립된 빌드 환경을 구성하는 데 쓰인다. Linux From Scratch가 임시 툴체인을 빌드한 뒤 최종 시스템을 구축할 때 chroot 환경으로 진입하는 것이 대표적인 예다.
- 네트워크 데몬 격리(샌드박싱): FTP 서버, BIND 같은 DNS 리졸버, 웹 서버 등 외부 요청을 처리하는 서비스가 침해당하더라도 시스템 전체가 아니라 제한된 디렉터리 안에만 영향을 주도록 가두는 용도로 흔히 쓰인다.
- 시스템 복구: 부팅이 불가능해진 시스템을 라이브 미디어로 부팅한 뒤, 손상된 시스템의 루트 파티션으로 chroot해서 부트로더를 재설치하거나 설정 파일을 고치는 등의 복구 작업에 활용된다.
- 신뢰할 수 없는 프로그램 실행: 출처가 불분명하거나 신뢰도가 낮은 프로그램을 시스템 전체에 영향을 주지 않는 제한된 영역 안에서 실행해 보는 용도로도 쓰인다.
5. 보안 도구로서의 한계
chroot는 파일시스템 경로만 격리할 뿐, 프로세스·네트워크·자원 사용량에 대한 격리는 전혀 제공하지 않는다. 더 근본적인 문제는, chroot로 만든 "감옥"이 root 권한으로 실행 중인 프로세스에는 사실상 무력하다는 점이다. 루트 권한을 가진 프로세스는 비교적 간단한 기법으로 chroot 감옥을 탈출할 수 있는데, 이런 상황을 가리켜 탈옥(jailbreak)이라 부른다. 대표적인 탈출 기법으로는, 감옥에 갇히기 전에 미리 실제 루트 디렉터리에 대한 파일 디스크립터를 열어 뒀다가, chroot로 더 깊은 디렉터리에 들어간 뒤 그 파일 디스크립터로 되돌아가(`fchdir`) 상위 디렉터리로 반복해서 이동(`chdir("..")`)하며 실제 루트까지 빠져나오는 방식이 알려져 있다.이 때문에 오늘날 chroot는 엄밀한 의미의 보안 경계로는 취급되지 않으며, 오용을 막기 위한 최소한의 장벽 정도로 이해하는 것이 안전하다는 평가가 일반적이다.
6. 현대 컨테이너 기술과의 관계
Docker를 비롯한 현대적인 컨테이너 기술은 chroot의 개념적 후예로 종종 소개되지만, 실제 구현 방식과 제공하는 격리 수준에는 뚜렷한 차이가 있다.- 자원 격리 여부: chroot는 파일시스템 경로만 바꿀 뿐, CPU나 메모리 사용량을 제한하는 기능이 전혀 없다. 반면 Docker는 리눅스 커널의 네임스페이스(프로세스 ID, 네트워크 스택, 사용자 ID 등)와 cgroups를 함께 사용해, 프로세스·네트워크 격리는 물론 컨테이너별 CPU·메모리 사용량 제한까지 지원한다.
- chroot 대신 pivot_root 사용: 흥미롭게도 Docker를 비롯한 최신 컨테이너 런타임들은 실제로는 chroot 자체를 거의 쓰지 않는다. 컨테이너 안에서 디버깅을 할 때 종종 root 권한(또는 `CAP_SYS_CHROOT`)이 요구되는 상황이 있는데, 이 경우 chroot는 적절한 격리 수단이 되지 못하기 때문이다. chroot는 어디까지나 현재 프로세스와 그 자식에게만 적용될 뿐, 전역 네임스페이스 자체의 루트나 마운트 테이블을 바꾸는 것이 아니라서 앞서 설명한 탈옥이 비교적 쉽다. 이 때문에 runc 같은 컨테이너 런타임은 새로운 마운트 네임스페이스를 만든 뒤, 그 네임스페이스 안에서 `pivot_root`를 이용해 마운트의 루트 자체를 아예 바꿔 버리는 방식을 사용한다.
- 개념적 연속성: 그럼에도 컨테이너 기술 전체가 근본적으로는 "특정 파일시스템 루트를 가진 프로세스"라는 chroot의 아이디어를 계승하고 있다는 평가가 자주 나온다. "컨테이너는 마케팅 예산이 붙은 chroot일 뿐"이라는 냉소적인 표현이 개발자 커뮤니티에서 종종 회자되기도 하는데, 이는 컨테이너가 제공하는 격리 역시 네임스페이스·cgroups 같은 커널 메커니즘에 기반한 하나의 "추상화 장벽"일 뿐, 완전한 보안 경계는 아니라는 냉정한 시각을 담고 있다.
7. 여담
- "chroot는 프로세스에게 파일시스템의 꼭대기가 어디인지에 대해 거짓말을 하는 것"이라는 식으로 chroot의 원리를 비유적으로 설명하는 경우가 많다.
- Bill Joy 본인은 훗날 chroot가 애초에 엄밀한 보안 경계로 설계된 도구가 아니라, 그저 실용적인 목적을 위해 빠르게 만든 도구였을 뿐이라고 회고한 것으로 알려져 있다.
- chroot에서 FreeBSD Jails, Solaris Zones, systemd-nspawn을 거쳐 리눅스 컨테이너(LXC)와 Docker, 나아가 Kubernetes에 이르는 흐름은 흔히 "운영체제 수준 가상화 기술의 계보"로 소개된다.