|
|
|
4.112, VITAlya (?), 22:23, 29/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
ХАХАХА, вы расскажите тогда что они в дистрибутивах по умолчанию делают тогда? ИЛИ У МЕНЯ ДИСТРИБУТИВ ЗАВЕДОМО ПОДМЕНЕН?
| |
|
|
|
1.3, dimcha (??), 12:41, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
> Обработчик /etc/shadow всегда получает доступ сразу ко всем хэшам паролей
а tcb не имеет такой возможности совсем? Как он будет проверять хэши тогда при логине?
| |
|
|
|
Часть нити удалена модератором |
4.46, Анонимный Аноним (?), 17:32, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
> Ну так что мешает сказать что хочу пароль рута
Сказать-то ничего не мешает, а вот получить - мешают недостаточные права доступа к файлу с паролем рута. У процесса (если не от рута проверка, есс-но) есть доступ только к своему файлу со своим же паролем на уровне тупо файловой системы. Хош - меняй, хош - проверяй. Но только свой.
| |
|
5.81, aa (?), 07:42, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
процесс запускается с правами пользователя, которого указал злоумешленник (при этом он ещё даже никак не авторизовался в системе)
то есть вся "улучшенная защита" строится на том, что пользователь вводит свой логин, а не чужой, что по-моему очень наивно.
| |
|
6.83, Анонимленьлогиниться (?), 11:09, 13/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
Ооо это реально так??
Тогда да, смешно. Получается можно заставить его менять uid на самых разных пользователей в системе (еще небось из-за тайминга или чего-либо еще это использовать как утечку для понимания, какие пользователи существуют, а какие нет?)
| |
|
7.91, Аноним (91), 12:50, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Для понимания "какие пользователи существуют" достаточно грепнуть /etc/passwd, который всегда world readable.
| |
|
6.92, Аноним (92), 12:53, 13/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
Как ты запустишь из-под себя процесс под uid другого пользователя без поднятия своих прав до рута? А когда у тебя уже рут, то какая разница что там будет.
| |
|
7.94, aa (?), 14:39, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
дак вот тут и предлагают - надо попробовать авторизаваться под любым другим пользователем, при этом автоматом запустится процесс проверки пароля - так как пароль хранится в файле доступным только этому другому пользователю, то и права у процесса его будут. А дальше нам нужна лишь уязвимость в этом процессе, для эксплуатации.
В классике этот процесс запускался от рута чтобы прочитать шадоу пароли, тут - от указанного, но кто мешает указать того же рута?
То есть отличий в безопасности - ноль - и то и то можно запустить от рута. Остается лишь надеятся на отсутствие дыр.
| |
|
|
|
|
|
2.27, Аноним (27), 14:43, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
>> параметры сохраняются в файле /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 есть доступ только на чтение.
| |
|
1.4, Гимли (?), 12:41, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –7 +/– |
> Ключевым отличием tcb от /etc/shadow является уход от использования общего файла со всеми хэшами паролей в пользу разнесения хэшей паролей по отдельным каталогам и файлам.
для этого понадобилось 10 лет?
> Из улучшений в выпуске tcb 1.2 отмечается поддержка libxcrypt и новых версий Glibc
новых 2010-2021?
| |
|
2.10, x3who (?), 12:53, 12/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –9 +/– |
> для этого понадобилось 10 лет?
Очень скоро, уже в этом столетии, разработчики откроют для себя возможность хранения данных в базах этих самых данных.
| |
|
3.23, Аноним (23), 14:28, 12/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– |
Использовать клиент-серверную СУБД для хранения паролей локалхоста нерационально. Использовать что-то, типа SQLite - проблема будет та же, что и с /etc/shadow.
| |
|
4.28, Аноним (27), 14:45, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –3 +/– |
А что, в макоси так и сделано. И, в принципе, это рационально в плане масштабируемости: один и тот же механизм используется и для локальной, и для удалённой аутентификации.
| |
|
3.52, Анонимный Аноним (?), 18:08, 12/01/2021 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +3 +/– |
> Очень скоро, уже в этом столетии, разработчики откроют для себя возможность хранения данных в базах этих самых данных.
Представьте себе, файл /etc/shadow - тоже "база этих самых данных". Сюрприз, да? Или Вы считаете базами данных только реляционные с поддержкой SQL? Спешу Вас разочаровать, мир баз данных огромен и разнообразен и уж никак не ограничивается реляционными. И не всегда структура обрабатываемых данных хорошо "ложится" на реляционную модель. Извратиться, конечно, можно по всякому, но зачем, если есть другие виды баз данных, которые могут более соответствовать особенностям обрабатываемых данных. Да что я Вам лекцию читаю, собственно...
| |
|
4.55, YetAnotherOnanym (ok), 19:51, 12/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +4 +/– |
Ненене! База данных - это чтобы обязательно в файлах на диске хранилась каша, в которой невозможно ничего прочесть ни текстовым, ни hex редактором, а только с помощью запроса через специальную программу.
И чтобы эта каша обязательно превращалась в тыкву при малейшем сбое.
| |
|
5.70, Аноним (-), 01:48, 13/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –3 +/– |
Твой /etc/shadow станет полной тыквой при одном бэд секторе под ним. И ничем тебе его текстовость не поможет.
| |
|
6.84, Анонимленьлогиниться (?), 11:14, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
Много что станет, и что?? Вам поименно перечислить файлы, бэд сектор в которых не даст системе загрузится для входа в нее? Боюсь пальцев не хватит.
Рейд, бэкапы, вот это все, не? А еще какая там вероятность что бэд сектор упадет именно на shadow? Ну и наконец, тссссс! "/etc/shadow-"
| |
|
|
4.110, x3who (?), 14:41, 17/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> Представьте себе, файл /etc/shadow - тоже "база этих самых данных". Сюрприз, да?
Ну ты прям глаза мне раскрыл.
> Или Вы считаете базами данных только реляционные с поддержкой SQL? Спешу Вас разочаровать, мир баз данных огромен и разнообразен и уж никак не ограничивается реляционными.
Кроме поддержки SQL некоторые СУБД предоставляют гарантии консистентности данных, транзакционный доступ, бэкапы, представления (view), управление доступом к данным и т.д.
> И не всегда структура обрабатываемых данных хорошо "ложится" на реляционную модель.
На реляционную модель ложится всё.
| |
|
3.69, Аноним (-), 01:46, 13/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> откроют для себя возможность хранения данных в базах этих самых данных.
MS еще в прошлом веке вроде открыл. AD это называется. И говорят что их недавно через все это классно поадминили - на всю компанию.
Так что бойтесь своих желаний... представляете себе чего получается когда хакер до сервера с этой бд дорывается? Правильно - SUPERGOD MODE. По всей компании. Можно зобанить админов, перехватить ВСЕ компьютеры, а потом поржать представляя как админы ЭТО будут пытаться чинить.
| |
|
4.82, Аноним (82), 10:04, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
AD всего лишь проприетарный LDAP с расширениями. Зато пд юниксами этих ваших directory service было столько, что считать устанешь. И все несовместимые.
| |
|
|
2.38, solardiz (ok), 16:58, 12/01/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +6 +/– |
> для этого понадобилось 10 лет?
Нет, это было в первой же версии в 2001 году. Именно потому что всё главное уже было, а багов почти не было, и не требовались частые выпуски новых версий.
> новых 2010-2021?
Нет, новых это начиная с версии 2.26, выпущенной в августе 2017, в случае сборки glibc без опции --enable-obsolete-nsl. В tcb в ALT это исправили в 2018 (выкинув поддержку NIS/NIS+ вслед за аналогичным изменением в glibc). Теперь мы наконец добрались сделать релиз на случай переиспользования tcb где-либо еще, что начиная с 2018 же стало проще и актуальнее благодаря libxcrypt.
| |
|
1.5, Аноним (5), 12:48, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –4 +/– |
Сомнительно, у пользователя не должно быть прав на запись в системные каталоги. А blowfish вроде старенький, уже лет 15 как считается совсем не секурным.
| |
|
2.8, Аноним (5), 12:50, 12/01/2021 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –2 +/– |
Хотя по поводу blowfish я в курсе что там только недавно от md5 (md4) отошли, лучше посмотреть на luks с его argon2.
| |
|
3.66, Аноним (-), 01:39, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Что тут еще за эксперты в крипто? А какие собственно атаки известны на blowfish? Он не рекомендуется к использованию - но в основном из-за тайминг атак и того факта что сам по себе он относительно тормозной. Современное крипто просто использует другие подходы, типа ARX от DJB, не завязаное на массивы/sbox (у которых проблемы с кэшом vs тайминги). Но этот класс атак имеет ограниченную применимость.
| |
|
4.71, Аноним (5), 02:20, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Кто-то и 3des до последнего использовал. И md4 хватит всем для паролей. Зависимость от васянокриптолибы тоже такое. Почему нельзя взять что-то надёжное и доверенное?
| |
|
|
|
3.67, Аноним (-), 01:42, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
А разве blowfish не использует массивы для пермутации? И если да - у этого на процессорах с кэшом заведомо есть проблемы с тайминг атаками. Сам автор его не советует.
| |
|
4.72, solardiz (ok), 02:20, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Насчет 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 атак.
| |
|
|
|
1.6, x3who (?), 12:48, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –5 +/– |
Сомнительное нововведение. Если в случае /etc/shadow юзер не имеет доступа к своему паролю и может его только вводить или менять, с tcb первый попавшийся троян унесёт хеш пароля в свой ботнет.
| |
|
2.11, Аноним (11), 12:56, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Иерархия /etc/tcb доступна на чтение только группе shadow. Что бы поменять или посмотреть пароль пользователь должен как-то войти в группу shadow или запустить утилиту которая сделает setgid. В этом плане всё почти также, как с обычным /etc/shadow, но с защитой от дыр в утилитах и библиотеках.
| |
|
|
|
|
6.36, gogo (?), 16:55, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
Да это бред.
Чтобы запустить процесс от имени user:shadow все равно нужны манипуляции от рута.
Как же тогда "привилегии не повышаются"?
| |
|
|
|
|
|
1.14, Корец (?), 13:13, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –2 +/– |
Файл shadow от обычного пользователя прочитать невозможно. То есть теперь любая прогамма сможет узнать пароль текущего пользователя?
| |
|
2.22, pda (?), 14:11, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Нет. Нужен ещё баг или плохая настройка, которая даст пользователю права группы shadow. Но и в этом случае, унести можно будет хэш только текущего пользователя.
| |
|
|
2.48, solardiz (ok), 17:34, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
> То есть теперь любая программа получает доступ к файлу пароля текущего пользователя
> и может его изменить?
Нет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого.
| |
|
|
2.29, Аноним (27), 14:51, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
По ссылкам не ходим принципиально?
>> 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. | |
|
3.34, flkghdfgklh (?), 16:21, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Ты прочитало, что я написал? Дело не в Альте. Оно и в Магеи, и в PCLinuxOS, и в Rosa.
Все перечисленное это дети Mandrake
Оно во всех живых ныне детишках и внучишках Mandrake Linux. Так что есть основание считать, что оно было там, потому и в наследничках живет
Или ты не знало, что Alt форкался от Mandrake?
| |
|
|
5.51, flkghdfgklh (?), 18:04, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Забавно.
Но реально выглядит так, словно из Мандрейка пришло
Просто большинство местных детишек и не знают, и не помнят, что Альт вырос из Мандрейка, единицы тут тех кто те времена застал.
Но ок, верю, что смешное сов падение
| |
|
|
|
|
|
2.32, Аноним (32), 15:37, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
> переписать незаметно для пользователя и залогинится на его тачку?
Для этого всё и делается. То в системде появятся носимые пароли на флэшке, то вот это чудо...
| |
2.47, solardiz (ok), 17:33, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
> получается файл с паролем можно будет переписать незаметно для пользователя
Нет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого.
| |
|
1.31, Аноним (-), 15:05, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –4 +/– |
> в Openwall GNU/*/Linux, ALT Linux и Mageia.
Г-н(не подумайте плохого) Ши - мои поздравления! Альт откинул конкурентов, таких как Роса и Астра далеко и надолго.
Но вот вопрос - лицензия BSD, а то что это используется в самих BSD ну ни слова. И в Linux потащили эту же лицензию. Как то не по GPL-ному это?
| |
|
2.33, Аноним (33), 16:17, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Но вот вопрос - лицензия BSD, а то что это используется в самих BSD ну ни слова.
BSDшники уже в курсе, чем пользуются? Или очередная инсайдерская опеннетная инфа?
| |
2.78, Michael Shigorin (ok), 07:27, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Эээ... а я-то тут при чём, разве что как юзер? Глянул авторов коммитов в альтовом tcb.git -- сплошь команда Openwall, включая ldv@altlinux. :-)
А схема и впрямь элегантная; и ещё поражён тем, как Александр терпеливо делает "зри в /etc/tcb" за такое множество сходу рванувших низлагать.
PS: кто не видел http://altlinux.org/control -- гляньте; перекликается именно по красоте и простоте, ну и полезности для простого сисадмина. /etc/control.d/functions -- чуть больше четырёх килобайт. (PPS: и это тоже Owl/ALT)
| |
|
1.39, Аноним (39), 17:16, 12/01/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –4 +/– |
> /etc/tcb/user/shadow - user:auth "-rw-r-----"
Выходит с tcb любой процесс пользователя может сменить его пароль, даже JS скрипт с бровзера. ;) И пользователь следующий раз в систему не зайдет :))))
А с нашим /etc/shadow только через утилиту passwd, но с привелегиями...
| |
|
2.42, Аноним (39), 17:22, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –3 +/– |
> Выходит с tcb любой процесс пользователя может сменить его пароль, даже JS скрипт с бровзера. ;) И пользователь следующий раз в систему не зайдет :))))
Пользователь Вася не зайдет в свою систему, зато крекер Вова, сменивший пароль посредством вирусного JS скрипта который исполнился в бровзере, сразу получает удаленный доступ к аккаунту Васи с известным Вове паролем!
| |
|
3.45, solardiz (ok), 17:29, 12/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Нет. Из текста новости: каталог /etc/tcb принадлежит root:shadow и имеет права "drwx--x---". Пользователь не может поменять пароль не зная старого. Также, JavaScript в браузере не имеет прямого доступа к файлам пользователя.
| |
|
4.65, Аноним (-), 01:35, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> JavaScript в браузере не имеет прямого доступа к файлам пользователя.
Не совсем верно, были баги когда таки имел. А там еще модное апи какое-то для доступа в ФС, так что новых багов для кражи файлов эти вебвредители явно добавят. В этом месте глухой permission deined для пользователя по поводу даже чтения /etc/shadow - фича.
А читануть хэш пароля и вгрузить его в кластер GPU атакующий таким макаром сможет? И хрен с ней с заменой тогда.
| |
|
5.76, solardiz (ok), 02:37, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> В этом месте глухой permission deined для пользователя по поводу даже чтения /etc/shadow - фича.
Эта фича сохраняется и при использовании /etc/tcb.
| |
|
6.89, Аноним (89), 12:36, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> ограничившись их повышением до группы 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
| |
|
7.96, Michael Shigorin (ok), 14:52, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> Надо смотреть реализацию, действительноли у пользователей нет по умолчанию
> группы shadow
Можно, конечно, и её давать при заведении -- но это уж расстараться надо.
> и пользователь получает группу shadow только после ввода старого пароля,
> и только на процесс passwd. [...] А какие права у вас на
> ls -l /bin/passwd
> ls -l /usr/bin/newgrp
[CODE]$ 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[/CODE]
> И вывод команды groups:
> groups
> passwd меняем пароль
> groups
Очевидно, тот же, если список групп не изменялся параллельно чем-либо ещё.
Вы же правда различаете _инициализацию_ его при порождении процесса и _изменение_ во время его жизни? :)
| |
|
|
|
|
|
|
|
2.97, solardiz (ok), 15:14, 13/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
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 программ).
| |
|
|
2.108, solardiz (ok), 17:26, 16/01/2021 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Для снижения опасности возможных уязвимостей в passwd(1), chage(1) и программах (раз)блокировки текущего сеанса по паролю, а также используемом ими специфичном системном коде (PAM). Также, если в дистрибутиве удалось избавиться и от остальных общедоступных SUID root программ (как удалось нам), для снижения опасности возможных уявзимостей в низкоуровневом системном коде, используемом при запуске программ (некоторые части динамического линкера, libc, ядра - во всех из которых исторически бывали уязвимости).
| |
|
|