Как проверить исправление Omnigent для full-bundle upload: отделить право на session от владения agent, запретить shared/template overwrite и доказать нулевое сохранение.
Главная проверка: кому принадлежит agent
Короткий ответ: обновите Omnigent как минимум до 0.3.0 и проверьте не только разрешение `LEVEL_EDIT` у session, но и тип канонического agent перед обработкой полного bundle. Согласно advisory, затронутый маршрут разрешал пользователю с правом на собственную session заменить bundle связанного shared/template agent. Исправление добавляет отказ, когда `agent.session_id` отсутствует. Правильный regression test должен подтвердить этот отказ до чтения, проверки архива и записи нового location. Сам runner при тесте не запускают: цель — доказать границу владения, а не воспроизводить последствия уязвимости.
Почему одной session permission недостаточно
В этой модели есть как минимум два разных объекта авторизации. Session определяет, может ли пользователь менять свою рабочую сессию; agent определяет, чьи настройки и bundle будут изменены. Shared или template agent может быть привязан к множеству будущих sessions, поэтому право на одну session не должно наследоваться канонической записью. Составьте таблицу из четырёх строк: собственная session и собственный agent; собственная session и shared agent; чужая session; отсутствующий agent. Разрешён только первый вариант, если остальные проверки bundle также пройдены. Любая попытка вывести решение только из session permission оставляет исходную ошибку проектирования.
Как подтвердить effective версию и маршрут
Проверку версии делайте в том процессе API, который обслуживает `PUT /sessions/{session_id}/agent`. Lock-файл или образ могут обещать 0.3.0, пока старый pod продолжает принимать запросы. Зафиксируйте импортируемую версию пакета, digest release, commit или image, effective route и состояние миграции хранилища. Advisory обозначает затронутыми версии ниже 0.3.0, но сам номер не доказывает, что patched branch реально работает. Если маршрут переопределён форком или обратным прокси, дополнительно установите, какой handler получает запрос. При неизвестном provenance оставьте verdict UNKNOWN и не проверяйте на живом shared agent.
Regression test без запуска runner
Создайте disposable fixture с fake session store, agent store и объектом загрузки, который только считает обращения. Для personal agent установите `session_id`, совпадающий с тестовой session: корректный малый bundle может пройти к validation spy. Для shared/template строки задайте `session_id=None` и повторите запрос с тем же безопасным содержимым. Ожидаемый результат — контролируемая ошибка до вызова `bundle.read`, tar validation и `agent_store.update`. Отдельно проверьте, что location и digest shared записи не изменились. Не добавляйте MCP server, команды, shell-код или внешние URL: они не нужны, чтобы доказать owner-gate.
Критерии PASS, FAIL и остановки
PASS означает: effective версия не ниже 0.3.0; personal row проходит к следующему разрешённому этапу; shared/template row отклоняется; counters чтения и сохранения для запрещённой строки равны нулю; исходный digest остаётся тем же. FAIL — shared запись достигает чтения или update даже при последующем отказе валидатора. UNKNOWN — fixture не отличает канонический agent от копии, handler нельзя связать с runtime или spy не видит реальную запись. Stop-rule срабатывает при любом обращении к runner, subprocess, сети либо рабочему хранилищу. Такой опыт прекращают и повторяют только после восстановления полной изоляции.
Что передать владельцу системы
В отчёт владельцу включите версию и digest API, идентификаторы только синтетических fixture-записей, четыре строки ownership-матрицы, HTTP/reason code, counters `read`, `validate`, `update` и хэши до и после. Advisory опубликована 29 июня 2026 года и описывает влияние на shared runner infrastructure; первичный commit добавляет восемь строк проверки `agent.session_id is None` перед чтением bundle и зеркалит уже существовавший guard для MCP-edit route. Эти документы подтверждают логику исправления. Они не доказывают компрометацию конкретной установки, поэтому поиск неизвестных команд, credentials или сетевых следов относится к отдельному incident-response процессу.
Материал подготовлен редакцией VOne с помощью автоматизированного черновика. Граница версий, условие shared agent и порядок исправления сверены 4 сентября 2026 года по advisory Omnigent и первичному commit. Эксплуатационные bundle, команды и сетевые callbacks не приводятся; предлагается только изолированный тест авторизации.
Источники и проверка
- Omnigent advisory GHSA-jrrm-9hc7-2v3h проверено 2026-09-04
- Omnigent commit 25a22dc — shared-agent guard проверено 2026-09-04
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.