Влияние записей в / etc / securetty

По умолчанию на 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

В чем разница между каждым из типов записей (console, vc / и tty ). В частности, каков конечный результат добавления и удаления каждого типа записи?

Насколько я понимаю, они влияют на то, как и когда вы можете войти, но есть ли другие эффекты? И когда вы можете и когда вы не можете войти в систему, в зависимости от того, какие записи есть?

РЕДАКТИРОВАТЬ 1 Что я знаю, так это то, что tty 1-6 соответствуют тому, можете ли вы войти в систему с первых 6 консолей, к которым вы обращаетесь, используя CTRL-ALT-F1 через CTRL-ALT-F6. Я всегда думал, что это были виртуальные консоли, поэтому я немного запутался. И что тоже соответствует консоли? Благодарю.

РЕДАКТИРОВАТЬ 2 Каков эффект, если таковые имеются в однопользовательском режиме?

/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] * позволит получить root-доступ с данного номера виртуальной консоли
• если вы используете udev (для динамического управления устройством и замены для devfs), добавление записей в формате tty [0-9] * позволит получить root-доступ с данного номера виртуальной консоли
• перечисление консоли в securetty обычно не имеет никакого эффекта, поскольку / dev / console указывает на текущую консоль и обычно используется только в качестве имени файла tty в однопользовательском режиме, на который не влияет /etc/securetty
• добавление записей типа pts / [0-9] * позволит программам, использующим псевдо-терминалы (pty) и pam_securetty, войти в систему с правами root, предполагая, что выделенный pty является одним из перечисленных; как правило, не стоит включать эти записи, потому что это угроза безопасности; это позволит, например, кому-то войти в root через telenet, который отправляет пароли в виде открытого текста (обратите внимание, что pts / [0-9] * - это формат для udev, который используется в RHEL 5.5; он будет другим, если использовать devfs или какая-то другая форма управления устройством)

Для однопользовательского режима /etc/securettyне используется, потому что вместо логина используется sulogin. Смотрите страницу руководства sulogin для получения дополнительной информации. Также вы можете изменить программу входа в систему, используемую /etc/inittabдля каждого уровня запуска.

Обратите внимание, что вам не следует использовать /etc/securettyдля управления root-входами через ssh. Для этого измените значение PermitRootLogin в /etc/ssh/sshd_config. По умолчанию /etc/pam.d/sshdне настроен для обращения к pam_securetty (и поэтому /etc/securetty). Вы можете добавить строку, чтобы сделать это, но ssh не устанавливает фактический tty, пока не пройдет некоторое время после этапа аутентификации, поэтому он не работает должным образом. На этапах авторизации и учетной записи - по крайней мере, для openssh - tty (PAM_TTY) жестко закодирован в "ssh".

Приведенный выше ответ основан на RHEL 5.5. Многое из этого будет относиться к текущим дистрибутивам других * nix систем, но есть различия, некоторые из которых я отметил, но не все.

Я ответил на это сам, потому что другие ответы были неполными и / или неточными. Многие другие форумы, блоги и т. Д. В Интернете также содержат неточную и неполную информацию по этой теме, поэтому я провел обширные исследования и тестирование, чтобы попытаться получить правильные детали. Если что-то, что я сказал, неверно, пожалуйста, дайте мне знать.

Источники:

• http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-sec-network.html#s1-wstation-privileges
• http://www.mathematik.uni-marburg.de/local-doc/centos5/pam-0.99.6.2/html/sag-pam_securetty.html
• http://linux.die.net/man/1/login
• http://www.tldp.org/HOWTO/html_single/Text-Terminal-HOWTO/
• http://www.kernel.org/doc/Documentation/devices.txt
• http://en.wikipedia.org/wiki/Virtual_console
• http://en.wikipedia.org/wiki/Linux_console
• http://www.kernel.org/doc/man-pages/online/pages/man4/console.4.html
• http://www.unix.com/security/8527-restricting-root-login.html
• http://www.redhat.com/mirrors/LDP/HOWTO/Serial-HOWTO-11.html#ss11.3
• http://www.mathematik.uni-marburg.de/local-doc/centos5/udev-095/udev_vs_devfs

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 и т. Д.), Не затрагиваются.