После 10 лет разработки состоялся релиз механизма управления теневыми паролями...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54391
Самый лучший механизм!!
оно и видно. 2 человека скачало.
> оно и видно. 2 человека скачало.Поколение лайков...
Вы вообще пытались головой подумать -- кому именно надо "скачивать"?
ХАХАХА, вы расскажите тогда что они в дистрибутивах по умолчанию делают тогда? ИЛИ У МЕНЯ ДИСТРИБУТИВ ЗАВЕДОМО ПОДМЕНЕН?
Самый глупый аноним!
Самый глупый это Fractal. Хотя он не аноним.
> Обработчик /etc/shadow всегда получает доступ сразу ко всем хэшам паролейа tcb не имеет такой возможности совсем? Как он будет проверять хэши тогда при логине?
В случае tcb можно запускать обработчик под тем пользователем, чей пароль мы хотим проверить.
> Ну так что мешает сказать что хочу пароль рутаСказать-то ничего не мешает, а вот получить - мешают недостаточные права доступа к файлу с паролем рута. У процесса (если не от рута проверка, есс-но) есть доступ только к своему файлу со своим же паролем на уровне тупо файловой системы. Хош - меняй, хош - проверяй. Но только свой.
процесс запускается с правами пользователя, которого указал злоумешленник (при этом он ещё даже никак не авторизовался в системе)
то есть вся "улучшенная защита" строится на том, что пользователь вводит свой логин, а не чужой, что по-моему очень наивно.
Ооо это реально так??
Тогда да, смешно. Получается можно заставить его менять uid на самых разных пользователей в системе (еще небось из-за тайминга или чего-либо еще это использовать как утечку для понимания, какие пользователи существуют, а какие нет?)
Для понимания "какие пользователи существуют" достаточно грепнуть /etc/passwd, который всегда world readable.
> Для понимания "какие пользователи существуют" достаточно грепнуть /etc/passwd, который
> всегда world readable.Речь про получение этого удаленно, не имея аккаунта.
Как ты запустишь из-под себя процесс под uid другого пользователя без поднятия своих прав до рута? А когда у тебя уже рут, то какая разница что там будет.
дак вот тут и предлагают - надо попробовать авторизаваться под любым другим пользователем, при этом автоматом запустится процесс проверки пароля - так как пароль хранится в файле доступным только этому другому пользователю, то и права у процесса его будут. А дальше нам нужна лишь уязвимость в этом процессе, для эксплуатации.
В классике этот процесс запускался от рута чтобы прочитать шадоу пароли, тут - от указанного, но кто мешает указать того же рута?
То есть отличий в безопасности - ноль - и то и то можно запустить от рута. Остается лишь надеятся на отсутствие дыр.
Да, при аутентификации произвольного пользователя tcb не помогает. Он помогает при повторной аутентификации уже зашедшего в систему пользователя - команда passwd(1), вспомогательные утилиты *chkpwd при разблокировке сеанса, например, в X или screen. В Owl, благодаря в том числе tcb нам удалось полностью избавиться от SUID root программ в системе.
> Owl, благодаря в том числе tcb нам удалось полностью избавиться от
> SUID root программ в системе.А как с пингами решили? От обычного пользователя не попинговать?
> А как с пингами решили?Добавили поддержку ограниченных ICMP сокетов в ядро. В upstream, как я помню, начиная с Linux 3.0: https://lwn.net/Articles/420799/ Теперь живет там своей жизнью: https://cregit.linuxsources.org/code/5.10/net/ipv4/ping.c.html
К сожалению, с этим вышло нехорошо. Исходно у нас для ping заменялся SUID root на SGID _icmp, что делало новый код в ядре доступным только этой группе, то есть мы добавляли дополнительный уровень безопасности. Нам удалось отстоять сохранение ограничения наших ICMP сокетов по диапазону групп (настраивается через sysctl) и их недоступность не-root'у по умолчанию при включении в upstream (исходно нас просили эту защиту выкинуть). Но (как минимум) в Android этот sysctl выставили так, что новая функциональность стала доступна всем. (Наверное, у них были на то свои основания.) А при переносе кода с интерфейсов ядра 2.4.32 (под который эти сокеты исходно реализовал участник нашей команды) на 2.6+ (другим участником нашей команды, то есть наша ответственность), к сожалению, были привнесены ошибки. Конечно, теперь известные ошибки исправлены. Вот конец треда на эту тему, с целью учиться на ошибках: https://www.openwall.com/lists/oss-security/2017/03/25/1
Теперь кроме нашего патченного ping'а, насколько я знаю эти сокеты также использует QEMU (чтобы можно было ping'ать из VM не запуская сам QEMU под root) и, видимо, приложения под Android.
Кстати, traceroute (его классический "протокол") реализуем без root'а уже начиная с Linux 2.4, и с тех же времен есть реализация от Olaf Kirch, это умеющая, которой мы и пользуемся. А другие дистрибутивы что-то не спешат.
да, можно перебирать пользователей - но это проще обнаружить чем скаченый весь shadow - в котором подбирать пароль будет проще - кто-нибудь да лажанется.плюс прога passwd - без suid
> но кто мешает указать того же рута?Например, настройки системы, запрещающие логин рута? Остаётся только sudo, но для этого надо уже иметь какой-то вход.
PAM и NSS модули?
Написано же для системные пользователи в отдельной группе с нужными правами
>> параметры сохраняются в файле /etc/tcb/user/shadow, где каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---" , а /etc/tcb/user/ user:auth "drwx--s---" и /etc/tcb/user/shadow - user:auth "-rw-r-----").У группы auth есть доступ только на чтение.
> Ключевым отличием tcb от /etc/shadow является уход от использования общего файла со всеми хэшами паролей в пользу разнесения хэшей паролей по отдельным каталогам и файлам.для этого понадобилось 10 лет?
> Из улучшений в выпуске tcb 1.2 отмечается поддержка libxcrypt и новых версий Glibcновых 2010-2021?
> для этого понадобилось 10 лет?Очень скоро, уже в этом столетии, разработчики откроют для себя возможность хранения данных в базах этих самых данных.
Использовать клиент-серверную СУБД для хранения паролей локалхоста нерационально. Использовать что-то, типа SQLite - проблема будет та же, что и с /etc/shadow.
А что, в макоси так и сделано. И, в принципе, это рационально в плане масштабируемости: один и тот же механизм используется и для локальной, и для удалённой аутентификации.
> Очень скоро, уже в этом столетии, разработчики откроют для себя возможность хранения данных в базах этих самых данных.Представьте себе, файл /etc/shadow - тоже "база этих самых данных". Сюрприз, да? Или Вы считаете базами данных только реляционные с поддержкой SQL? Спешу Вас разочаровать, мир баз данных огромен и разнообразен и уж никак не ограничивается реляционными. И не всегда структура обрабатываемых данных хорошо "ложится" на реляционную модель. Извратиться, конечно, можно по всякому, но зачем, если есть другие виды баз данных, которые могут более соответствовать особенностям обрабатываемых данных. Да что я Вам лекцию читаю, собственно...
Ненене! База данных - это чтобы обязательно в файлах на диске хранилась каша, в которой невозможно ничего прочесть ни текстовым, ни hex редактором, а только с помощью запроса через специальную программу.
И чтобы эта каша обязательно превращалась в тыкву при малейшем сбое.
Твой /etc/shadow станет полной тыквой при одном бэд секторе под ним. И ничем тебе его текстовость не поможет.
Много что станет, и что?? Вам поименно перечислить файлы, бэд сектор в которых не даст системе загрузится для входа в нее? Боюсь пальцев не хватит.Рейд, бэкапы, вот это все, не? А еще какая там вероятность что бэд сектор упадет именно на shadow? Ну и наконец, тссссс! "/etc/shadow-"
Отличная причина сменить пароли.
текстовый редактор, hex редактор - тоже специальные программы (:
> Представьте себе, файл /etc/shadow - тоже "база этих самых данных". Сюрприз, да?Ну ты прям глаза мне раскрыл.
> Или Вы считаете базами данных только реляционные с поддержкой SQL? Спешу Вас разочаровать, мир баз данных огромен и разнообразен и уж никак не ограничивается реляционными.
Кроме поддержки SQL некоторые СУБД предоставляют гарантии консистентности данных, транзакционный доступ, бэкапы, представления (view), управление доступом к данным и т.д.
> И не всегда структура обрабатываемых данных хорошо "ложится" на реляционную модель.
На реляционную модель ложится всё.
> откроют для себя возможность хранения данных в базах этих самых данных.MS еще в прошлом веке вроде открыл. AD это называется. И говорят что их недавно через все это классно поадминили - на всю компанию.
Так что бойтесь своих желаний... представляете себе чего получается когда хакер до сервера с этой бд дорывается? Правильно - SUPERGOD MODE. По всей компании. Можно зобанить админов, перехватить ВСЕ компьютеры, а потом поржать представляя как админы ЭТО будут пытаться чинить.
AD всего лишь проприетарный LDAP с расширениями. Зато пд юниксами этих ваших directory service было столько, что считать устанешь. И все несовместимые.
> для этого понадобилось 10 лет?Нет, это было в первой же версии в 2001 году. Именно потому что всё главное уже было, а багов почти не было, и не требовались частые выпуски новых версий.
> новых 2010-2021?
Нет, новых это начиная с версии 2.26, выпущенной в августе 2017, в случае сборки glibc без опции --enable-obsolete-nsl. В tcb в ALT это исправили в 2018 (выкинув поддержку NIS/NIS+ вслед за аналогичным изменением в glibc). Теперь мы наконец добрались сделать релиз на случай переиспользования tcb где-либо еще, что начиная с 2018 же стало проще и актуальнее благодаря libxcrypt.
Был не прав, прошу прощения, и благодарю за развёрнутый и внятный ответ.
Сомнительно, у пользователя не должно быть прав на запись в системные каталоги. А blowfish вроде старенький, уже лет 15 как считается совсем не секурным.
Хотя по поводу blowfish я в курсе что там только недавно от md5 (md4) отошли, лучше посмотреть на luks с его argon2.
Что тут еще за эксперты в крипто? А какие собственно атаки известны на blowfish? Он не рекомендуется к использованию - но в основном из-за тайминг атак и того факта что сам по себе он относительно тормозной. Современное крипто просто использует другие подходы, типа ARX от DJB, не завязаное на массивы/sbox (у которых проблемы с кэшом vs тайминги). Но этот класс атак имеет ограниченную применимость.
Кто-то и 3des до последнего использовал. И md4 хватит всем для паролей. Зависимость от васянокриптолибы тоже такое. Почему нельзя взять что-то надёжное и доверенное?
> Сомнительно, у пользователя не должно быть прав на запись в системные каталоги.Их и нету. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---".
> А blowfish вроде старенький, уже лет 15 как считается совсем не секурным.
1. Не путайте блочный шифр Blowfish и парольный хеш bcrypt на его основе. У них совсем разные свойства. В данном контексте, речь о bcrypt.
2. Конечно, и Blowfish и bcrypt старенькие, но с ними в целом всё в порядке. Основной недостаток Blowfish как шифра в маленьком размере блока (64 бита) - см. https://sweet32.info и https://blog.cryptographyengineering.com/2016/08/24/attack-o.../ - это 2016 год. К bcrypt этот недостаток отношения не имеет.
3. tcb никак на bcrypt не завязан, он лишь использует универсальный API, который мы первоначально реализовали в crypt_blowfish (реализации bcrypt). Теперь этот API доступен в libxcrypt и позволяет tcb использовать любой из поддерживаемых в libxcrypt парольных хешей, в том числе наш yescrypt.
А разве blowfish не использует массивы для пермутации? И если да - у этого на процессорах с кэшом заведомо есть проблемы с тайминг атаками. Сам автор его не советует.
Насчет cache timing, да, есть такое. Вот только в bcrypt эта же особенность существенно повышает стоимость offline атак на хеши, так что получается своеобразный security vs. security trade-off. Реально пока что cache timing атаки in the wild не встретишь (потому что не практично), а вот offline атаки на хеши - везде, как только хеши утекут. Аналогичный trade-off присутствует и для более современных схем хеширования паролей - например, из-за него существуют Argon 2i, 2d, и 2id - разный баланс между cache timing safety и защитой от offline атак.
Сомнительное нововведение. Если в случае /etc/shadow юзер не имеет доступа к своему паролю и может его только вводить или менять, с tcb первый попавшийся троян унесёт хеш пароля в свой ботнет.
Иерархия /etc/tcb доступна на чтение только группе shadow. Что бы поменять или посмотреть пароль пользователь должен как-то войти в группу shadow или запустить утилиту которая сделает setgid. В этом плане всё почти также, как с обычным /etc/shadow, но с защитой от дыр в утилитах и библиотеках.
/etc/tcb/user/ и /etc/tcb/user/shadow - -rw-r----- user:auth
Внутрь /etc/tcb вас не пустит без группы shadow.
Да, пропустил этот момент
Да это бред.
Чтобы запустить процесс от имени user:shadow все равно нужны манипуляции от рута.
Как же тогда "привилегии не повышаются"?
бинарь с sgid shadow, не рут
В /etc/tcb не пустит, а в /etc/tcb/$USERNAME/ пустит.
Нет, и в /etc/tcb/$USERNAME/ тоже не пустит.
Как без NIS-то?Я пользовался.
именно НИС? yp?
ну теперь не будет и хорошо)
Файл shadow от обычного пользователя прочитать невозможно. То есть теперь любая прогамма сможет узнать пароль текущего пользователя?
Нет. Нужен ещё баг или плохая настройка, которая даст пользователю права группы shadow. Но и в этом случае, унести можно будет хэш только текущего пользователя.
То есть теперь любая программа получает доступ к файлу пароля текущего пользователя и может его изменить?
> То есть теперь любая программа получает доступ к файлу пароля текущего пользователя
> и может его изменить?Нет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого.
Что-то список на https://repology.org/project/tcb/versions напоминает мне список живых детей Mandrake просто. То есть оно и в Альте, и в Магеи и в прочих PCLinuxOS. То есть это не альтовая идея его заюзать, а скорее всего унаследовано в давние годы из Mandrake еще.
По ссылкам не ходим принципиально?>> After 10 years since the previous release, we've just released version
>> 1.2 of tcb, the alternative password shadowing scheme we had introduced
>> in Owl. tcb is currently in use in ALT Linux distributions and Mageia.
Ты прочитало, что я написал? Дело не в Альте. Оно и в Магеи, и в PCLinuxOS, и в Rosa.
Все перечисленное это дети MandrakeОно во всех живых ныне детишках и внучишках Mandrake Linux. Так что есть основание считать, что оно было там, потому и в наследничках живет
Или ты не знало, что Alt форкался от Mandrake?
Это логичная теория, но она ошибочна. tcb в Owl и ALT с 2001, а в Mandriva с 2009.
Забавно.
Но реально выглядит так, словно из Мандрейка пришло
Просто большинство местных детишек и не знают, и не помнят, что Альт вырос из Мандрейка, единицы тут тех кто те времена застал.Но ок, верю, что смешное сов падение
Наличие в репозитории ROSA не означает, что он используется по умолчанию, по умолчанию он не используется очень давно: http://lists.rosalab.ru/pipermail/rosa-devel/2013-March/0045...
А в Mandriva появился в 2009: https://annvix.com/blog/mandriva-linux-20090-released-today
В Росу был просто унаследован.
Походу угнали tcb, давайте доверяйте пароли
получается файл с паролем можно будет переписать незаметно для пользователя и залогинится на его тачку?
> переписать незаметно для пользователя и залогинится на его тачку?Для этого всё и делается. То в системде появятся носимые пароли на флэшке, то вот это чудо...
> получается файл с паролем можно будет переписать незаметно для пользователяНет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого.
> в Openwall GNU/*/Linux, ALT Linux и Mageia.Г-н(не подумайте плохого) Ши - мои поздравления! Альт откинул конкурентов, таких как Роса и Астра далеко и надолго.
Но вот вопрос - лицензия BSD, а то что это используется в самих BSD ну ни слова. И в Linux потащили эту же лицензию. Как то не по GPL-ному это?
> Но вот вопрос - лицензия BSD, а то что это используется в самих BSD ну ни слова.BSDшники уже в курсе, чем пользуются? Или очередная инсайдерская опеннетная инфа?
Эээ... а я-то тут при чём, разве что как юзер? Глянул авторов коммитов в альтовом tcb.git -- сплошь команда Openwall, включая ldv@altlinux. :-)А схема и впрямь элегантная; и ещё поражён тем, как Александр терпеливо делает "зри в /etc/tcb" за такое множество сходу рванувших низлагать.
PS: кто не видел http://altlinux.org/control -- гляньте; перекликается именно по красоте и простоте, ну и полезности для простого сисадмина. /etc/control.d/functions -- чуть больше четырёх килобайт. (PPS: и это тоже Owl/ALT)
Важным свойством control является то, что установленные настройки сохраняются при обновлении пакетов.
> /etc/tcb/user/shadow - user:auth "-rw-r-----"Выходит с tcb любой процесс пользователя может сменить его пароль, даже JS скрипт с бровзера. ;) И пользователь следующий раз в систему не зайдет :))))
А с нашим /etc/shadow только через утилиту passwd, но с привелегиями...
> Выходит с tcb любой процесс пользователя может сменить его пароль, даже JS скрипт с бровзера. ;) И пользователь следующий раз в систему не зайдет :))))Пользователь Вася не зайдет в свою систему, зато крекер Вова, сменивший пароль посредством вирусного JS скрипта который исполнился в бровзере, сразу получает удаленный доступ к аккаунту Васи с известным Вове паролем!
Нет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого. Также, JavaScript в браузере не имеет прямого доступа к файлам пользователя.
Не занимайся ерундой. Человек не способный прочитать текст новости твой комментарий читать не будет.
> JavaScript в браузере не имеет прямого доступа к файлам пользователя.Не совсем верно, были баги когда таки имел. А там еще модное апи какое-то для доступа в ФС, так что новых багов для кражи файлов эти вебвредители явно добавят. В этом месте глухой permission deined для пользователя по поводу даже чтения /etc/shadow - фича.
А читануть хэш пароля и вгрузить его в кластер GPU атакующий таким макаром сможет? И хрен с ней с заменой тогда.
> В этом месте глухой permission deined для пользователя по поводу даже чтения /etc/shadow - фича.Эта фича сохраняется и при использовании /etc/tcb.
> ограничившись их повышением до группы shadow) при запуске утилиты passwd. Например, параметры сохраняются в файле /etc/tcb/user/shadow, где каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---"Надо смотреть реализацию, действительноли у пользователей нет по умолчанию группы shadow, и пользователь получает группу shadow только после ввода старого пароля, и только на процесс passwd.
grep shadow /etc/group
grep shadow /etc/gshadow
newgrp shadow
newgrp - shadow
...А какие права у вас на
ls -l /bin/passwd
ls -l /usr/bin/newgrpИ вывод команды groups:
groups
passwd меняем пароль
groups
> Надо смотреть реализацию, действительноли у пользователей нет по умолчанию
> группы shadowМожно, конечно, и её давать при заведении -- но это уж расстараться надо.
> и пользователь получает группу shadow только после ввода старого пароля,
> и только на процесс passwd. [...] А какие права у вас на
> ls -l /bin/passwd
> ls -l /usr/bin/newgrp
$ ls -l /usr/bin/{passwd,newgrp}
-rwx------ 1 root root 98792 сен 22 10:54 /usr/bin/newgrp
-rwx--s--x 1 root shadow 18472 мар 29 2019 /usr/bin/passwd
# control passwd
tcb
# control newgrp
restricted> И вывод команды groups:
> groups
> passwd меняем пароль
> groupsОчевидно, тот же, если список групп не изменялся параллельно чем-либо ещё.
Вы же правда различаете _инициализацию_ его при порождении процесса и _изменение_ во время его жизни? :)
>Очевидно, тот же, если список групп не изменялся параллельно чем-либо ещё.
> Вы же правда различаете _инициализацию_ его при порождении процесса и _изменение_ во время его жизни? :)Не очевидно, откуда мне было знать вашу реализацию повышения привилегий до группы shadow при выполнении passwd?
Ваш вариант принят:
-rwx--s--x 1 root shadow 18472 мар 29 2019 /usr/bin/passwdНо я честно подумал сначала о другом варианте, повышение привилегий как в newgrp, только после ввода старого пароля пользователя (и реализация могла сохранять права после завершения работы passwd), тогда passwd должен иметь s-бит на пользователя root. Ваш вариант требует s-бит на группу shadow и следовательно выглядит привлекательней.
Тень от пароля это как рисунок ключа?
Лучше не доверять, компания, которая срослась госвластью и заказами
>>из команды ALT Linux
Всегда оценивайте труд по личности, а не результату. И судите о безопасности механизмов тоже не по устройству этих механизмов, а по тому, кто их сделал.P.S. Ой, оказывается, Дмитрий Левин был релиз менеджером glibc 2.27
https://sourceware.org/glibc/wiki/Release/2.27
P.P.S. И ещё он мантейнер strace:
> Всегда оценивайте труд по личности, а не результату.https://www.opennet.me/~Led - наслаждайтесь. Это он. Оказывается, можно быть трамвайнейшим из хамов и при этом релиз менеджером glibc.
Led точно ldv?
led@ -- ядерщик, который за болтунов языком, которым от него нередко прилетает едкостей, исправил как минимум один дедлок: http://bugzilla.kernel.org/show_bug.cgi?id=15658Ну и да, найдите минимум два различия:
led
ldv
Ага, спасибо.
> по тому, кто их сделал.Это важно - а вдруг какой баг, или фичи не хватает, или еще чего? Довольно некстати если с той стороны экрана окажется людоед, взаимодействие не доставит радости. За особо вонючими, типа Drepper-а, половина дистров форкала вообще. Кстати вот этот самый glibc. "Везет" ему с хамьем в майнтайнерах, увы.
Вы вряд ли когда-либо являлись майнтейнером glibc, не смешите.
>>Openwall GNU/*/LinuxСколько не копался в исходниках и пакетах, так и не нашёл...
Не нашел чего в чем?
> The source code of the tcb suite can be browsed via CVSwebОхренеть, лич-король собственной персоной. Мешок костей!
Кстати, в ALT tcb уже давно в git https://packages.altlinux.org/en/sisyphus/srpms/tcb/gears/repos включая upstream-ветку http://git.altlinux.org/people/ldv/packages/tcb.git?p=tcb.gi...
Сам же upstream проект в CVS исторически (git'а еще не было), но тоже переезжает на git вместе с рядом других.
Граждане! Храните аккаунты в сберегательном лдапе! Если, конечно, он у вас есть. )
Пора выйти из shadow - время хранить пароли. (тм)
В HP-UX 11.31/11.23 у нас оно использовалось, всегда думал, что это чисто особенность HP-UX.
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://altlinux.org/tcb со ссылкой на Ваш комментарий.
Зачем?
Для снижения опасности возможных уязвимостей в passwd(1), chage(1) и программах (раз)блокировки текущего сеанса по паролю, а также используемом ими специфичном системном коде (PAM). Также, если в дистрибутиве удалось избавиться и от остальных общедоступных SUID root программ (как удалось нам), для снижения опасности возможных уявзимостей в низкоуровневом системном коде, используемом при запуске программ (некоторые части динамического линкера, libc, ядра - во всех из которых исторически бывали уязвимости).
Слишком много сказочных фраз, а по сути будет пердёж на месте с новыми дырами.