--user-data-dir=/home/user/.config/chromium_second_profile/ - защитит ли от кражи cookies и паролей?

В хроме до сих пор нет нормального менеджера профилей?

В фф это делается ключом -P <имя_профиля>.

Насколько изолирован будет второй профиль?

На уровне js - изолирован. То есть честно залезть в другой не получится. А вот если проэкслуатировать RCE-уязвимость (их регулярно находят и исправляют) в браузере то можно вылезти из js-песочницы и делать что угодно в рамках того куда пустит ОС. Но тут я бы не про пароли в браузере беспокоился а про доступ к произвольным файлам юзера.

Или лучше запускать второй экземпляр от имени другого пользователя?

Повторюсь, дело тут не только в браузере. В первую очередь такие меры нужны для запуска всякого сомнительного софта типа игрушек (особенно если с торрентов, но и официальным я б не стал сильно доверять).

И если да, то как это сделать по уму?

Создаёшь второго юзера командой adduser от рута, проверяешь что права на всё home-директории и на /root/ стоят 0700 не 0755 как часто бывает дефолт (= все могут читать чужие файлы), потом запускаешь юзеру отдельный иксовый сеанс: ctrl-alt-f2, логинишься и пишешь startx -- :2. После чего можно переключаться между разными иксами.

Спасибо за то, что объяснили настолько подробно!

Когда-нибудь они наконец научатся не хранить пароли в браузере? Про белые списки для кукизов я уже даже не мечтаю.

Да они и так защищены, если используется gnome-keyring/kwallet, тогда все твои значения кук зашифрованы, пароли зашифрованы, их кража не имеет смысла. Другое дело, что ВСЕ ЭТИ ДАННЫЕ ЧАСТО почему-то хранятся в открытую. У меня хромиум почему-то не использовал kwallet как и не использует Brave

Когда-нибудь они наконец научатся не хранить пароли в браузере? Про белые списки для кукизов я уже даже не мечтаю.

Ну вообще, про пароли было образно сказано. Конечно, храню в блокнотике, в каталоге, доступ к которому только у root. Но удобно было бы конечно поставить авто вход. Боюсь только не утекли бы все данные куда не следует в результате какой-нибудь незадокументированной синхронизации. Экспериментальной функции, так сказать.

gnome-keyring/kwallet

Так xfce же... Ну... Хотя есть Seahorse, который я к своему стыду еще не освоил. Насколько он заменяет KWallet - не скажу, не вникал еще. А! Вот еще вопрос: его, этот пакет, можно настроить так, чтобы он выполнял свою функцию и при этом не морочил голову каждый раз при запуске браузера - «введите пароль от связки ключей»?

За идею спасибо!

«…или крестик снимите, или трусы наденьте.»

Ты уж определись. Хочешь быть единственным, знающим пароль, или пусть знает еще кто-то. Форумы полны тем, избавить от фразы «введите пароль от связки ключей».

Ну если «двести рублей не могут спасти гиганта мысли», то пусть будет пароль. Лишь бы толк от него был. В общем, два профиля и Seahorse?

Без kwallet/gnome-keyring куки и пароли так же шифруются, но каким-то общеизвестным (захардкоженным) КЛЮЧОМ типа пинэпл и тп, поэтому я и утверждаю, что в «открытую» хранятся

Xfce - это тот же самый гном. gnome-keyring там есть, но может быть не настроен. Когда ты входишь через gdm/sddm, то в случае успешного входа, твоим паролем разблокируется связка ключей, если примитивно, то там есть ключ шифрования данных, который хранится зашифрованным паролем пользователя. Это сделано для того чтобы при смене пароля ты не потерял зашифрованные данные. Поэтому после смены пароля пользователя браузер начинает просить ввести старый пароль, и избежать этого можно только сменив пароль на связке ключей на текущий. Я подозреваю, что нужно настроить PAM, так как криворукие авторы крысы все сломали

Спасибо! Теперь - есть!

$ sudo apt install gnome-keyring
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово         
Будут установлены следующие дополнительные пакеты:
  gcr gnome-keyring-pkcs11 libassuan0 libgcr-ui-3-1 libpam-gnome-keyring
  p11-kit p11-kit-modules pinentry-gnome3
