Tcb: различия между версиями

Текущая версия от 00:33, 8 июля 2022

В 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

Ссылки

@@ Строка 7: / Строка 7: @@
 <!-- TODO: gpasswd -a, usermod -a -G: Задача добавления пользователя в какую-нибудь группу или удаления его оттуда традиционно решается с помощью команды {{cmd|vigr}} — редактированием файла {{path|/etc/group}} (или {{path|/etc/gshadow}}). {{cmd|vigr}} заботится о том, чтобы на время работы доступ к этому файлу был закрыт, а специально созданный временный файл отдаёт на редактирование программе, указанной в переменной окружения <tt>$EDITOR</tt>, после чего заменяет старый файл новым. Если перемещение пользователей по группам — частая задача, на основе {{cmd|vigr}} несложно написать соответствующий сценарий. -->
+== Историческая справка ==
+ 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 программ).
+ -- [http://www.opennet.ru/openforum/vsluhforumID3/122914.html#97 Solar Designer]
 == Ссылки ==
 * [http://www.openwall.com/tcb openwall.com/tcb]
 * <tt>[http://www.opennet.ru/man.shtml?topic=tcb&category=5&russian=0 tcb(5)]</tt> <!-- по мотивам http://docs.altlinux.org/manpages/tcb.5.html -->
 * [http://docs.altlinux.org/ru-RU/archive/2.4/html-single/master/alt-docs-master/ch06s19.html#distrib.setup.security документация ALT Linux 2.4 Master]
+* [http://www.opennet.ru/openforum/vsluhforumID3/101076.html#50 Так что нет, мы считаем tcb доделанным.]
 [[Категория:Admin]]