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

А как ты собственную базу защитишь? Защита должна от ядра идти, а не наоборот.

Вау, погуглил, Хром хранит пароли в базе, но база шифруется с мастер-паролем в GNOME Keyring (Libsecret) или KDE Wallet, а если DE легковесная то база вообще не шифруется. В Firefox либо шифруется с ключом на том же диске, а с местер-паролем шифруется собственным, то есть по факту без доступа от каких либо прог извне.

Это всё печально, но никак не отменяет мной ранее написанного.

В Firefox либо шифруется с ключом на том же диске

Это не шифрование, а кодирование по факту.

А как ты собственную базу защитишь? Защита должна от ядра идти, а не наоборот.

Если какая-то прога может взять мастер пароль для Хрома, то из Хрома надо её ещё достать. Движок то браузера может, но с чего он даст внешней проге залезть в браузер. Типа хром даёт апи внешним прогам бери что хочешь из меня? Вот прям мало вероятно. Я думаю даже плагин не сможет достать пароль, несмотря на то что он встроен в хром.

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

то из Хрома надо её ещё достать

А с этим какие-то трудности?

А с этим какие-то трудности?

Ну если создашь домен linux.org.ru и в нём сделаешь запрос логина пароля, но как я понимаю не сможешь создать второй домен с таким же именем. А если ты не сайт, то каким образом?

Credentials Manager

это старьё, в современном оффтопике есть более безопасные механизмы, вроде PasswordVault, Windows Hello API тоже фиксит эту проблему (но лучше бы его не было, т.к. это подозрительно похоже на кражу биометрии для ИИ и спецслужб).

Где я предлагал костыли? Я предлагал как раз не грузиться всякими связками ключей и давать доступ всем везде при логине. А для критически важных паролей - не сохранять их на комп (по крайней мере на комп общего назначения). С твоими «механизмами в ОС» их тоже нельзя сохранять на общий комп, так что в этом аспекте всё остаётся как было.

Атака про которую я говорю идёт не со стороны сайта. А со стороны процесса, работающего от того же пользователя, что и хром. Схема такая:

┌──────────────────────────┐ Запрос от валидного приложения
│ Связка ключей закрыта    │ например от хрома на разблокировку
│ никто не может получить  │ связки ключей
│ доступ к паролям         ╞═════════════════════════════════════╗
└──────────────────────────┘                                     ⇓
                                      ┌──────────────────────────┐
  Вредоносный код, запущенный от      │ Связка ключей открыта    │
  пользователя (скрипт, плагин,       │ Любой процесс от того    │
  заражённая библиотека с гитхаба     │ же пользователя может    │
  запрашивает ключ у хранилища)       │ читать любые пароли      │
 ╔════════════════════════════════════╡ любых приложений         │
 ⇓                                    └──────────────────────────┘
 ┌──────────────────────────┐
 │ Хранилище возвращает     │ Вредоносный код имея на руках
 │ мастер-ключ хрома,       │ мастер-ключ спокойно расшифровывает
 │ которым тот шифрует      │ базу данных хрома, т.к. алгоритмы
 │ ключи от сайтов в своей  │ не защищают если ключ известен, а
 │ базе данных лежащей в    │ сама база всё так же лежит в хомяке
 │ домашней папке           │ и передаёт их злоумышленнику
 │ пользователя             ╞═════════════════════════════════════╗
 └──────────────────────────┘                                     ⇓
 ┌────────────────────────────────────────────────────────────────┐
 | Злоумышленник, имея логины и пароли, заходит на сайт           |
 | https://www.linux.org.ru и пишет гадости, за что пользователь  |
 | получает бан, ибо нефиг доверять всяким gnome-keyring-daemon,  |
 | kdewallet и libsecret, которые только создают видимость        |
 | безопасности и обманывают как пользователя, так и              |
 | разработчиков, ведь по сути они всего лишь костыль, созданный  |
 | до изобретения шифрования дисков и защищают лишь от кражи      |
 | выключенного ноута или диска прямо из ПК ручками.              |
 └────────────────────────────────────────────────────────────────┘

Вопрос к гуглу: «открывает ли линукс доступ процессам к паролям при вводе мастер пароля» Ответ ИИ: «Ввод мастер-пароля лишь расшифровывает базу данных конкретного менеджера паролей (например, … или GNOME Keyring) в оперативной памяти этого приложения. Доступ к этим данным ограничен изоляцией памяти процессов.»

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

Я бы даже пофантазировал, то есть в базу паролей хорошо бы ещё ввести имя процесса, который запросил пароль, то есть левый процесс не может получить доступ к паролям, который не он создавал. Ну если бы я задумывал базу паролей, то я бы так и поступил. А что те люди глупее меня? Если это не так то должен быть аргумент в пользу противоположного.

