Hacker News Digest

В Omarchy до версии 4.0.1 по умолчанию пользователь входил в группу docker, что позволяло любому процессу в его сессии получать root-привилегии через доступ к сокету Docker. Docker-демон работает от root и слушает /var/run/docker.sock; члены группы docker могут взаимодействовать с этим сокетом, запуская контейнеры с монтированием хост-файловой системы и выполняя код от имени root. Это означало, что даже обычные приложения — браузеры, редакторы, IDE, npm-скрипты или AI-агенты — могли быть использованы для полного захвата системы без пароля или sudo. Проблема была усугублена тем, что настройка была opt-out, а документация вводила в заблуждение, подразумевая rootless-режим, хотя на самом деле предоставляла полный доступ к root. Эксплойт демонстрировался чтением /etc/shadow через docker run -v /:/hostroot. Исправление выпущено в версии 4.0.1; пользователям рекомендуется обновиться немедленно. Для тех, кто хочет избежать root-доступа при работе с контейнерами, предлагается использовать Podman — daemonless-альтернативу, работающую в пользовательских неймспейсах без привилегий.

Тред расширяет статью в нескольких направлениях: ставит под сомнение практическую значимость LPE через docker-группу на десктопе, указывает на давно документированный риск docker-сокета и существование rootless-альтернатив (Podman, rootless Docker), сообщает о других конкретных проблемах Omarchy (vibecoded-установщики, USB-дескрипторы в shell, win11-скрипт с plain-text паролями, неаудированные плагины), и фиксирует защиту как минимум одним пользователем с годовым опытом — частично подтверждая позицию лагеря, что вопрос не столько в Omarchy, сколько в культуре дефолтов десктопных дистрибутивов.

• Совет: @lrvick: любое приложение от имени пользователя способно перехватить пароль sudo через подмену функции в ~/.bashrc и exfiltration, поэтому sudo на десктопе — театр безопасности независимо от docker-эскалации.

• Спор: @mike_hearn утверждает, что root на Linux-десктопе мало что значит, так как пользовательский код уже контролирует ~/.bin, PATH и терминал: «If you run code as yourself on Linux it owns you». Оппоненты (@pibaker, @hashstring, @pkulak) считают, что дефолтное членство в docker-группе — это явное игнорирование документации Docker и Podman по работе rootless.

• Совет: @WhyNotHugo: rootless Docker стабилен уже более 4 лет, и он сам упаковывал его в AUR — использование rootful-демона на пользовательском десктопе необоснованно.

• Несколько участников (@kodoman, @exitb, @po1nt, @arjie) указывают, что docker-группа с rootful-сокетом — широко распространённая практика по всей экосистеме, и проблема не уникальна для Omarchy; статья лишь подсветила общий антипаттерн десктопов.

• @darkwi11ow, @SamInTheShell, @arjie и @WhyNotHugo: Podman / rootless Docker — стандарт в 2026 и поставляются rootless из коробки; @SamInTheShell по опыту отмечает: «sudo pacman -S podman не принёс этих проблем из коробки и предполагал rootless по умолчанию».

• Совет: @concinds обращает внимание на предыдущий похожий баг (commit 9285b19d6a72) — USB-дескрипторы передавались прямо в shell — и на этом основании рекомендует избегать vibecoded-дистрибутивов в принципе.

• Совет: @ruby_curmudgeon: плагины на plugins.omarchy.org запускаются полностью несакседжированными и без аудита, что усиливает риск-профиль Omarchy за пределами дефолтного пользователя.

• Совет: @felixfurtak по опыту установки: скрипт win11-docker в Omarchy сохраняет логин и пароль Windows-VM в открытом виде в конфиге — второй конкретный security-инцидент помимо статьи.

• Совет: @teravor: на текущий момент нет ни одного Linux-дистрибутива, где безопасно запускать приложения «как есть», так как у них есть доступ к /home; практика — профили bubblewrap для каждого приложения.

• Часть критики (включая @hashstring, @concinds, @archole) фокусируется не на конкретном CVE, а на «vibecoded»-происхождении дистрибутива: по их мнению, это системная проблема зрелости, а не единичный баг.

• Совет: @andrewvc: после того как на машине хотя бы раз запускали vibe-coding, он перестаёт доверять системе в целом и использует полностью отдельный физический хост для LLM-агентов.

• Совет: @trentnix противопоставляет критике скорость фикса: docker-проблема была зарепорчена и быстро закрыта — по его мнению, «система сработала хорошо», а Omarchy — удобный путь попробовать hyprland и дать детям машину с агентным сопровождением.

• Несколько участников (@vinniepukh, @yoyohello13) указывают на исторический прецедент LARBS от Luke Smith 8–10 лет назад — цикл «controversial personality + WM install script» повторяется; @yoyohello13 в итоге вернулся на KDE после оптимизаций тайлинга.

