Omarchy: 모든 사용자 프로세스가 root 권한으로 상승 가능

• Omarchy 사용자는 즉시 4.0.1로 업데이트해야 함

  • 기본 Docker 설정 때문에 데스크톱 세션에서 실행되는 사실상 모든 프로그램이 비밀번호, sudo, 권한 승인 없이 root 권한을 얻을 수 있었음

  • 책임 있는 공개 절차를 통해 비공개로 신고했고, 설정이 수정된 뒤 세부 내용을 공개함

  • 영향 범위는 4.0.1 이전 버전이며, 최신 3.x ISO인 3.8.4에서도 취약점을 확인함

취약한 기본 설정과 공격 방식

• Omarchy는 기본 사용자를 Linux docker 그룹에 추가했음

  • 그 결과 사용자는 sudo 없이 다음과 같은 Docker 명령을 실행할 수 있었음

docker run...

• Arch의 Docker 데몬은 root로 실행되며 다음 소켓에서 요청을 받음

/var/run/docker.sock

• docker 그룹 구성원은 root 소유 Docker 데몬을 통해 호스트 전체를 제어할 수 있음

  • Docker의 비-root 사용자 관리 문서도 docker 그룹이 사용자에게 root 수준 권한을 부여한다고 명시함

  • 소켓에 접근하는 프로세스는 데몬에 다음 작업을 요청할 수 있음

    • root 사용자로 컨테이너 실행

    • 호스트 파일시스템의 임의 영역 마운트

    • 마운트한 파일을 root 권한으로 조작

    • 호스트에서 root 권한으로 코드 실행

  • 따라서 영향받는 시스템에서는 기본 사용자뿐 아니라 해당 사용자 세션에서 시작된 모든 프로세스가 root 권한에 접근 가능

재현 방법

• 취약한 Omarchy 신규 설치에서 일반 사용자로 /etc/shadow 읽기를 시도하면 차단됨

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

• 사용자의 그룹 목록에서 docker 그룹 소속을 확인할 수 있음

$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

• 같은 보호 파일을 Docker가 root로 읽게 하면 일반 사용자 프로세스에서도 접근 가능

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
...

• 명령을 시작한 주체는 일반 사용자 프로세스지만 실제 파일 접근은 root로 실행되는 데몬이 수행함

세션 전체에 미치는 영향

• Linux 보조 그룹은 자식 프로세스에 상속되므로 취약점이 사용자 세션 전체로 확산됨

  • 사용자의 systemd --user 아래 프로세스 트리를 조사했을 때 사실상 모든 일반 프로세스에 Docker 그룹 권한이 존재했음

  • 신뢰할 수 없는 코드를 실행할 수 있는 거의 모든 프로세스가 root 권한을 얻을 수 있었음

    • AI 코딩 에이전트와 에이전트 하네스

    • 웹 브라우저

    • 편집기와 IDE

    • npm 스크립트

    • 각종 개발 도구와 백그라운드 프로세스

  • 일반 사용자 애플리케이션 하나만 침해돼도 즉시 시스템 전체 장악으로 이어질 수 있음

기본값과 문서의 문제

• Docker를 실제로 사용하지 않는 사용자에게도 보안상 절충이 기본 적용됐음

  • 사용자가 명시적으로 선택하는 opt-in이 아니라 직접 해제해야 하는 opt-out 방식이었고, 기본 계정에 적용된 위험도 설명되지 않았음

  • 운영체제가 기본적으로 안전하며 보안을 낮추는 설정에는 동의나 안내가 있을 것이라는 합리적인 기대와 맞지 않음

• Omarchy Docker 문서의 설명은 rootless Docker로 오해할 여지가 있었음

Omarchy는 Docker를 원활하게 실행하는 데 필요한 모든 것을 설치합니다. 여기에는 […] root가 아닌 일반 사용자로 Docker를 실행하는 데 필요한 사용자 그룹 변경도 포함됩니다

• 실제 구성은 rootless 모드가 아니었음

  • “root가 아닌 일반 사용자로 실행”한다는 표현과 달리, 일반 사용자 프로세스가 root 데몬을 제어해 root 수준 권한을 행사하는 구조였음

도입과 수정 경과