Почему же?

 ┌────────────────────────────────────┐
 | Связка ключей хранит кроме ключа   | Приложение при первом запуске
 | электронную подпись бинарика или   | (установке) сообщает свою подпись или
 | скрипта, которая записала ключ или | требует себя подписать и запрашивает
 | получила в явном виде от           | доступ к секретному хранилищу
 | пользователя право его читать.     ╞═══════════════════════════════════════╗
 └────────────────────────────────────┘                                       ⇓
                                         ┌────────────────────────────────────┐
   Теперь приложение может сохранять     | Модуль ядра на уровне LSM проводит |
   секреты в хранилище, которое работает | проверку, что приложение,          |
   от специального пользователя secret   | запросившее разрешение             |
   и чья папка не доступна на чтение     | действительно имеет ту подпись или |
   никому кроме root и secret            | подписывает приложение             |
 ╔═══════════════════════════════════════╡                                    |
 ⇓                                       └────────────────────────────────────┘
 ┌────────────────────────────────────┐
 | Когда приложение запрашивает       | Если подпись не та, то возврат ошибки и
 | пароль из хранилища, то модуль     | уведомление пользователя, что такой-то
 | ядра проверяет подпись приложения  | процесс с такого-то бинаря вредонос и
 | и возвращает его связке ключей     | пытался получить доступ к секретам
 |                                    | такого то приложения. В противном 
 |                                    | случае возврат ключа.
 |                                    ╞═══════════════════════════════════════╗
 └────────────────────────────────────┘                                       ⇓
 ┌────────────────────────────────────────────────────────────────────────────┐
 | Злоумышленник может сохранять и читать только свои пароли и секреты, чужие |
 | не может, может если заражена сама программа которая работает с ключами    |
 └────────────────────────────────────────────────────────────────────────────┘

Однако тут есть ряд оговорок и трудностей требующих большой работы над ядром.

• Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).

• dbus не безопасен (его можно читать левым программам так же как и ключи сейчас), как вариант сокеты или шифрование внутри dbus могли бы помочь.

• Это не защищает от повышения прав до рута (но и не должно)

PS

А главная трудность в том, что тогда TPM не нужен, кроме как для DRM и очень специфичных бэкдоров и продавливать его необходимость будет труднее.

Ты не осилил скрипт из первого поста? Проверь сам, если не веришь. Сначала хром запусти только (чтоб связка разблокировалась тобой).

secret-tool lookup application chrome

Можно и бинарик написать, на сишке, но мне просто лень, когда он уже написан.

вроде PasswordVault,

С MSDN:

Represents a Credential Locker of credentials. Lockers are specific to a user.
Apps running in an AppContainer (for example, UWP apps) can only access the contents of their own locker (for the current user). Apps not running in an AppContainer (for example, regular Desktop apps) can access all the user's lockers, including those of AppContainer apps.

Т.е. для обычных (не UWP) приложений все «секреты» одной пользовательской учётки - общие.

Windows Hello API

Подробный и свежий ответ по теме: What is the security boundary of Windows Hello KeyCredentialManager credentials for desktop apps?

Судя по этой странице Win32 app isolation всё ещё в состоянии preview.

Да, именно так, но с использованием vim+gpg. Бонусом идёт доступ к паролям по ssh

Я не пользуюсь хромом и гномом. А там есть опция не сохранять мастер-пароль в DE-шной шняге? У меня есть своя программа, но мне бы не хотелось каждый раз логинится вручную.

Нет никакой опции (по крайней мере чтоб она была тривиально доступна). У большинства разработчиков понимания того как работает libsecret и какую проблему решает нет.

Хм, ну они хотя бы двигаются в правильном направлении.

Ядро должно иметь возможность надёжно отследить бинарь и процесс запущенной программы (как я понимаю сейчас это не так и в этом основная трудность).

В Андроид же эта проблема как-то решена, и там каждый app запускается под своей учеткой. Примерно также как в MS Windows app containers каждому приложению присваивается свой SID.

В Андроид же эта проблема как-то решена

Возможно что не на уровне ядра, а на уровне java внесли костыли. И системные (предустановленные) приложения всё это могут.

Изолированный запуск приложений? Пахнет снапом или флатпаком. Не уж то они что-то знали?

Костыль. Надо предполагать что любой файл, скачанный юзером с интернета - приложение (даже если он утверждает что является картинкой, т.к. уязвимости во всяких превьюшках у ФМ никто не отменял). И либо делать изоляцию для всего автоматически, либо работать оно не будет полноценно.

Отследить процесс несложно. Когда процесс подключается по сокету, сервер может запросить его pid и вытащить его /proc/pid/exe.

Проблема в другом. В линуксе хватает способов выполнить свой код «от имени» чужого процесса. Например пускай мы храним пароль от ssh-ключа в надежде на то, что его может вытащить только /usr/bin/ssh и отдаём пароль по сокету только если вызывающий имеет именно этот бинарник. Но пользователь легко может запустить ssh с LD_PRELOAD в котором будет библиотека с его кодом. Всё, теперь мы можем делать запросы «от имени» ssh. Через отладчик можно делать то же самое.

Т.е. в целом понятно, что это всё - странные вещи и можно было бы их пользователю и запретить. Но в линуксе не запретили. И никто не проектировал защиту процессов одного пользователя друг от друга.

Поэтому нормальная аутентификация возможна только по uid/gid. Их подменить нельзя и это то, как изначально проектировалась система безопасности в операционной системе. А то, что по факту эта система на десктопе никак не используется - ну я уже писал про то, что линуксовый десктоп это самая слабо защищённая операционная система из всех сравнительно популярных.

