Rssh(1)

Материал из wiki.lissyara.su
Перейти к: навигация, поиск

НАЗВАНИЕ

rssh - безопасная ограничивающая командная оболочка для применения только по протоколам scp и/или sftp

СИНТАКСИС

rssh [ опции... ] [ ... ]
rssh -v

ОПИСАНИЕ

rssh является командной оболочкой для предоставления ограниченного доступа к хостам через SSH(1), что позволяет пользователю, оболочка которого настроен на rssh использовать одну или несколько команд. Она предназначена главным образом для работы с OpenSSH (см. www.openssh.com), но может работать и с другими реализациями ssh.
Системный администратор должен установить на оболочку ограничения системы. Затем файл паролей входа любого пользователя, для которого было бы желательно предоставить ограниченный доступ должен быть изменен таким образом, чтобы их командной оболочка был rssh. Например: 
      luser:x:666:666::/home/luser:/usr/bin/rssh
Если rssh будет вызван с опцией -v, то rssh сообщит о своей версии и закончит работу. Все остальные аргументы rssh специфичны для удаленного ssh клиента, и не представляют большого интереса для среднего пользователя. Аргументы должны быть при условии того, что оболочка на удаленном конце будет получать и корректно проводить контроль команд SCP(1), SFTP(1) и т.д. Если rssh принимает аргументы, которые не корректны, он выводит сообщение об ошибке и заканчивает работу. Если программа пользователя пытается запустить то, что не разрешено, или содержит синтаксис, который будет пытаться выполнить команды оболочки (например, замена команды), он также будет выводить ошибку и заканчивать работу.
rssh имеет конфигурационный файл, rssh.conf(5), который позволяет управлять поведением rssh. Смотрите man страницу по rssh.conf(5) для более подробного изучения.

ПРИМЕЧАНИЕ О БЕЗОПАСНОСТИ

