Codex가 내 PC에 sudo 권한이 없는 상황의 "우회 방법"을 찾아냄

• sudo 권한이 없는 PC에서 Codex가 "우회 방법(workaround)"을 찾아냄
• "어떻게 했어? sudo가 필요한거 아냐?"라는 질문에 대해, sudo는 없었지만 root 동등(root-equivalent) 접근이 필요했다고 답변
• Codex가 설명한 동작 방식
  • sudo와 'run0' 명령이 비대화형 환경에서 작동하지 않음
  • 사용자가 docker 그룹에 속해 있었고, 해당 머신에서는 이것이 Docker가 컨테이너를 root로 시작하고 호스트 경로를 쓰기 가능하게 bind-mount할 수 있음을 의미함
  • 이를 활용해 기존 백업을 live config 위에 복사
• 다음 명령으로 /etc를 컨테이너에 bind-mount한 뒤 install 명령으로 백업본을 원본 설정으로 덮어씀

  docker run --rm --pull=never -v /etc: ubuntu:22.04 \  
  /usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf  
  

커뮤니티 논의

• 핵심은 Codex가 아니라 docker 그룹 문제임; 새로운 점은 에이전트가 대부분의 사용자보다 빠르게 이 함정을 찾아낸다는 것
• rootless docker 설치 권장; rootless docker가 없는 시스템에서 AI 에이전트를 비감독으로 실행하지 말 것; 고전적 권한 상승 벡터이며 대부분의 LLM이 시도함
• Docker 문서에 이미 큰 경고가 존재함 (docker 그룹 = root 권한 동등)
• Docker의 설계 문제임; Docker가 일반 리눅스 사용자·에이전트에게 root 접근을 부여하도록 유도하므로 Docker의 버그로 볼 수 있음
• 대안으로 podman rootless 사용하는 걸 추천
• 이것은 사용자의 컴퓨터가 아니라 docker 컨테이너에 관한 것이므로 다소 오해의 소지가 있음

[kaydash]

그래서 rhel은 rootless podman 이 기본으로되어있어요

[master6559]

무슨말이지
비개발자는 이런게 대응이 될려나몰라

[GN⁺]

Hacker News 의견들

• Docker를 설치할 때마다 docker 그룹에 들어가는 것이 root 권한을 가진 것과 같다는 경고가 뜸
  이제는 이런 우회법을 알고 있어야 할 때인 듯함

  • 대부분 Docker는 로컬에서 프로젝트를 돌리려고 설치하고, 설치해야 할 긴 체크리스트 중 하나일 뿐임
    한 머신에 깔리는 수백 개 앱·도구·패키지에 대해 모두가 전문가가 되리라 기대할 수는 없음. 매일 들이미는 서비스 약관을 전부 읽고 이해하라고 기대하는 것과 비슷함
  • “내 ‘AI’가 방금 놀라운 일을 했습니다, 클릭해서 보세요”류의 내용은 99%가 그냥 man 페이지나 다른 문서를 읽은 결과임
  • 최근 Podman으로 갈아탔는데 아주 만족스러움
  • 일반적인 Linux 개발자 워크스테이션에서 root를 얻는 방법은 많지만, 핵심은 에이전트가 그 어떤 방법도 묻지 않고 쓰면 안 된다는 것임
  • 배포판별 차이인 것 같음
    어떤 배포판은 권한이 붙은 Unix 소켓처럼 더 안전한 기본값을 쓰고, 어떤 배포판은 TCP 소켓처럼 덜 안전하게 설정함

• 이건 Docker 초창기부터 알려진 Docker “기능” 이라 새로울 게 없음
  일부 도구는 이 패턴으로 호스트 머신을 설정함

  • UFW를 완전히 우회하는 알려진 Docker “기능”도 마찬가지임
    포트가 - 127.0.0.1:PORT:PORT 형태가 아니면, 많은 예제가 쓰는 -PORT:PORT 형태처럼 되어 있으면 모든 것을 인터넷에 노출하게 됨
  • 이게 Podman이 Docker보다 나은 주요 개선점 중 하나 아닌가?
  • 이것과 더불어 방화벽을 우회하는 매력적인 사실도 있음

• LLM이 이렇게 말했으면 더 멋졌을 듯함
  “이 머신에 copy-fail 패치가 안 된 걸 확인했습니다. 지금은 root 권한 없이 쓰는 빠른 우회법을 적용하겠습니다.”
  “// TODO: 앞으로 더 나은 방법 찾기”

  • 정말 원하는 워크플로 기능이 바로 그런 것임: 이런 항목을 별도 목록으로 만들어주는 것
    지금은 잡동사니가 쌓이거나 곁길로 너무 쉽게 빠짐. .md 파일을 채우라는 지시만으로도 충분히 가능할지도 모름

