Создание полностью изолированных sandbox‑окружений в Termux с помощью Firejail и namespaces: ограничение доступа к файловой системе, сети и устройствам

Termux — мощная среда для работы на Android, но по умолчанию процессы используют те же системные ограничения и доступ к данным, что и остальная часть приложения. Если вам нужно выполнить потенциально «не доверенную» программу, проверить скрипт или воспроизвести поведение ПО в контролируемых условиях, разумно использовать sandbox‑подход: изолировать процессы так, чтобы минимизировать доступ к файловой системе, сети и устройствам.

В этой статье мы рассмотрим практику построения полностью изолированных sandbox‑окружений в Termux с применением Firejail и Linux namespaces. Акцент будет на безопасных ограничениях: где возможно — блокировать доступ к ФС, сети и устройствам; где необходимо — предоставлять строго ограниченные точки входа.

Важно: все примеры предназначены для легитимных задач анализа и тестирования. Не используйте sandbox для обхода ограничений, атак или несанкционированных действий.

Что дают Firejail и namespaces в контексте Termux

Firejail — утилита для контейнеризации на уровне процессов Linux с политиками изоляции. Она использует механизмы ядра, включая namespaces и различные фильтры доступа.

Ключевые идеи:

• Файловая система: ограничение видимости каталогов, “пустые” монтирования, read-only режимы, запрет опасных путей.
• Сеть: отключение доступа к сокетам, либо разрешение только специфических сетевых сценариев (например, локальная сеть для сервисов тестирования).
• Устройства: запрет доступа к /dev и отдельным устройствам.
• Процессы: ограничение прав, возможностей и “системных” вызовов на уровне ядра через параметры Firejail.

Подготовка окружения в Termux

Ниже приведены типовые шаги установки. Реальные пакеты и возможности зависят от устройства, версии Android и ядра. Смысл: иметь рабочую связку Firejail + возможность создавать namespaces.

Обычно начинаем с обновления репозиториев и установки необходимых пакетов:

pkg update
pkg upgrade -y
pkg install -y firejail proot

Далее проверьте, что Firejail запускается и доступен:

firejail --version

Если ваша сборка Android/ядра ограничивает некоторые namespace‑возможности, часть параметров может не сработать. В таком случае используйте максимально близкий по смыслу набор ограничений (сеть/ФС/устройства) и валидируйте поведение тестируемого приложения.

Базовая концепция политики sandbox

Смысл политики Firejail — описать, что процесс может и что он не может. Для изоляции «максимально из коробки» используйте комбинацию:

• Отключение сети (или разрешение строго нужного).
• Ограничение файлов: запрет доступа к домашней директории, предоставление только временного каталога.
• Запрет доступа к устройствам.
• Запрет небезопасных системных возможностей.

Пример 1. Полностью изолированный запуск команды с закрытой сетью и ограниченной файловой системой

Этот сценарий демонстрирует “минимально доверенный” запуск: процесс не видит ваши личные файлы, не имеет выхода в сеть и работает в ограниченном временном пространстве.

1) Создайте профиль Firejail. Например, в /data/data/com.termux/files/home (в Termux это обычно ваш домашний каталог):

mkdir -p ~/sandbox-profiles
cat > ~/sandbox-profiles/isolated-offline.profile <<'EOF'
# Жёсткая базовая политика sandbox
noblacklist
quiet

# Имена пользователя/группы внутри jail (по возможности)
# Примечание: фактическая поддержка зависит от окружения.
# В Termux обычно будет работать в рамках возможностей user namespace.

# Сеть: полностью отключаем доступ к сокетам
net none

# Устройства: не монтируем /dev
disable-sysfs
private-dev

# Файловая система: делаем приватную
private

# Делаем "дом" только временным пространством
# Firejail private создает приватную ФС-песочницу.
# Ограничим доступ к некоторым опасным путям
blacklist ${HOME}/.ssh
blacklist ${HOME}/.gnupg
blacklist ${HOME}/.cache
blacklist ${HOME}/Documents
blacklist ${HOME}/Downloads
blacklist ${HOME}/shared

# Ограничение прав: минимизируем возможность записи
# Полный режим read-only может приводить к отказам в запуске,
# поэтому лучше проверять под ваш кейс.
# read-only

# Снижаем возможности (если поддерживается)
caps.drop all

# Запрещаем выполнение из приватных путей, кроме того что нужно
# В простом примере полагаемся на private и отсутствие доступов.

# Включаем отдельный /tmp (обычно внутри private)
# (зависит от поддержки, но private обычно это обеспечивает)

# Запрет некоторых системных действий (осторожно с совместимостью)
# seccomp можно включать, если доступно в вашей сборке Firejail.
# seccomp
EOF

2) Запустите тестовую команду, например, вывести информацию и попытаться обратиться к файловой системе:

firejail --profile=~/sandbox-profiles/isolated-offline.profile -- bash -lc 'echo "PWD=$(pwd)"; ls -la; echo "HOME=$HOME"; ls -la "$HOME"' 

3) Проверьте, что сеть действительно недоступна. Например, попробуйте выполнить DNS/соединение (как тест):

firejail --profile=~/sandbox-profiles/isolated-offline.profile -- bash -lc 'getent hosts example.com || echo "DNS unavailable"; curl -I https://example.com || echo "No network"' 

Если getent или curl не установлены, используйте аналоги из вашего окружения. Смысл проверки — убедиться, что соединения не выходят за пределы jails.

Пример 2. Sandbox с разрешением только локальной сети (для тестовых сервисов)

Иногда требуется, чтобы sandbox мог работать с сервисами в рамках вашей локальной сети (например, тест на клиент‑сервер в одной Wi‑Fi сети). В таком случае важно не использовать это для обхода блокировок, а применять исключительно для легитимных стендов.

