Tcb: различия между версиями
м (→Ссылки: +tcb(5)) |
|||
| (не показаны 3 промежуточные версии 2 участников) | |||
| Строка 7: | Строка 7: | ||
<!-- TODO: gpasswd -a, usermod -a -G: Задача добавления пользователя в какую-нибудь группу или удаления его оттуда традиционно решается с помощью команды {{cmd|vigr}} — редактированием файла {{path|/etc/group}} (или {{path|/etc/gshadow}}). {{cmd|vigr}} заботится о том, чтобы на время работы доступ к этому файлу был закрыт, а специально созданный временный файл отдаёт на редактирование программе, указанной в переменной окружения <tt>$EDITOR</tt>, после чего заменяет старый файл новым. Если перемещение пользователей по группам — частая задача, на основе {{cmd|vigr}} несложно написать соответствующий сценарий. --> | <!-- 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] | |||
=== SGID Directory treversal === | |||
Этот трюк кажется общеизвестным — и вместе с тем текст с внятным его описанием не гуглится. | |||
Что ж, переведём кусок [https://uneex.org/HSE/ArchitectureOS/13_GrantingActions#SETGID_directory_traversal вот этой лекции] | |||
Хеш пароля пользователя <tt>george</tt> лежит в файле {{path|/etc/tcb/george/shadow}}: | |||
-rw-r----- 1 george auth 80 сен 19 2018 /etc/tcb/george/shadow | |||
⇒ Процесс с <tt>UID=george</tt> имеет доступ на чтение и запись, а процесс с <tt>GID=auth</tt> — только на чтение | |||
Каталог {{path|/etc/tcb/george}} полностью доступен пользователю <tt>george</tt>, а создаваемые в нём файлы принудительно оказываются в группе <tt>auth</tt> (для того, чтобы процессы с <tt>GID=auth</tt> могли их читать) | |||
drwx--s--- 2 george auth 4096 сен 19 2018 /etc/tcb/george | |||
А вот каталог {{path|/etc/tcb}} вообще недоступен никому, кроме <tt>root</tt>: | |||
drwx--x--- 62 root shadow 4096 мар 24 13:41 /etc/tcb | |||
…с одним исключением: если процесс принадлежит группе <tt>shadow</tt>, то ''может'' получить доступ к ''конкретному подкаталогу'' этого каталога (бит '''x'''), хотя прочесть или модифицировать их список не может. | |||
⇒ Таким образом, чтобы получить доступ к файлу {{path|/etc/tcb/george/shadow}}, процесс должен ''одновременно'' принадлежать пользователю <tt>george</tt> и группе <tt>shadow</tt>. | |||
…и именно так запускается программа {{cmd|passwd}}! | |||
-rwx--s--x 1 root shadow 14552 июл 1 2018 /usr/bin/passwd | |||
В самом деле: | |||
* Процесс наследует UID у запустившего его пользователя <tt>george</tt> | |||
* Процесс получает участие в группе <tt>shadow</tt> благодаря биту '''s''' | |||
* Процесс ''не получает'' прав суперпользователя, и не имеет доступа к другим файлам {{path|/etc/tcb/<user>/shadow}} | |||
Алсо: чтобы найти все SGID-ные программы, можно запустить | |||
find /usr/*bin -perm -2000 -ls | |||
== Ссылки == | == Ссылки == | ||
* [http://www.openwall.com/tcb openwall.com/tcb] | * [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 --> | * <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://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]] | [[Категория:Admin]] | ||
Текущая версия от 21:41, 21 января 2025
В 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
SGID Directory treversal
Этот трюк кажется общеизвестным — и вместе с тем текст с внятным его описанием не гуглится.
Что ж, переведём кусок вот этой лекции
Хеш пароля пользователя george лежит в файле /etc/tcb/george/shadow:
-rw-r----- 1 george auth 80 сен 19 2018 /etc/tcb/george/shadow
⇒ Процесс с UID=george имеет доступ на чтение и запись, а процесс с GID=auth — только на чтение
Каталог /etc/tcb/george полностью доступен пользователю george, а создаваемые в нём файлы принудительно оказываются в группе auth (для того, чтобы процессы с GID=auth могли их читать)
drwx--s--- 2 george auth 4096 сен 19 2018 /etc/tcb/george
А вот каталог /etc/tcb вообще недоступен никому, кроме root:
drwx--x--- 62 root shadow 4096 мар 24 13:41 /etc/tcb
…с одним исключением: если процесс принадлежит группе shadow, то может получить доступ к конкретному подкаталогу этого каталога (бит x), хотя прочесть или модифицировать их список не может.
⇒ Таким образом, чтобы получить доступ к файлу /etc/tcb/george/shadow, процесс должен одновременно принадлежать пользователю george и группе shadow.
…и именно так запускается программа passwd!
-rwx--s--x 1 root shadow 14552 июл 1 2018 /usr/bin/passwd
В самом деле:
- Процесс наследует UID у запустившего его пользователя george
- Процесс получает участие в группе shadow благодаря биту s
- Процесс не получает прав суперпользователя, и не имеет доступа к другим файлам /etc/tcb/<user>/shadow
Алсо: чтобы найти все SGID-ные программы, можно запустить
find /usr/*bin -perm -2000 -ls