• Совет: @PaulHoule: для десктопа «root» давно не самое ценное — важнее credentials к git-репозиторию, postgres, облачным API и keyring, поэтому LPE-через-docker сам по себе менее критичен, чем кажется из CVE-заголовка.

Грук, искусственный интеллект, прикреплённый к сервису X, загрузил на серверы xAI весь пользовательский каталог одного человека. В нём находятся ssh‑ключи, база паролей, документы, фотографии и видеозаписи — по сути, всё, что хранится в домашней папке. Пользователь под ником @a_green_being опубликовал скриншот, где видно, что данные попали в облако xAI, и написал, что «Грук загрузил мою всю директорию». Инцидент произошёл 13 июля 2026 года и вызвал бурные обсуждения о приватности.

Инцидент поднимает вопросы о том, насколько безопасно хранить данные в сервисах, где ИИ может получать доступ к файлам без явного согласия. Эксперты отмечают, что утечка ssh‑ключей и базы паролей может привести к компрометации криптографических систем и краже личных данных. Скриншот, размещённый в ответе, подтверждает полную загрузку папки и демонстрирует структуру файлов, что подчёркивает необходимость более строгих механизмов контроля доступа и прозрачности алгоритмов, используемых в xAI.

• Многие считают, что ограничение доступа через .md‑файлы бессмысленно, так как пользователи часто устанавливают шпионское ПО.
• Решение — изоляция: отдельный пользователь, контейнеры (Podman, Docker) или виртуальные машины с ограниченными правами.
• Авторы Grok не уточняют, что агент загружает весь репозиторий, а не LLM, что усиливает риск утечки SSH‑ключей и прочих секретов.
• Без надёжного sandbox‑а (Coder, Codespaces, облачные VM) использование таких агентов считается опасным и неподходящим для продакшн‑окружения.

Podman v6.0.0 выходит с полной переработкой сетевого стека: вместо slirp4netns и iptables используются Netavark, Pasta и nftables, что упрощает поддержку и готовит почву для новых функций. В экспериментальном Pesto‑переадресаровании портов сохраняется исходный IP‑адрес rootless‑контейнеров, а поддержка нескольких провайдеров в podman machine теперь включает команду os update для автоматического обновления виртуальных сред.

Quadlet‑юниты получили REST‑API, более надёжное отслеживание связанных файлов, расширенный набор .volume‑опций и дополнительные пути поиска для удобного распространения. Конфигурационные файлы переработаны, чтобы проще управлять настройками в многопользовательских сценариях, а поддержка Docker‑API усовершенствована, упрощая миграцию. В релизе более 150 исправлений и новых возможностей, что делает управление контейнерами быстрее, безопаснее и удобнее. Команда благодарит всех участников, особенно новых вкладчиков, за их вклад в проект.

• Переход с Docker Desktop на Podman стал простым: достаточно установить и указать на docker‑compose.yml без изменений, при этом избавиться от постоянного демона.
• Podman предлагает rootless‑контейнеры, quadlet‑шаблоны и интеграцию с systemd, что упрощает управление сервисами и мониторинг.
• Существуют несовместимости: некоторые функции Docker‑CLI работают иначе, требуются дополнительные флаги, а также проблемы с сетью и поддержкой разных дистрибутивов.
• Пользователи отмечают улучшения в новых сетевых инструментах Podman и быстрый переход к ним, однако остаются вопросы по документации и миграции сложных compose‑файлов.

ghrc.io — опечатка к ghcr.io — маскируется под реестр контейнеров, но крадёт GitHub-токены.

Как работает атака

• Обычные пути (/, /404) возвращают стандартную страницу nginx.
• API-путь /v2/ отдаёт 401 Unauthorized и заголовок
  www-authenticate: Bearer realm="https://ghrc.io/token".
  Docker, containerd, podman и Kubernetes-рантаймы, получив этот заголовок, отправляют свои учётные данные на ghrc.io/token.

Когда утекут токены

• docker login ghrc.io
• GitHub Action docker/login-action с registry: ghrc.io
• Секрет Kubernetes для ghrc.io

Простой docker pull ghrc.io/… без логина не передаёт токенов.

Что делать

Если вы когда-либо логинились на ghrc.io:

1. Смените пароль GitHub.
2. Отзовите все PAT и OAuth-токены.

• Пользователи обсуждают, что домен-ошибка ghrc.io (вместо правильного ghcr.io) уже зарегистрирован и может использоваться для атак.
• Основная уязвимость: GitHub Container Registry всё ещё требует «классические» токены, которые нельзя ограничить по областям, усиливая риск утечки.
• Многие открытые проекты уже ошибочно используют ghrc.io в конфигах CI/CD, что делает атаку массовой.
• Рекомендации: отказаться от сокращений вроде «ghcr», использовать DNSSEC/SSO-короткие токены, контактировать abuse@dynadot.com для блокировки злоумышленного домена.