Вариант: вместо полного запрета сети — ограничить на уровне Firejail доступ так, чтобы процесс мог общаться только “внутри” ожидаемой сетевой подсети. Конкретные параметры сильно зависят от возможностей Firejail в вашей сборке и доступности user namespaces.

Общий шаблон профиля может выглядеть так:

cat > ~/sandbox-profiles/isolated-localnet.profile <<'EOF'
quiet

# Сеть: ограничиваем, не даем произвольный доступ.
# В зависимости от сборки, поддержка тонкой настройки может отличаться.
# Начинайте с отключения и постепенно добавляйте нужное.
netfilter

# Приватные устройства и ФС
private
private-dev

# Профильный набор ограничений
caps.drop all
disable-sysfs

# Пример: оставляем только то, что нужно приложению.
# Настройка правил iptables/nftables обычно требует поддержки kernel и возможностей.
EOF

Затем запуск:

firejail --profile=~/sandbox-profiles/isolated-localnet.profile -- bash -lc 'echo "Testing local net access..."; ip addr || true' 

Для точной настройки “только локальная подсеть” потребуется знать модель сетевого доступа в вашем окружении и какие средства доступны (iptables/nftables). Если хотите — подготовьте вашу цель (например, адреса/порты тестового сервера в LAN) и параметры терминала, а мы подскажем безопасную конфигурацию под ваш кейс.

Пример 3. Жесткое ограничение файловой системы: видимые каталоги только по списку

Некоторые задачи требуют строгого “allowlist”: процесс видит только отдельный каталог входных данных и каталог для результатов. Ниже — подход с явным предоставлением точек доступа.

1) Профиль:

cat > ~/sandbox-profiles/allowlist-fs.profile <<'EOF'
quiet

# Отключаем сеть
net none

# Приватная ФС
private
private-dev

# Обнуляем лишние пути
blacklist ${HOME}
whitelist ${HOME}/sandbox-input
whitelist ${HOME}/sandbox-output

# Разрешаем только каталоги для работы
# Создайте их заранее
# whitelist не всегда гарантирует полный control для всех сценариев,
# поэтому тестируйте на конкретном ПО.
read-only ${HOME}/sandbox-input
mkdir ${HOME}/sandbox-output

# Устройства: запрет доступа
disable-sysfs
caps.drop all
EOF

2) Подготовьте вход/выход:

mkdir -p ~/sandbox-input ~/sandbox-output
echo 'test payload' > ~/sandbox-input/input.txt

3) Протестируйте чтение/запись:

firejail --profile=~/sandbox-profiles/allowlist-fs.profile -- bash -lc 'echo "Can read input:"; cat "$HOME/sandbox-input/input.txt"; echo "Can write output:"; echo "result" > "$HOME/sandbox-output/out.txt"; echo "Try read home:"; ls -la "$HOME" || true; ls -la "$HOME/sandbox-output"' 

Если задача требует абсолютной строгости, дополнительно проверяйте попытки обхода через символические ссылки и пути вроде /proc (в зависимости от поддержки профиля). В таких случаях лучше расширить профиль под конкретное поведение приложения.

Ограничение доступа к устройствам и “опасным” псевдофайлам

Чтобы уменьшить возможность взаимодействия с системой:

• Используйте private-dev для приватизации /dev.
• Ограничивайте доступ к /sys (например, через disable-sysfs или эквиваленты профиля).
• Сбрасывайте capabilities (пример: caps.drop all).

Даже если само ядро Android “не дает” часть возможностей, политики Firejail полезны как дополнительный слой контроля.

Тестирование и валидация: как понять, что sandbox работает

Минимальный чек‑лист:

• ФС: попробуйте перечислить каталоги, прочитать известные файлы вне allowlist, создать файл в “запрещенном” месте.
• Сеть: попробуйте DNS, HTTP запрос, исходящий TCP/UDP. При net none соединения должны падать.
• Устройства: попробуйте открыть характерные устройства (например, серийные устройства или псевдоустройства). При корректной изоляции — ошибки доступа.
• Поведение: убедитесь, что легитимная функциональность (например, обработка входных данных) работает в пределах разрешенных ресурсов.

Для отладки включайте логирование Firejail (аккуратно, не раскрывая чувствительные данные в логах). Начните с кратких тестов и затем расширяйте профили.

Частые проблемы и совместимость

• Ограничения ядра Android: некоторые namespace‑механизмы или фильтры могут быть ограничены. Симптом — параметры профиля игнорируются или вызывают ошибки.
• Отказ приложений из‑за “слишком строгих” ограничений: если программа не находит файлы/каталоги, сначала расширьте allowlist точечно.
• Сеть и утилиты: в jail могут отсутствовать инструменты или DNS‑резолвинг (особенно при net none).
• Права и capabilities: caps.drop all может ломать приложения, которым нужны специфичные операции (редко для обычных задач, чаще для низкоуровневых утилит).

Заключение

Sandbox в Termux на базе Firejail и механизмов namespaces — практичный и относительно простой способ усилить безопасность при тестировании скриптов и запуске не доверенного кода. Ключ к успеху — грамотная политика: изолировать файловую систему (private и allowlist), закрыть или строго ограничить сеть (net none или локальный сценарий для тестов), запретить доступ к устройствам (private-dev) и минимизировать системные возможности (caps.drop all).

Если вам нужна помощь с настройкой профилей под конкретное приложение, подбором параметров под вашу версию Android и валидацией изоляции — обращайтесь в РыбинскЛАБ. Мы поможем выстроить безопасный sandbox под ваши задачи.