Кратко

  • RFC 2307 описал LDAP-представление учётных записей Unix, групп и сетевых данных. В класс posixAccount входил uidNumber — числовой идентификатор, по которому системные функции находили пользователя.
  • Раздел безопасности назвал последствие ошибочно выданного права записи: пользователь, способный менять uidNumber, мог приравнять свою учётную запись к суперпользователю. Риск зависел от того, кому разрешено редактирование системных записей.

Поиск учётной записи начинается с числа

Процесс Unix не просит каталог рассказать биографию владельца. Он передаёт число библиотеке C и получает связанную запись учётной записи. В RFC 2307 для этого приведена функция getpwuid(): она находит имя входа по идентификатору пользователя. В предложенной модели LDAP служба искала posixAccount, у которого uidNumber совпадал с числом, полученным от программы.

В файле это всего одна колонка. Для системы это идентификатор.

До LDAP сети Unix уже могли обмениваться сведениями об учётных записях и узлах через Network Information Service (NIS). Руководство Sun по администрированию Solaris описывает карты NIS как таблицы «ключ — значение». Главный сервер хранит карты домена, ведомые серверы держат их копии, а клиент может обращаться к любому из них. Карта passwd.byname ищет запись по имени входа; passwd.byuid использует ключом номер пользователя. Администратор создаёт карты на главном сервере из локальных файлов и распространяет их на ведомые.

Так локальное редактирование превращалось в сетевой ответ. Администратор менял исходный файл, заново собирал карту, и клиенты домена получали обновлённую запись. Код поиска не проводил проверку номера голосованием всех клиентов. Он использовал значение, которое вернула служба имён.

В руководстве SunOS 1999 года осталась и история названия. Раньше NIS назывался Sun Yellow Pages; после переименования из-за британского товарного знака его функции сохранились. Название изменилось, роль карты учётных записей — нет.

LDAP изменил место хранения; право записи осталось вопросом управления

RFC 2251 в декабре 1997 года определил LDAPv3 как менее затратный по ресурсам способ обращаться к каталогам X.500, чем полноценный DAP. Примерно через три месяца вышел RFC 2307, An Approach for Using LDAP as a Network Information Service. Документ предложил классы и атрибуты LDAP для данных Unix и TCP/IP.

Речь шла не только об именах узлов. Схема охватывала учётные записи и группы, названия служб и номера протоколов, идентификаторы RPC, параметры загрузки, сетевые адреса и сетевые группы NIS. Класс posixAccount позволял хранить имя входа, отображаемое имя, uidNumber, gidNumber, домашний каталог и командную оболочку. В RFC также показано, как строку из файла наподобие /etc/passwd представить атрибутами каталога.

У такой связки была понятная практическая причина. Приложения Unix уже запрашивали сведения об учётной записи через библиотеку C. Источником могла стать сетевая служба каталога вместо локального файла, а приложения сохраняли привычный интерфейс поиска. В разделе об реализации RFC 2307 упомянуты сервер NIS, который использовал LDAP вместо локальных файлов, эталонная реализация поиска для библиотеки C и сценарии загрузки /etc/passwd и /etc/hosts в LDAP.

RFC 2307 опубликован в категории Experimental и не предписывал всем системам Unix переходить на LDAP. Документ сообщает о нескольких успешных реализациях, но не подсчитывает установки и не измеряет распространённость.

Число стало границей полномочий

В разделе безопасности RFC 2307 говорится о том, какую силу запись каталога может иметь для операционной системы. Менять записи системных сущностей должны только администраторы. Причина сформулирована прямо: если пользователь может изменить собственный uidNumber, он способен подорвать безопасность и сделать свою учётную запись равной учётной записи суперпользователя.

RFC 2307 описывает условный риск и указывает точку контроля. Программа Unix связывает число с учётной записью; каталог может передавать это соответствие многим клиентам; имеющий право записи способен изменить идентичность, которую они увидят. Схема задаёт формат поля. Правило доступа определяет, кто может менять значение, важное для системы.

В том же разделе отмечено столкновение поиска и защиты секретов. Если непривилегированные пользователи могут читать зашифрованные хеши паролей, созданные распространёнными средствами вроде crypt(), их можно атаковать словарным перебором и полным перебором. RFC связывал такую схему с совместимостью существующих систем Unix, а для сред с более высокими требованиями к защите рекомендовал сильную службу аутентификации. Общий каталог упрощает поиск, но может открыть чувствительные данные учётных записей большему числу клиентов.

Источники подтверждают предложение и предупреждение, записанное в самом RFC. Насколько широко LDAP применялся для учётных записей Unix, эти документы не показывают; для этого нужна отдельная статистика установок.

Главная перемена состояла не в том, что у базы данных появилась ещё одна схема. Операционная система стала принимать ответ на локальный вопрос из сети. uidNumber мог оставаться одной колонкой, но смысл ему придавала программа, которая его читала. При переходе от /etc/passwd к NIS или LDAP менялись и точки контроля: какой источник считается главным, какая копия содержит актуальную карту и кто вправе изменять идентификатор пользователя?

Источники