У меня есть сервер, который я хочу использовать в качестве SSH-шлюза для удаленной и локальной переадресации портов. Я не хочу, чтобы на нем можно было выполнять произвольные команды, только мои скрипты.
Я постоянно читаю о том, что из ограниченных оболочек легко выйти, но достаточно ли хорош rbash, если:
command="cmd_handler",no-pty,permitopen="127.0.0.1:*",permitopen="localhost:*",no-agent-forwarding,no-X11-forwarding
"cmd_handler" - это сценарий оболочки rbash, который может делать несколько различных специфических вещей, основанных на том, что передается в ssh из stdin. Он находится в папке ~/usr/bin вместе с симлинками на необходимые ему исполняемые файлы, а именно fold
, head
, nc
, sed
, ssh-keygen
, tee
, tr
. ~/usr/bin - единственная папка в PATH, поэтому это единственные доступные команды.
Пользователь является владельцем группы с доступом только для чтения для любых файлов или папок, требующих доступа (включая папку ~/usr/bin). Пользователь не является владельцем и не имеет доступа на запись к любым файлам и папкам, кроме ~/.ssh и ~/.ssh/authorized/keys (что необходимо).
Я не вижу, каким образом это оставляет систему уязвимой, поскольку единственная команда, которая может быть выполнена удаленным компьютером, это "cmd_handler". И если каким-то образом удаленный пользователь может выполнить другую команду, то это не так уж и много. tee
, sed
и ssh-keygen
создают теоретическую возможность модификации ~/.ssh/authorized_keys для выполнения произвольных команд, но даже если бы они могли, все, что есть вокруг для использования - это семь команд, и если они запишут что-то в /tmp или ~/.ssh, это не будет иметь значения, потому что rbash не будет выполнять ничего, что не находится в PATH.
Итак, вернемся к первоначальному вопросу: достаточно ли этого для того, что я хочу сделать, или мне действительно нужно изучить AppArmor или что-то еще? Я хотел бы получить ответ, объясняющий конкретную уязвимость, а не общие заявления о том, что все знают, что rbash легко взломать и тому подобное. Это может быть правдой, но является ли он конкретно небезопасным для этого приложения?
Наличие сценария, использующего ненадежный пользовательский ввод, в основном означает, что в этом сеансе есть пользователь с полной оболочкой (если в процедурах синтаксического анализа вашего сценария есть уязвимость). Итак, ваша настройка «PATH» на самом деле не играет роли.
Более того, ваш префикс ключа authorized_keys
позволяет удаленному пользователю открывать соединения с любыми локальными портами на машине, которые можно использовать для эксплуатации среды (если у вас есть слабая локальная служба, прослушивающая петлю интерфейс).
Чтобы правильно ответить на ваш вопрос (с выделением конкретных уязвимостей), нужно увидеть скрипт, который вы запускаете, и то, как он обрабатывает свои входные данные, поскольку в вашем случае это будет основным вектором эксплуатации. Однако, если вы создаете надежную среду, я бы предложил не полагаться на подход «список запрещенных» (когда вы пытаетесь заблокировать все нежелательные вещи), а вместо этого использовать подход «список разрешений» (когда вы определяете, что разрешено явно, с неявным запретом по умолчанию). Однако в вашем случае, учитывая, что вы хотите использовать сценарии bash, я бы рассмотрел решения MAC, такие как SELinux, где я бы назначил пользователя SELinux для учетной записи и определил ограниченный домен для процессов, запущенных этим пользователем.