• Docker 그룹 기본 설정은 2025년 6월 도입된 뒤 잠시 비활성화됐다가 다시 활성화됐고, 2026년 8월 제거됨

  • 2025년 6월 1일 — Docker 그룹 소속 도입 25799ee

  • 2025년 6월 2일 — Docker 그룹 추가 일시 비활성화 c5ee230

  • 2025년 6월 17일 — Docker 그룹 소속 재활성화 fdd2aaf

  • 2026년 8월 24일 — 기본 설정에서 Docker 그룹 소속 제거 b5ded31

개발자 환경의 보안 위험

• 개발자용 배포판은 개발자 시스템이 고가치 공격 대상이라는 점을 기본 설정에 반영해야 함

  • AI가 핵심 인프라에서 심각도 높은 CVE를 점점 더 많이 찾아내는 가운데, 개발자 시스템 침해와 그 접근 권한을 이용한 소프트웨어 공급망 오염·프로덕션 시스템 공격 사례가 계속 보고되고 있음

  • 개발자 시스템은 편의를 위해 보안 장치를 끄고, 평문 dotfile에 자격 증명을 저장하며, 여러 시스템의 접근 권한을 축적하는 경우가 많아 이런 관행을 바꿔야 함

• 이번 문제는 Docker 그룹 추가의 영향을 놓친 실수로 보이며 신고 뒤 대응 속도는 매우 빨랐음

  • 어떤 배포판도 모든 보안 결정을 완벽하게 내릴 수는 없지만, Omarchy에서 보안 문제를 겪은 것이 이번이 처음은 아님

  • 현재 의사결정 과정이 배포판에 기대하는 보안 수준을 보장한다고 신뢰하기는 어려우며, 장점이 많은 프로젝트인 만큼 개선되기를 바람

root 권한이 필요 없는 대안

• Linux에서 컨테이너 실행을 위해 root 권한을 부여하고 싶지 않다면 Podman을 권함

  • Podman은 데몬 없이 컨테이너를 자체 사용자 네임스페이스의 일반 자식 프로세스로 실행하므로 어떤 형태의 root 접근도 요구하지 않음

  • 수개월 동안 사용한 결과 기존 Docker 워크플로를 모두 대체할 수 있었음

^{source https://0xcc.io/posts/omarchy-root-creds/}

HN에서는 이번 사안을 단순한 Docker 설정 실수보다, 편의를 위해 위험한 권한을 기본값으로 제공해도 되는가의 문제로 봤다. 일반 사용자를 docker 그룹에 넣으면 루트로 실행되는 데몬을 통해 호스트 파일을 마음대로 다룰 수 있다. 널리 알려진 위험을 사용자의 명시적 선택 없이 모든 설치 환경에 적용했다는 점이 비판의 핵심이었다.

루트 권한 상승이 실제 피해를 얼마나 키우는지를 두고는 판단이 엇갈렸다. 개인용 리눅스에서는 악성 코드가 사용자 권한만 확보해도 홈 디렉터리의 문서와 인증 정보를 훔치고 셸 설정을 바꿀 수 있으니 이미 치명적이라는 주장도 있었다. sudo 암호를 가로챌 수도 있어 전통적인 사용자와 루트의 경계가 데스크톱 보안에서 충분하지 않다는 설명이다. 그렇다고 시스템 파일까지 직접 변조할 수 있는 권한 확대를 사소하게 볼 수는 없다는 지적도 분명했다.

대안으로는 rootless Docker와 Podman이 반복해서 언급됐다. 특히 Docker를 쓰지 않는 사용자에게도 관련 권한을 처음부터 부여한 설계는 설득력을 얻지 못했다. 브라우저와 편집기, npm 스크립트, AI 코딩 에이전트처럼 사용자 세션에서 다양한 코드가 실행되는 환경에서는 작은 침해가 곧 시스템 전체 장악으로 번질 수 있기 때문이다. 비공개 제보 뒤 신속히 수정한 절차는 적절했지만, 초기 기본값의 책임까지 없애지는 않는다.

배포판을 고를 때는 설치와 설정의 편리함뿐 아니라 기본 프로그램과 권한 범위를 함께 살펴야 한다. 권한 확대를 사용자가 직접 선택하는지, 더 안전한 실행 방식을 기본으로 삼는지, 위험을 충분히 알리는지가 핵심이다. 개별 취약점의 수정 속도와 함께 이런 선택을 출시 전에 검토할 체계가 있는지도 신뢰를 가르는 기준이 된다.