Вплив записів у / etc / securetty


19

За замовчуванням на RHEL 5.5 у мене є

[deuberger@saleen trunk]$ sudo cat /etc/securetty 
console
vc/1
vc/2
vc/3
vc/4
vc/5
vc/6
vc/7
vc/8
vc/9
vc/10
vc/11
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
tty11

Яка різниця між кожним із типів запису (консоль, vc / та tty ). Зокрема, який кінцевий результат додавання та видалення кожного типу запису?

Я розумію, що вони впливають на те, як і коли ви можете увійти, але чи є інші ефекти? І коли ви можете і коли не можете увійти, залежно від того, які записи є?

РЕДАКТИКА 1 Я знаю, що tty 1-6 відповідають тому, чи можете ви увійти з перших 6 консолей, до яких ви потрапляєте, використовуючи CTRL-ALT-F1 через CTRL-ALT-F6. Я завжди думав, що це віртуальні консолі, тому я трохи розгублений. І що відповідає також консолі? Спасибі.

EDIT 2 Який ефект, якщо такий є в режимі одного користувача?

Відповіді:


34

/etc/securettyпроводиться консультація модулем pam_securetty, щоб визначити, з якого коріння віртуальних терміналів (ttyS) дозволено входити в систему. Раніше /etc/securettyз такими програмами, як увійти в систему , зверталися безпосередньо, але зараз PAM це вирішує. Тож зміни /etc/securettyвпливатимуть на будь-яке використання PAM з файлом конфігурації, в якому використовується pam_securetty.so. Отже, за замовчуванням впливає лише програма входу. /etc/pam.d/loginвикористовується для локальних входів і /etc/pam.d/remoteвикористовується для віддалених входів (наприклад, telnet).

Основні типи запису та їх афекти такі:

  • Якщо /etc/securettyйого не існує, root може входити з будь-якого tty
  • Якщо /etc/securettyіснує і порожньо, доступ до кореневих файлів буде обмежений режимом одиночного користувача або програмами, які не обмежені pam_securetty (тобто su, sudo, ssh, scp, sftp)
  • якщо ви використовуєте devfs (застарілу файлову систему для обробки / dev), додавання записів форми vc / [0-9] * дозволить увійти в систему з вказаного номера віртуальної консолі
  • якщо ви використовуєте udev (для динамічного керування пристроєм та заміни devfs), додавання записів форми tty [0-9] * дозволить кореневий вхід із заданого номера віртуальної консолі
  • Перерахування консолі в безпеці, як правило, не має ефекту, оскільки / dev / console вказує на поточну консоль, і зазвичай використовується лише як ім'я файлу tty в режимі одиночного користувача, на що не впливає /etc/securetty
  • додавання записів, таких як pts / [0-9] *, дозволить програмам, які використовують псевдотермінали (pty) та pam_securetty, входити в корінь, припускаючи, що виділений pty є одним із перелічених; зазвичай не рекомендується включати ці записи, оскільки це ризик для безпеки; це дозволило б, наприклад, комусь увійти в root через теленет, який надсилає паролі в простому тексті (зауважте, що pts / [0-9] * - це формат для udev, який використовується в RHEL 5.5; він буде іншим, якщо використовувати devfs або іншої форми управління пристроєм)

У режимі одиночного користувача /etc/securettyне проводиться консультація, оскільки замість входу використовується сулогін. Для отримання додаткової інформації дивіться сторінку чоловіка із сулогіном. Також ви можете змінити програму входу, що використовується /etc/inittabдля кожного рівня запуску.

Зауважте, що вам не слід використовувати /etc/securettyдля керування кореневими логінами через ssh. Для цього змініть значення PermitRootLogin в /etc/ssh/sshd_config. За замовчуванням /etc/pam.d/sshdне налаштовано для консультування з пам’яткою (та, отже /etc/securetty). Ви можете додати рядок, щоб це зробити, але ssh не встановлює фактичну tty лише десь після етапу auth, тому він не працює, як очікувалося. Під час етапів auth та account - принаймні для openssh - tty (PAM_TTY) важко кодується до "ssh".

Вищенаведена відповідь ґрунтується на RHEL 5.5. Значна частина цього стосуватиметься поточних розподілів інших * nix систем, але є відмінності, деякі з яких я зазначив, але не всі.

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

Джерела:


+1 за те, що знайшли час відповісти в такій глибині. Я не впевнений, чому тут немає прийнятої відповіді. Схоже, ви відповіли на питання ОП. Мені подобається коментар @Alexios, "vc / X та ttyX - синонім [ous] ..."
harperville

Нещодавно видалений Debian / etc / securetty. Це вважається застарілим, і, мабуть, більше клопоту, ніж варто. Він використовувався для telnet та rlogin, але для того, щоб деякі входи контейнерів працювали, в деяких системах додаються псевдотермінали типу "pts / 0", що перемагає первісне призначення. Якщо вам потрібно обмежити вхід до кореневого режиму певним набором пристроїв, існують більш надійні механізми. Дивіться bugs.debian.org/731656
dlitz

4

vc/Xі ttyXє синонімами: різні шляхи до одних і тих же пристроїв. Сенс надмірності полягає в тому, щоб зловити різні випадки, щоб не заблокувати вас.

Традиційно login(і, можливо getty, я не можу точно згадати) перевіряв би /etc/securettyі забороняв rootвходи в невключені термінали. У сучасних системах є й інші способи зробити це та інші заходи безпеки. Ознайомтеся з вмістом /etc/login.defs(який також охоплює securettyфункціональність і рекомендований securetty(5)вручну), а також /etc/pam.d/login, де ви можете контролювати поведінку цієї функції.

Оскільки securettyце перевірено лише loginзасобами входу, які не використовуються login(наприклад, SSH з use_login=no, X-менеджерами дисплеїв тощо), це не впливає.


Варто зазначити, що на busyboxбазі систем він все-таки може бути корисним для простого факту, що у loginнього немає /etc/login.defsпідтримки.
phk
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.