Linux-mcp-daemon предлагает выдавать ИИ-агенту доступ к Linux через MCP

Проект решает проблему доверия shell-доступа ИИ-агенту. По словам автора, существующие MCP-серверы для Linux делятся на три типа: удалённый shell с белым списком по первому слову команды, read-only диагностика (например, linux-mcp-server от Red Hat) и прямой SSH-ключ. Ни один из них не даёт сетевого доступа с аутентификацией, разделением пользователей и выдачей root по одному инструменту.

Архитектура mcpd:
— Демон написан на Go как один статический бинарник. Данные читаются из /proc, /sys и через D-Bus systemd; внешние утилиты (smartctl, traceroute, journalctl, dmesg, last, find) вызываются без shell.
— На сегодня у сервера 38 инструментов вида группа/команда (processes/top, services/manage, files/read, logs/journal-control и др.) и 11 постоянных ресурсов с URI плюс 6 шаблонов.
— Главный процесс принимает запрос, проверяет токен и права, но сам инструмент не выполняет. Для каждого вызова запускается короткоживущий worker-процесс от имени Linux-пользователя с тем же именем, что у пользователя mcpd. Пользователь alice в mcpd — это системный аккаунт alice: запреты ядра действуют и на агента.
— Root выдаётся точечно через файл mcp-sudo.yaml. Для каждого пользователя указан список инструментов, которые он может вызвать с privileged: true, и границы: например, files/read разрешён только внутри /var/log, а network/curl ограничен настройкой deny_private: true. Без paths для файловых инструментов конфиг не загружается.
— Транспорт — HTTPS с самоподписанным серверным сертификатом и аутентификацией клиентов по отпечатку. Открытый HTTP в конфиге выключен.
— Каждый вызов пишется в лог демона: пользователь, инструмент, аргументы (секреты вырезаются), результат. Действия, меняющие систему, помечаются как audit.

Клиент linuxctl работает в стиле kubectl: команды get, describe, create, update, delete поверх групп инструментов. Список команд не хранится локально — клиент каждый раз читает схему у демона, поэтому новый инструмент на сервере сразу доступен. Для Claude Code достаточно добавить MCP-сервер одной командой, агент сам выбирает нужные инструменты по их описаниям.

В тестовом инциденте — растущий без ротации лог-файл my-service — агент за пару минут сделал 20 вызовов, нашёл причину, посчитал скорость роста и предложил не удалять файл (сервис держит его открытым), а очистить. Попытка запросить root без разрешения была отклонена mcpd, и агент не стал настаивать.

Автор отдельно разбирает разрешения, которые выглядят узкими, но дают фактический root: запись в /etc, управление любыми systemd-юнитами через services/manage, запись параметров ядра без списка write_keys, чтение всего диска через files/read с paths: ["/"], членство OS-аккаунта агента в группе docker. Для network/curl без блока network закрытый адрес 169.254.169.254 (сервис метаданных облака) закрывается флагом deny_private: true.

Среди найденных и исправленных ошибок: пользователь mcpd с именем root обходил все ограничения mcp-sudo.yaml (теперь конфиг с таким именем не загружается); симлинки внутри разрешённых путей (теперь при ограниченных путях используется O_NOFOLLOW, при paths: ["/"] симлинки открываются как обычно); путаница между Docker-флагом --privileged и аргументом privileged вызова — контейнер без --pid host видел свой PID 1 и тихо получал root внутри контейнера (в v0.3.4 такие вызовы падают с понятной ошибкой); нестабильный тест в релизе, ловивший чужой DNS-запрос.

В ближайших планах — read-only инструменты для Docker, сводка «здоровья» системы одним вызовом и аудит безопасности (SUID-файлы, открытые на запись каталоги, sshd).

Проект открыт под Apache 2.0: код — github.com/nucleusv/linux-mcp-daemon, документация — nucleusv.github.io/linux-mcp-daemon/.