Предлагаемые пакеты:
  pinentry-doc
Следующие НОВЫЕ пакеты будут установлены:
  gcr gnome-keyring gnome-keyring-pkcs11 libassuan0 libgcr-ui-3-1
  libpam-gnome-keyring p11-kit p11-kit-modules pinentry-gnome3
Обновлено 0 пакетов, установлено 9 новых пакетов, для удаления отмечено 0 пакетов, и 3 пакетов не обновлено.
Необходимо скачать 2 709 kB архивов.
После данной операции объём занятого дискового пространства возрастёт на 10,4 MB.
Хотите продолжить? [Д/н] 

Прошу прощения за то, что спрашиваю одно и то же 10 раз, но всё-таки хочу убедиться, что я всё понимаю правильно:

1) запрет cookies в браузере и использование белого списка закрывает доступ к хранилищу куки со стороны сайтов, не входящих в белый список - у них нет возможности не только устанавливать куки, но и читать из них, что неплохо повышает приватность и защищенность;

2) gnome-keyring после установки сам автоматически перетягивает в свое хранилище все пароли из chromium, они больше не хранятся в plain text в профиле пользователя, что также повышает защищенность;

3) пароль на gnome-keyring целесообразно выставить отличный от пароля текущего пользователя;

4) gnome-keyring шифрует не только пароли chromium но и куки, причем также по умолчанию, сразу после установки, дополнительно ничего настраивать не нужно;

5) нет необходимости заморачиваться о том, что после разового ввода пароля от связки ключей при запуске браузера доступ к паролям сохраняется открытым до конца сеанса (вот этот момент меня вводит в ступор: «не переживайте, что Вы видите пароли, их видите только Вы, под свои пользователем»... Пардон, а под каким пользователем будет работать потенциальная уязвимость в том же браузере, если не под моим?!!!)

6) gnome-keyring будет работать не только с профилем по умолчанию, но и в случае запуска с аргументом --user-data-dir=/home/user/.config/chromium_second_profile/ при этом он сам со всем разберется и ему ничего не нужно объяснять дополнительно.

В общем, если не сложно, пожалуйста, помогите понять эти моменты.

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

1 -

2 -

3 -

4 -

5 -

6 -

Про белые списки для кукизов я уже даже не мечтаю.

Спасибо за идею.

На хабре же была статья с рекомендациями

На виртуалке запускай всё что связано с важными данными.

На хабре же была статья с рекомендациями

На виртуалке запускай всё что связано с важными данными.

Интересный подход. Но ресурсозатратный. А можно ссылку?

как это спасет? как вариант можно еще стороний менеджер паролей использовать. есть интеграция с pass - вот там точно все зашифрованным хранится

все твои значения кук зашифрованы, пароли зашифрованы, их кража не имеет смысла

это рассуждение твоё не имеет смысла. Толку от их зашифрованности если поимели браузер, которому их заботливо расшифровывают и отдают в открытом виде без какого-либо пользовательского на то одобрения?

Заполните сначала следующую форму:

Модель угроз: ______________________________

Ты храни и юзай, а другим это все не надо.

Забавные комментарий=)

На гитхабе сами стилеры данных найдёте, да)

Модель угроз: ______________________________

Не думаю, что есть вероятность целенаправленной атаки. Скорее опасность зайти на какой-нибудь сайт, который перебирает известные уязвимости и если находит, выполняет автоматически какой-нибудь вредоносный код. Больше всего беспокоит потенциальная возможность перехватить сессию в Сбербанк Онлайн или в WebQUIK. Но вторая штука - довольно защищенная. Даже больше, мне кажется, чем сам личный кабинет Сбера. Пароли на эти вещи, разумеется, не храню в менеджере.

Сбер и WebQUIK сейчас в отдельном профиле. Куки запретил в обоих профилях, кроме белого списка. В chrome://settings/content запретил всё, что только можно. Но js оставил.

Как-то так.

Не по форме, но как есть. )

Сбербанк Онлайн

Просто ходи туда исключительно со своего телефона для предъявления силовикам, проблема решена.

Да, но... У меня нет смарта. И пока не выпустят недорогие модели с поддержкой нормальной операционки, в идеале - дебиан, покупать не планирую.