Прочитайте этот раздел очень внимательно, или вы можете подвергнуть операционную систему риску быть взломанной или выведенной из строя!
Использование rss с CVS
Если вы используете rssh для предоставления CVS доступа, то следует отметить, что невозможно помешать пользователем, кто хорошо знаком с CVS и в обход rssh может получить доступ к командной оболочке, даже если пользователь не имеет права доступ на запись в хранилище. Очевидно, что пользователь должен иметь права доступ на запись в хранилище, чтобы обновлять его, что позволяет им загружать депозитарий в хранилище. CVS предусматривает ряд механизмов для выполнения таких произвольных программах... Единственный надежный способ разумно использовать rssh с CVS является использование изолированной клетки(jail) в которой будут размещаться хранилища CVS в изолированной среде. Пожалуйста, см. ниже, и все соответствующие документы для получения более подробной информации о том, как создать изолированную клетку(jail). Заметим, что пользователи будут иметь возможность получить доступ к оболочке в клетке(jail); только защита обеспечивается в тем, что они не могут вырваться из клетки(jail). Я(автор rssh, Derek D. Martin) сохраню поддержку CVS, поскольку эта защита лучше, чем полное отсутствие защиты. Вы были предупреждены. Используйте CVS на свой страх и риск.
Потенциальный администратор, компромисс в старой версии
До rssh v.2.3.0, если обычный пользователь имел доступ к командной оболочке машины с установленным rssh, пользователь мог произвольно использовать файловую систему. Для снижения риска использования этого метода в старых версиях rssh, необходимо использовать контроль доступа к файлам и папкам, чтобы убедиться в том, что пользователь не может написать любой файл на тот же раздел, занятый ОС, а также на те разделы, в которых запрещен запуск программ. В rssh v.2.3.0, это нападение можно предотвратить путем изолирования приложений в клетке(jail), с условием что ваша клетка(jail) установлен корректно. В частности, убедитесь в том, что регулярные пользователи не могут писать по каталогам внутри клетки, в которых содержатся скопированые исполняемые программы. Это должно быть очевидным, но оно должно быть сказано. Несмотря на то, что это не является строго необходимым, чтобы дополнительно защитить вашу систему от возможных компромиссов. Также рекомендуется ознакомиться с разделом озаглавленным "Гарантии против игнорирование rssh".
Гарантии против Игнорирование rssh
rssh предназначена для взаимодействия с другими программами. Даже если rssh полностью исключит все свои ошибка, изменения в других программах, возможно, приведут к появлению методов для того, чтобы обойти защиту, для обеспечения которой предназначена rssh. Это важно для системного администратора быть уверенным в программах, работающих с rssh, и что эти команды, не предусматривают механизмов, позволяющих пользователю запускать произвольные команды. В тоже время, цель каждого релиза заключается в том, чтобы бы избавиться от ошибок, ничто не идеально... Поэтому в rssh могут быть ошибки, которые могли бы позволить пользователю обойти защиту.
Вы можете защитить вашу систему от тех, кто хотел бы воспользоваться такой уязвимостью. Это не является обязательным для правильной работы rssh, но это очень хорошие рекомендации. Существуют шесть основных шагов:
1. защитить всех не-администраторов с rssh (т.е. обычный пользователь не должен иметь доступ к оболочке сервера;
2. поместить ваших пользователей в клетку(jail);
3. ограничить запускаемые программы, которые доступны в клетке(jail) до абсолютного минимума;
4. монтировать домашний каталог с флагом noexec/nosuid (например, использование отдельных разделов в клетке(jail) для пользователей домашних каталогов и все другие файлы, если это возможно/разумного);
5. создать группу для rssh пользователей, а также ограничить доступ к исполняемым программам пользователей в этой группе.
6. использовать стандартные права доступа внимательно и аккуратно;
Если возможно, убедитесь в том, что обычный пользователь не имеет какого-либо доступ к системе кроме как через rssh. В противном случае, пользователи смогут использовать необнаруженные ошибки в rssh_chroot_helper, и получить административный доступ к серверу.
rssh предоставляет системному администратору возможность поместить пользователей в изолированную среду. Смотрите подробности в man странице по rssh.conf и в файле CHROOT, который распространяется с rssh. Если вы хотите быть уверены в том что пользователи не смогут запускать произвольные программы, используйте клетку(jail), и не ставьте какие-либо программы, помимо тех, что абсолютно необходимы для обеспечения работы пользователя. Это предотвращает их запуск стандартной системы команд.
Затем убедитесь, что файлы пользователя внутри клетки(jail) имеют отдельную файловую систему отличную от системных каталогов и исполняемых директорий. Если возможно в вашем окружении, убедитесь, что вы монтируете файловую систему, используя флаги noexec или/и nosuid, если ваша операционная система поддерживает их. Это даст пользователям возможность выполнить программы, которые они загрузят на целевую машину (например, с помощью scp), которые могут быть исполняемым, и предотвращать SUID программы с SUID битом. Имейте в виду, что использования этих флагов требуется, чтобы пользовательские файлы находились на отдельном разделе от программ и библиотек системы, которые живут в клетке(jail). Поэтому вам нужно как минимум 2 раздела для вашей клетке(jaul),и разместить файлы в них надо правильно, один для системы и исполняемых программ в клетке(jail), а другой для каталога пользователей.
Кроме того, необходимо создать группу, например, "rsshuser", для rssh пользователей. Добавьте всех пользователей в эту группу, которые будут ограничены rssh. Установите права собственности и разрешений на rssh и rssh_chroot_helper так, что только эти пользователи смогут выполнять их. Следующие команды иллюстрируют это: 
      # groupadd rsshuser
      # chown root:rsshuser rssh rssh_chroot_helper
      # chmod 550 rssh
      # chmod 4550 rssh_chroot_helper
В добавок используйте стандартные Unix/POSIX права доступа к файлам и папкам, чтобы они не смогли получить доступ к файлам клетке(jail).
Командная строка Parser
С rssh версии 2.2.3, программа должна проверять вывод командной строки, чтобы избежать выполнения произвольных программ (и, следовательно, обходить безопасность rssh). Для того, чтобы сохранить исходный код здравым, анализатор является немного чрезмерно фанатичным к соответствиям вариантов командной строки. На практике это, вероятно, не будет проблемой, но теоретически это возможно.
Если вы столкнулись с проблемой, когда rssh отказывается запускать на выполнение команду, утверждая, что это отклонение и оно небезопасно, попробуйте изменить проверку вашей командной строки таким образом, чтобы все короткие варианты указывали в качестве одного вариант флага (например, -e -p вместо -ep) и убедитесь, что аргументы и флаги разделены разделителем пробела(например, -p 123 вместо -p123). Практически во всех случаях, это должно решить проблему. Разумеется, исчерпывающий поиск моежет быть не выполнен.
Альтернативой было бы включение полного анализатора командной строки для rcp, rdist и rsync; это было бы выходом из сферы действия данного проекта. На практике, существующего анализатора должно хватить. Однако, если Вы найдете те случая, когда этого не происходит, пожалуйста, подробности в список рассылки rssh. Подробности о том, как отправить письмо в список рассылки rssh можно найти на домашней странице rssh.


OpenSSH версии и обход rssh
До OpenSSH v.3.5, sshd(8), будет пытаться проанализировать файлы в домашней директории пользователя, а также может попытаться запустить скрипт от пользователя в каталоге $HOME/.ssh. rssh не использует пользовательскую среду каким-либо образом. Соответствующая команда выполняется по вызову execv(3) и полному пути к команде, как это определено во время компиляции. Она не зависит от пользовательской переменной PATH, или от любой другой переменной окружения.
Существуют, однако, несколько проблем, которые могут возникнуть. Это объясняется исключительно тем, работой sshd проекта OpenSSH, и это ни в коей мере не по вине rssh. Например, одна проблема, которая может существовать в том, что, в соответствии со страницей man sshd(8), по крайней мере, некоторых релизов OpenSSH, команды, перечисленные в каталоге $HOME/.ssh/rc выполняются через /bin/sh вместо пользовательского командного интерпретатора. Если какой-либо релиз из OpenSSH подвержен этой проблеме, то очень вероятно, что он является устаревшим. До тех пор, пока вы работаете с последние версией OpenSSH, это не должно быть проблемой, насколько я могу сказать.
If your sshd is vulnerable to this attack, there is a workaround for this problem, though it is pretty restrictive. The user's home direc tory absolutely must not be writable by the user. If it is, the user can use sftp to remove the directory or rename it, and then create a new one, and fill it up with whatever environment files they like. For providing file uploads, this means a user-writable directory must be created for them, and they must be made aware of their inability to write into their home directory other than in this location.
A second problem is that after authenticating the user, sshd also reads $HOME/.ssh/environment to allow the user to set variables in their environment. This allows the user to completely circumvent rssh by clever manipulation of such environment variables as LD_LIBRARY_PATH or LD_PRELOAD to link the rssh binary against arbitrary shared libraries. In order to prevent this from being a problem, as of version 0.9.3, by default rssh is now compiled statically. The restrictive work-around mentioned above will also defeat this sort of attack.
В OpenSSH с v.3.5, sshd теперь поддерживает опцию PermitUserEnvironment, который устанавливается на "no" по умолчанию. Этот параметр позволяет ограничить командные оболочки, такие как rssh. С rssh версии 1.0.1, конфигурационный скрипт определяет, что OpenSSH присутствует, и отключает нужные параметры.

ОШИБКИ

Никаких.
Замечание о получении справки
Если у вас возникли проблемы при работе rssh, или Вы считаете, что обнаружили ошибку, пожалуйста, используйте список рассылки, а не присылайте электронную почту мне непосредственно. Вы должны зарегистрироваться в списке, с тем чтобы получить возможность отправлять сообщения. Информация о том, как зарегистрироваться можно на главной странице rssh. Если вы отправляете почту мне напрямую с вопросами, я почти наверняка вас проигнорирую. Присылайте ваши вопросы и предложения в список рассылки. Также Вы можете высказать свое мнение по поводу rssh в списке, независимо от того, положительное оно или отрицательное (в особенности негативные).
Проблемы безопасности
Единственным исключением из вышеизложенного, если вы считаете, что обнаружили проблему с безопасностью rssh. Если это так, то, пожалуйста, свяжитесь со мной в частном порядке. Если вы не можете найти мой прямой контакт, отправить сообщение в список, с просьбой связаться с вами по поводу потенциальной проблемы безопасности. Проблемы безопасности должны рассматриваться в частном порядке. Я отношусь к проблемам безопасности серьезно, и буду работать для устранения их в кратчайшие сроки.
Перед тем, как писать письмо на мою электронную почту или в список рассылки, не забудьте внимательно прочитать все следующие файлы: README, INSTALL, CHROOT, SECURITY. Все эти файлы распространяются с исходными кодами программы rssh, а также во всех бинарных пакетах rssh. Если вы загрузили пакет в бинарном виде, то эти файлы должны быть расположены там, где ваш дистрибутив ведет свою документацию (обычно /usr/share/doc/rssh-version/ или нечто подобное). Кроме того, внимательно прочитайте документацию по rssh(1), и rssh.conf(5). Наконец, если все еще возникают проблемы, прочитайте FAQ на http://www.pizzashack.org/rssh/faq.shtml. Если я пойму что вы не читали документацию, я буду вас игнорировать. В большинстве случаев, в этих документах уже есть все, что вам нужно, чтобы rssh работал, и я не смогу объяснить это лучше, чем я сделал это в этиъ документах...

СМОТРИТЕ ТАКЖЕ

rssh.conf(5), sshd(8), SSH(1), SCP(1), SFTP(1).
Источник — «http://wiki.lissyara.su/w/index.php?title=Rssh(1)&oldid=5270»