tcb

Материал из ALT Linux Wiki
Версия от 00:03, 14 января 2021; MichaelShigorin (обсуждение | вклад) (комментарий solardiz@ насчёт /tcb в HP-UX)

В ALT для работы с паролями пользовательских входов используется схема TCB, в которой при добавлении новой учётной записи добавляется новая строка в файл /etc/passwd, новый подкаталог /etc/tcb/имя и файл shadow в нём. Для совместимости с другими схемами имя может содержать только латинские буквы, цифры и символ подчёркивания. Для задания полного имени пользователя можно использовать ключ -c "полное имя".

Переключение между схемой хранения паролей TCB, классической схемой (с единым файлом /etc/shadow) и строгой схемой (классическая, при которой команду passwd имеет право запускать только суперпользователь) управляется командой control passwd с параметрами tcb, traditional и restricted соответственно.

Импорт учётных записей из других систем, использующих shadow, не вызывает неприятностей, нужно только иметь в виду, что небезопасный ключ пребудет в shadow неизменным до тех пор, пока пользователь не сменит пароль (преобразование невосстановимого ключа из одного формата в другой, конечно, невозможно). При решении задач импорта-экспорта учётных записей стоит воспользоваться содержимым пакета tcb-utils.

Историческая справка

HP-UX действительно умеет размещать хеши по файлам в /tcb и имеет схожие утилиты конвертирования туда-сюда при включении-выключении trusted режима. Он умел/имел это еще до реализации нашего tcb в Owl, и мы не случайно используем то же название tcb для каталога. Но на этом внешняя схожесть заканчивается и начинаются принципиальные отличия. HP-UX не использует свой /tcb для безопасности сверх того что позволяет /etc/shadow. Как я понимаю, исторически у них /tcb появился как первый и когда-то единственный способ password shadowing - не в trusted режиме хеши лежали прямо в /etc/passwd, а поддержка /etc/shadow появилась позже чем поддержка /tcb. (Конвертировал когда-то свой HP-UX 10.20 туда-сюда, наблюдал это дело.) В этот же trusted режим они привязали и поддержку bigcrypt (которым лучше не пользоваться) - видимо, формально удовлетворяли требования сертификации. Зачем они вообще раскидали хеши по отдельным файлам если сами это никак для безопасности не используют (всё равно запись только от root, команда passwd(1) - SUID root), я могу только гадать, и моя догадка в том что это потенциально позволяет применять MAC, что опять же могло быть нужно для сертификации на какой-нибудь уровень, и что реально никто не делает. В нашем же tcb выставлены другие права доступа, что учтено в нашей libtcb (недоверие к содержимому каталогов при доступе от root) и что позволило снизить привилегии passwd(1) (и в Owl полностью избавиться от SUID root программ).
-- Solar Designer

Ссылки