NIS: какой механизм скрывает shadow.byname для непривилегированных пользователей?
На каком-то Linux-боксе (SLES 11.1), который является клиентом NIS, я могу сделать это как root
ypcat shadow.byname
и получить вывод, то есть некоторые строки с зашифрованными паролями, среди другой информации.
На том же компьютере с Linux, если я запускаю ту же команду, что и непривилегированный пользователь, я получаю
No such map shadow.byname. Reason: No such map in server's domain
Теперь я удивлен. Мои старые добрые знания говорят, что теневые пароли в NIS абсурдны, потому что в протоколе нет контроля доступа или аутентификации, и поэтому каждый (непривилегированный) пользователь может получить доступ к теневой карте и, таким образом, получить зашифрованные пароли.
Очевидно, у нас здесь другая картина. К сожалению, у меня нет доступа к серверу NIS, чтобы выяснить, что происходит. Мое единственное предположение состоит в том, что мастер NIS выдает карту только клиентам, подключенным к привилегированному порту (>1024), но это только необразованное предположение.
Какие механизмы существуют в текущих реализациях NIS, чтобы привести к поведению, подобному описанному выше? Насколько они "безопасны"? Можно ли обойтись легко? Или теневые пароли в NIS так же безопасны, как старые добрые теневые файлы?
1 ответ
Доступ к картам, которые не доступны для чтения под /var/yp/{domainname}/ на главном сервере NIS ограничен клиентами, делающими запрос от привилегированного порта (<1024). Это не так безопасно, как местные /etc/shadow но все же немного лучше, чем ничего.
Для большей безопасности Sun разработала NIS+, но она так и не получила широкого распространения.
Намного лучше LDAP, где хэш пароля не нужно извлекать с сервера на клиент, а вместо этого клиент отправляет предложенный пароль на сервер для проверки (LDAP auth-bind).