Безопасен ли rbash, если логин пользователя и пароли ssh отключены?

У меня есть сервер, который я хочу использовать в качестве SSH-шлюза для удаленной и локальной переадресации портов. Я не хочу, чтобы на нем можно было выполнять произвольные команды, только мои скрипты.

Я постоянно читаю о том, что из ограниченных оболочек легко выйти, но достаточно ли хорош rbash, если:

  • у пользователя нет пароля (поэтому он не может войти в оболочку)
  • пароли ssh отключены (поэтому требуется ключ)
  • PATH=~/usr/bin (только, поэтому никакие файлы из других мест не могут быть выполнены)
  • запись в ~/.ssh/authorized_keys имеет префикс: 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 легко взломать и тому подобное. Это может быть правдой, но является ли он конкретно небезопасным для этого приложения?

3
задан 19 April 2015 в 04:54
1 ответ

Наличие сценария, использующего ненадежный пользовательский ввод, в основном означает, что в этом сеансе есть пользователь с полной оболочкой (если в процедурах синтаксического анализа вашего сценария есть уязвимость). Итак, ваша настройка «PATH» на самом деле не играет роли.

Более того, ваш префикс ключа authorized_keys позволяет удаленному пользователю открывать соединения с любыми локальными портами на машине, которые можно использовать для эксплуатации среды (если у вас есть слабая локальная служба, прослушивающая петлю интерфейс).

Чтобы правильно ответить на ваш вопрос (с выделением конкретных уязвимостей), нужно увидеть скрипт, который вы запускаете, и то, как он обрабатывает свои входные данные, поскольку в вашем случае это будет основным вектором эксплуатации. Однако, если вы создаете надежную среду, я бы предложил не полагаться на подход «список запрещенных» (когда вы пытаетесь заблокировать все нежелательные вещи), а вместо этого использовать подход «список разрешений» (когда вы определяете, что разрешено явно, с неявным запретом по умолчанию). Однако в вашем случае, учитывая, что вы хотите использовать сценарии bash, я бы рассмотрел решения MAC, такие как SELinux, где я бы назначил пользователя SELinux для учетной записи и определил ограниченный домен для процессов, запущенных этим пользователем.

0
ответ дан 19 August 2021 в 02:01

Теги

Похожие вопросы