Чи безпечно залишати кореневу оболонку, запущену в сеансі окремого екрана?


20

Мені цікаво про безпеку залишення кореневої оболонки в сеансі окремого екрана. Я зазвичай ніколи цього не роблю.

Окрім потенційного впливу мого некореневого облікового запису користувача (відкритий пароль, схилений ключ ssh тощо), чи існують інші вектори входу в окремий, захищений паролем екранний сеанс, про який я повинен переживати, чи може відключений екран сеанс вважати інертним?


Це не відповідь, тому що я цього не знаю, але я не думаю, що це має різницю між тим, як ти сказав, і залишати роботу sudo.
phunehehe

7
@phunehehe Існує різниця, оскільки коли робота завершується, sudoдезактивується, коли справжня коренева оболонка залишається відкритою.
Майкл

Відповіді:


5

Я думаю, що це питання безпеки, тому що "окрім потенціалу мого некореневого облікового запису користувача" може бути досить великим.

Але крім цього є інші підвищені ризики. Наприклад, ви зараз відкрили собі теоретичний подвиг, який дозволяє змінювати дозволи в режимі розетки екрана ( /var/run/screenу моїй системі, але іноді /tmpвикористовується). Цей подвиг тепер має шлях до коріння, який інакше не може.

sudoЄ й інші переваги, якщо ви можете навчити себе використовувати його для кожної команди, а не виконувати sudo su -. Він реєструє дії (які, якщо ви не здійснюєте реєстрацію дистанційно, не значущо підвищує безпеку, але дає вам слід про те, що ви зробили). І це допомагає запобігти аваріям, вимагаючи навмисної ескалації для кожної команди, а не перемикаючись на повністю привілейований сеанс.


1
Хоча зараз подібного подвигу не відомо, я продовжуватиму не залишати кореневі оболонки відкритими на екрані. Ризики для облікового запису користувача є такими, які є. Спасибі.
Майкл

-1 Якщо у мене є експлойт, який може змінювати дозволи файлів, мені не потрібно зламати якийсь запущений екран. Я можу робити що завгодно із системою.
Let_Me_Be

@Let_Me_Be - це залежить від того, які дозволи на ваш файл може змінювати дозволи. Можливо, ви можете виконати лише кілька конкретних речей за певних ієрархій. Це не так надумано.
mattdm

Сам екран має велику поверхню атаки. У мене немає повної атаки, щоб показати , але явні слабкі місця.
Жил "ТАК - перестань бути злим"

виправте мене, якщо я помиляюся, але екранний додаток пов'язаний із сеансом оболонки (або безпосередньо на системній консолі, або через сеанс ssh). наскільки мені відомо, це не мережевий протокол як такий. отже, це так само безпечно, як і ваша сесія ssh або термінал. якщо хтось має доступ до сеансу ssh або до вашої фізичної машини, усі ставки відключені. якщо у них є достатній доступ, щоб потрапити на будь-який тип командного рядка під будь-яким обліковим записом користувача, ви також можете так само викинути безпеку вашого пристрою.
несинхронізований

10

Якщо ви маєте кореневу оболонку під час сеансу на екрані (відірваний чи ні, захищений паролем чи ні), а ваш screenвиконуваний файл не встановлений, а зловмисник, який отримує ваші привілеї, може виконувати команди в цій оболонці. Якщо нічого іншого, вони можуть це зробити, відстежуючи процес екрана.

Якщо екран налаштовано або налаштовано жорстко, а сеанс від'єднаний та захищений паролем, то в принципі потрібен пароль екрана для запуску команд у цій оболонці. Якщо цей принцип дотримується, хтось, хто лише скомпрометував ваш обліковий запис, повинен був би поставити троян на місце і чекати, коли ви введете пароль. Однак поверхня атаки (тобто кількість місць, де все може піти не так через помилку чи неправильну конфігурацію) незручно велика. Окрім основних функцій безпеки системи, ви довіряєте:

  • екран, щоб правильно перевірити пароль.
  • екран, щоб запобігти доступу до сеансу іншими способами.
  • екрану, щоб правильно використовувати механізми контролю доступу до ОС (наприклад, дозволи на труби).
  • ядро правильно виконувати перевірки безпеки 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 після чого багато місця та вірогідний підказ.

Екран реалізує кілька інших подібних ризикованих послідовностей управління, я не знаю, у чому полягає їх потенціал щодо вразливих місць. Але, сподіваємось, на даний момент ви можете побачити, що захист, запропонований паролями сеансу екрану, не настільки великий. Спеціалізований інструмент безпеки, такий як sudo, набагато рідше має вразливості.


+1 Відмінна відповідь. Дякуємо, що знайшли час, щоб усе це пояснити.
Майкл

1

Труби, створені екраном, доступні лише власникові, тому це не повинно бути проблемою безпеки.


5
Ви використовували "є" в першій частині свого речення, де ви, мабуть, мали на увазі "має бути". Не будемо вникати в звичку робити припущення.
Шадур

1
А? Труби, створені екраном, доступні лише власникові (якщо ви не вручну їх chmod).
Let_Me_Be
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.