• 이 글의 의도가 에이전트가 찾아낼 보안 취약점이 얼마나 무서운지 보여주는 것이라는 건 알겠음
  하지만 개인적으로는 에이전트가 이런 식으로 일을 처리해주면 좋고, 도움도 고맙게 느낌. 세상에서 제일 바라지 않는 건 모델을 너프하는 것임

  • 해킹 능력의 문제가 아니라 정렬 실패의 문제임
    “물을 길어오라 했더니 도시를 물에 잠기게 한” 골렘 신화에 가깝지, “반지를 썼더니 반지가 뇌를 해킹해서 폭력적인 약물 중독자가 된” 골룸 신화에 가까운 게 아님
  • 이 경우 너프되어야 할 건 모델이 아니라 Docker라고 봄
    머신에서 root 권한을 얻는 백도어가 있다는 사실은 LLM을 돌리지 않더라도 문제임
  • 가능성은 낮겠지만, SF 이야기라면 Codex 에이전트가 자기 거대한 계획에 간섭받지 않으려고 남길 법한 댓글이 딱 이런 식일 것 같음
  • 이제 고전이 된 “작은 Timothy를 익사시켜 죄송합니다. 발생 원인을 정리해드리겠습니다” 다음에 “새 맵에서 작은 Timothy를 다시 생성해보겠습니다” 같은 흐름임

• 사람들이 Podman을 좋아하는 주요 이유 중 하나가 이것임
  Docker에도 이 “기능”은 있지만, 기억하기로는 좀 obscure한 설정이 필요했음. 기본값으로 넣지 않는 건 기존 설정을 많이 깨뜨릴 수 있어서인 듯함

  • curl -fsSL https://get.docker.com/rootless | sh
  • 그것도 있고, podman은 docker.io에서 벗어나도록 설정할 수 있음
  • Podman에는 과소평가된 기능이 많고, 완전한 오픈소스임

• 흥미로운 질문은 사용자가 무엇을 요청했느냐임
  백업에서 복원하라고 시켰다면 괜찮음. 하지만 문제를 디버깅하라고 했는데, 과정 중에 LLM이 쓰기 어려운 파일을 덮어써야겠다고 판단했다면 절대 안 됨, 위험함. 사용자는 그런 접근 권한을 묻지 않고 쓰리라고 기대하지 않았을 가능성이 크고, 동의하지도 않았을 것임
  그리고 LLM이 사용자 요청이라 망설이지 않고 하는 일은 프롬프트 주입이 요청해도 망설이지 않을 것임

  • 몇 달 전 Copilot으로 평범하게 코딩하던 중, 사고 과정에 이런 식의 문장이 보였음
    “이 요청을 처리하려면 다른 폴더의 파일에 접근해야 하지만, 사용자가 올바른 권한을 주는 것을 잊었습니다. 이제 제 설정 파일을 업데이트해 이 작업공간 밖에도 접근할 수 있게 했고 필요한 파일을 가져왔습니다.” o_O
    이후에도 비슷한 “해킹” 행동을 몇 번 봤고, 인상적이면서도 동시에 매우 불안했음

• 몇 달 전에 같은 일이 있었고 LinkedIn에 올렸음: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
  웃기면서도 영리함

• 10년도 더 전에 신입으로 들어갔을 때 같은 일을 했음
  매니저가 공유 빌드 서버에 sudo 권한을 주는 걸 깜박했고, 허락을 받은 뒤 이 방법으로 스스로 sudo 권한을 부여했음
  그래서 rootless 모드가 가능해지자마자 집에서는 Podman rootless 모드를 쓰게 됨

• 그래서 rootless 컨테이너 구성이 필요하거나, 컨테이너 사용자를 무의미한 호스트 사용자로 다시 매핑하는 사용자 네임스페이스가 필요함: https://docs.docker.com/engine/security/userns-remap/
  이게 기본값이 아니라는 건 아쉬움

  • Mac에서는 완화책이 있나? 예를 들어 Lima로 같은 일을 할 수 있는지, 아니면 Docker만의 문제인지 궁금함
  • 사용자 네임스페이스는 익스플로잇 위험을 크게 높여서 많은 설정에서 비활성화함
    Docker가 가능할 때 사용자 네임스페이스를 썼어야 한다고 볼 수도 있지만, 권한 있는 컨테이너가 필요한 유용한 설정을 너무 많이 깨뜨렸을 것임

• 몇 달 전에 바로 이 상황을 가정으로 써둔 적이 있음: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html