Безопасно ли оставить корневую оболочку, запущенную в сеансе отдельного экрана?

Мне интересно, как оставить оболочку root запущенной в сеансе отдельного экрана. Обычно я этого не делаю.

Помимо возможности нарушения моей учетной записи пользователя, не являющегося пользователем root (пароль открыт, скомпрометирован ssh-ключ и т. д.), существуют ли другие векторы входа в сеанс сеанса, который защищен паролем, я должен быть обеспокоен или может сеанс отдельного экрана считается инертным?

20 голосов | спросил Michael 4 MarpmFri, 04 Mar 2011 17:45:30 +03002011-03-04T17:45:30+03:0005 2011, 17:45:30

3 ответа


5

Я думаю, что это проблема безопасности, потому что «Помимо потенциальности скомпрометированной учетной записи пользователя, отличного от пользователя root», может быть довольно большой.

Но помимо этого существуют и другие повышенные риски. Например, теперь вы открыли себе теоретический эксплойт, который позволяет изменять разрешения в каталоге dir экрана (/var/run/screen на моем система, но иногда используется /tmp). У этого эксплойта есть путь к корневому каталогу, который он не мог бы сделать иначе.

sudo имеет другие преимущества, если вы можете обучить себя использовать его для каждой команды, а не делать sudo su -. Он регистрирует действия (которые, если вы не регистрируетесь удаленно, не осмысленно увеличивают безопасность, но дают вам след того, что у вас сделано). И это помогает предотвратить несчастные случаи, требуя преднамеренной эскалации для каждой команды, вместо перехода на полностью привилегированный сеанс.

ответил mattdm 4 MarpmFri, 04 Mar 2011 18:35:11 +03002011-03-04T18:35:11+03:0006 2011, 18:35:11
10

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

Если экран установлен на setuid или setgid, а сеанс отключен и защищен паролем, тогда в принципе для запуска команд в этой оболочке требуется пароль экрана. Если этот принцип соблюдается, кто-то, кто только скомпрометировал вашу учетную запись, должен был бы установить троянец и ждать, пока вы наберете пароль. Однако поверхность атаки (то есть количество мест, где все может пойти не так, из-за ошибки или неправильной конфигурации), неудобно велико. Помимо основных функций безопасности системы, вы доверяете:

  • , чтобы правильно проверить пароль.
  • , чтобы предотвратить доступ к сеансу другими способами.
  • , чтобы правильно использовать механизмы управления доступом к ОС (например, разрешения на каналы).
  • Ядро для корректной проверки безопасности ptrace (это частой источник уязвимостей).
  • работающая оболочка не делает ничего глупого.
  • какая-то другая функция не укусить вас.

«Еще одна особенность не укусить вас»: да, это расплывчато. Но это всегда забота в безопасности. У вас может возникнуть соблазн отклонить это как простое принятие желаемого за действительное, но вы действительно все думали? Например ...

Пока вы можете записывать на терминальное устройство, вы можете вводить данные во входные данные этой оболочки. В настройках экрана по умолчанию на моей машине:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

Вставляет ␛]lfoobar␛l во входной поток оболочки. \ek - это управляющая последовательность, которая позволяет приложению (или любому, что может записать на терминальное устройство) установить заголовок окна (см. раздел «Именование окон» в руководстве по экрану ) и \e[21t заставляет терминал указывать заголовок на стандартном входе приложения (экран не документирует эту последовательность, но выполняет ее, вы можете найти ее под CSI Ps ; Ps ; Ps ; t в списке последовательностей xterm . Фактически, по крайней мере, на экране 4.0.3 все управляющие символы удаляются из указанного заголовка, поэтому оболочка читает lfoobar (предполагается, что ␛] не привязан к команде редактирования) и не имеет новой строки. Таким образом, злоумышленник не может фактически выполнить команду таким образом, но может наполнить команду вроде chmod u+s /bin/sh, за которой следует много места s и вероятный запрос.

Экран реализует несколько других подобных рискованных контрольных последовательностей, я не знаю, какова их потенциальная уязвимость. Но, надеюсь, к настоящему времени вы можете видеть, что защита, предоставляемая паролями сеансов сеанса, не так уж велика. У специализированного инструмента безопасности, такого как sudo, вероятность появления уязвимостей значительно реже.

ответил Gilles 5 MaramSat, 05 Mar 2011 00:15:14 +03002011-03-05T00:15:14+03:0012 2011, 00:15:14
1

Труды, созданные экраном, доступны только владельцу, поэтому это не должно быть проблемой безопасности.

ответил Let_Me_Be 4 MarpmFri, 04 Mar 2011 18:02:47 +03002011-03-04T18:02:47+03:0006 2011, 18:02:47

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132