Так это опять к ядру вопросы. Под сложностью определить надёжно я как раз и имел это ввиду. Линусу плевать по сути на безопасность десктопа. Он пилит ОС для серверов. Хотя и на сервере я бы не отказался от надёжного хранения паролей для той же СУБД и приложения, которое в контейнере с ней работает, чтоб не хранить его в коде или конфиге.

Так это опять к ядру вопросы.

За LD_PRELOAD отвечает glibc, так что не совсем к ядру (: Но впрочем как надо сделать правильно я точно советовать не буду. Я просто вижу, что сейчас оно не так, как надо бы.

Линусу плевать по сути на безопасность десктопа. Он пилит ОС для серверов.

Я не думаю, что прямо таки плевать. В конце концов он же сам сидит на линуксе. Тут дело в другом.

Те, кому на безопасность было не плевать, например разработчики андроида, просто сделали сразу как надо. Для каждого приложения при установке создаётся свой пользователь. Каждое приложение запускается от своего пользователя. Изоляция между приложениями сделана корректно. В таких условиях уже можно работать.

А линуксовый десктоп родом где-то из 80-х. Когда на сервере работала сотня пользователей. И запускали они пару программ. И так оно и осталось. Какие-то потуги в виде флатпаков вроде есть, но я ими не пользовался и пользоваться не планирую, как, полагаю, и львиная доля других пользователей линукса. И вот такая вот закостенелость мешает развиваться. Как-то работает и ладно. Хотя нас вроде за уши тянут вперёд, к прогрессу, может и дотянут. Если, конечно, там реально прогресс… В любом случае флатпак это вроде для GUI приложений. ssh клиент через флатпак не ставят же.

LD_PRELOAD отвечает glibc

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

Хотя и на сервере я бы не отказался от надёжного хранения паролей для той же СУБД и приложения, которое в контейнере с ней работает, чтоб не хранить его в коде или конфиге.

На сервере как раз всё надежно. Для каждого сервиса свой пользователь и только он имеет права на чтение конфига с паролями.
Применительно к вышеописанному контейнеру с СУБД этим пользователем/сервисом будет по-видимому некий менеджер контейнеров.

Возвращаясь к теме десктопа: я думаю, что следует менеджер паролей запускать под отдельным пользователем, но в той же X сессии. Правда, тут мы получаем проблему буфера обмена, к которому опять же имеют доступ все пользовательские процессы. Но мне кажется, что это проще как-то пофиксить, чем городить полноценную изоляцию процессов.

Не хотелось бы встревать в разговор на тему топика, ибо в не очень разбираюсь (скорее очень не). Я смотрю на это со стороны.

А ситуация следующая: выходит новость про снап и тут же набегают «скорпоратились», «тормозная фигня», «эталонное не нужно» и всё в таком духе. А потом читаешь такие новости и думаешь: а может эти чудаки со своими странными решениями были не так уж и не правы? Поулчается что десктопный Линь обеспечивал безопасность по принципу неуловимого Джо, а как стал чуть популярнее, так оказалось, что в плане безопасности там поле непаханное и надо много чего делать.

Править ядро - вопрос спорный, ибо это может ударить по сервакам, а это точно никому не надо.

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

Не хотелось бы встревать в разговор на тему топика, ибо в не очень разбираюсь (скорее очень не). Я смотрю на это со стороны.

Я вот выше спрашивал что это за места такие где нужна секурность и нет двойной автрификации, что то молчат … странно это очень.

Как вы предлагаете отличать пароли одного приложения от паролей других?

Почему же?

Что почему? Если «почему с твоими проверками всё равно нельзя сохранять критически важные пароли», то потому что твоё устройство могут так или иначе взломать, и ты ничего с этим кардинально сделать не можешь - железо (микросхемы) делают без твоего контроля, софт тоже пишешь не ты (ну и скорее всего ты бы, даже если бы тебе предоставили права всё это контролировать, сделать это всё равно бы не смог ввиду отсутствия необходимых компетенций). Все эти простыни безопасных механизмов только снижают шансы утекания секретов, но не более того. Причём безопасные эффекты от 10 наложенных друг на друга програмных защит не складываются, а лишь чуть усиливают друг друга (т.к. дыра с большой вероятностью сразу все их разом обойдёт).

выковыривать gnome-keyring-daemon из гнома занятие неприятное, т.к. с keepassxc и гномом есть какие-то багулины.

Гномовский аналог «безопасности через неясность»? Безопасность через неудобства? :)

«[подставь любое слово] через неудобства» — это, по-моему, в принципе гномовский девиз :)

Любая защита строится вокруг вектора атаки и как раз её задача снижать риск утечек, повышая стоимость для атакующего до неадекватно высоких значений. Один из них векторов, к примеру, терморектальный и иногда с ним тоже надо бороться, потому что это снижает риски для того к кому его будут применять (нет смысла пытать человека, который ничего не сможет рассказать, кроме как для устрашения других). Но это не значит, что не надо заниматься защитами, т.к. это комплексные мероприятия.