LINUX.ORG.RU

Безопасность связки ключей и хранение паролей в Linux-ах...

 gnome-keyring-daemon, ,


2

1

Впервые задумался об этом, но ведь пароли у многого прикладного ПО лежат в seahorse и его аналогах которые под капотом используют gnome-keyring-daemon и его аналоги в других DE. После того как юзер включает браузер/pgadmin или какой-то другой софт, который хранит там пароли, то всё хранилище ключей становится доступным любому процессу, работающему от пользователя через dbus. Таким образом, простейший скрипт, запущенный от юзера спокойно прочитает и расшифрует любые ключи. Например, для хромого можно штатными средствами вытащить мастер ключ (чтоб не городить огорода с dbus и убедиться что это правда, можно воспользоваться готовым софтом из репы, например secret-tool lookup application chrome). Вернётся мастер ключ, которым хром уже шифрует свои ключи… Зная алгоритм и секретный ключ которым хромой расшифровывает свои ключи, можно их легко вытащить. Т.е. любой вредоносный код, имея только права пользователя спокойно уведёт все ключи у всего прикладного софта в тот момент, когда пользователь разблокирует связку ключей для любой программы. Всё это напомнило мне театр безопасности и дыру невероятных масштабов. Есть ли какие-то способы бороться с этим ужасом? Кроме как не хранить вообще никаких паролей в софте на Linux.

★★★★★

Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

Опенсорс тем же болеет, потому что хочется быстрее получить готовый продукт для удовлетворения от проделанной задачи.

Да ладно. Если имеется ввиду прога которую ты сам пилишь, для души, и выкладываешь на гитхаб то ты ее можешь всю жизнь переделывать.

Или вы про ядро линукс?

anonymous
()
Ответ на: комментарий от anonymous

Да ладно. Если имеется ввиду прога которую ты сам пилишь, для души, и выкладываешь на гитхаб то ты ее можешь всю жизнь переделывать.

У многих удовлетворение именно от того что софт готов и им пользуются.

peregrine ★★★★★
() автор топика
Ответ на: комментарий от peregrine

Не совсем. ld-linux.so отвечает за всё под капотом. Он вроде как и не ядро но и не совсем glibc. Прослойка.

Исходники от него лежат в проекте glibc. Если хочешь использовать другую libc вроде musl или bionic, там будет свой загрузчик. Так что на мой взгляд в контексте линукса это таки однозначно часть libc. Причём, насколько я понимаю, это не просто так, загрузчик очень тесно связан с внутренностями libc (TLS, всякие специальные функции-конструкторы).

Более того, в musl загрузчик и libc это буквально один файл:

/ # ls -la /lib/l*
-rwxr-xr-x    1 root     root        670312 Apr 11 09:33 /lib/ld-musl-x86_64.so.1
lrwxrwxrwx    1 root     root            19 Jun 13 16:38 /lib/libc.musl-x86_64.so.1 -> ld-musl-x86_64.so.1

Чисто теоретически можно было бы создать какой-то «стандартный протокол» между загрузчиком и libc и разделить эти проекты, сделав оба компонента заменяемыми. Но вряд ли это случится.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

Чисто теоретически есть стандарт где он не прописан, но его суют в glibc, т.к. куда-то надо. Да маловероятно, что что-то изменится в лучшую сторону в ИБ в линуксах (если не будет массовой кражи паролей и большого-большого скандала). Может только ИИ потом перепишет как надо.

peregrine ★★★★★
() автор топика
Последнее исправление: peregrine (всего исправлений: 1)

Таким образом, простейший скрипт, запущенный от юзера спокойно прочитает и расшифрует любые ключи.

Да, а так же этот же скрипт имеет доступ ко всем твоим настройкам, паролям в браузере и т.д. и т.п.

Какое следующее для тебя откровение? Что сертификаты в https такая же филькина грамота? :-)))

vtVitus ★★★★★
()

Есть ли какие-то способы бороться с этим ужасом?

SELinux.

anonymous
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария