id: Гость   вход   регистрация
текущее время 04:04 24/03/2023
создать
просмотр
ссылки

Хранитель паролей KeePassX


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



 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (18/05/2013 17:56)   <#>

Уязвимость браузера ≠ уязвимость Flash. Последний — вообще полноценный хозяин в системе. Это независимый процесс, который сам лазит в сеть и делает, что ему вздумается.
— SATtva (21/05/2013 08:57)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Что можно легко предпринять для защиты от кражи паролей, если делать быстро и на коленке?

Двое иксов, каждые со своим отдельным пользователем, в одних (А) — браузер, в других (Б) — база паролей. Под иксами Б копируем нужные реквизиты в общедоступный файл в /tmp, возвращаемся в иксы А и копируем реквизиты из файла в окно браузера.
— невер (21/05/2013 09:15)   <#>
по мне так это все тоже самое, только еще и с извращениями. Если у вас в системе сидит злой флэш/троян и только и ждет как базу стащить то, что ему мешает стащить все ваши пароли по одному по мере использования? Это тогда просто вопрос времени, а не защита.
— SATtva (21/05/2013 09:26)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Гражданин, Вы же всё равно вводите пароли через браузер, он их так или иначе получает. Ну, передавайте через астрал, Касперский вроде ещё не сообщал об отсраастральных троянах.
— Гость (22/05/2013 19:45)   <#>
так я про это и говорил. Должен же быть предел шизофрении, а то так уже можно и свое второе я подозревать. А то вздруг вы днем на пгп ру сидите, а ночью ваше второе я шлет письма мелким подчерком.
Лично меня, как я и сообщал уже в теме устроит отсутствие закладок в самой програме и стойкость шифра. А все остальное я отношу к организационным проблемам. Мойте руки перед едой, товарищи. Ну и не читайте советских газет.
— Гость (22/05/2013 23:31)   <#>
ваше второе я
это не параноя, а раздвоение личности. а не доверять себе – нормальный подход.
— Гость (23/05/2013 05:34)   <#>

Передадим IP-пакеты с помощью голубей Сделаем IPC своими руками. :)


Да, замечание совершенно справедливое. Пусть будет «костыль в надежде, что атакующий не сможет грамотно провести атаку», а по-хорошему — да, нет доверия к процессам конкретного пользователя — не может быть доверия и к безопасности паролей, которые из-под него используются.
— Гость (28/12/2013 22:58)   <#>

Допустим, есть профиль, из-под которого мы планируем безопасно ходить на некоторые чувствительные сайты (тот же интернет-банкинг, например), тогда:

  1. Создаём чистый профиль, настраиваем его по-минимуму, скидываем в него файл с паролями, разрешаем доступ к файлу паролей только от рута, и сохраняем весь этот профиль в бэкап.
  2. Когда нужно зайти на чувствительный сайт, удаляем всё старое, что было в профиле (его домашнюю директорию), восстанавливаем чистую копию из бэкапа, логинимся, открываем терминал.
  3. Под рутом в текстовой консоли меняем права на файл с паролями, возвращаемся в графику и делаем cat passdowrds_file | grep <site_name> для извлечения паролей на нужную категорию и только неё.
  4. Возвращаемся обратно в текстовую консоль и (под рутом) возвращаем права на доступ к файлу (теперь его может читать только root).
  5. Идём обратно в графического юзера и запускаем firefox. Логинимся на сайт, пароли копируем из терминала.

Если после этого надо зайти на другой сайт, повторяем всю процедуру (шаги 2-5) заново. При такой схеме есть какие-то гарантии, что пароль, например, на сайт-2 не может быть украден, во время работы браузера с сайтом-1. Есть гарантии, что добавленная уязвимость в профиль всегда нивелируется восстановлением копии из бэкапа (временные файлы с /tmp и /var, если трубется, тоже можно подчищать). Но если не громоздить такую схему, а просто держать файл с паролями под рутом, к которому давать доступ руками, когда надо, то почти вся заявленная безопасность улетучивается.

Кто может, покритикуйте предложенное решение.
— Гость (24/05/2014 16:32)   <#>
Кто может, покритикуйте предложенное решение.

Традиционная ахинея из подпорок с распорками из-за безграмотности, так же именуемая в народе: «колхоз». Типична для человека незнакомого с разницей между дискретной и мандатной системой контроля доступа. Потому айда восполнять пробелы, а так же что в этом плане предложило АНБ со своим SELinux и для чего используют «песочницы»(sandbox).

!И не смей агрессировать, реально колхоз жуткий предложил, иди действительно восполняй пробелы в познаниях.
— Гость (25/05/2014 00:59)   <#>
Распишите по шагам, как это сделать через SELinux, причём так, чтоб было короче, проще, удобней и надёжней, чем выше предложено. А то тут были жалобы что официальные дистрострители не могут SELinux приркутить, делают как попало, и сами не понимают, как он работает.

[offtop]
всё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.

С программами и демонами понятно. Для многих из них правил просто нет и они незащищены. Для других правила настолько глючат, что не допиливаются даже вручную. Для третьих вроде оно работает, но насколько это только видимость защиты — понять сложно.

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

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

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

Но вообще, SELinux всё ещё кривой и ужасный. По крайней мере в исполнении Debian. Приходиться использовать только стандартные политики (выучить и понять весь его синтаксис нет сил), выгружать часть глючных модулей (оставляя часть программ без защиты). Те модули, которые относительно успешно можно запустить хотя бы с глюками, есть возможность дополнять своими политиками в соответствии с тем, что выдаёт audit2allow, что есть неправильно и заведомо опасно (но лучше, чем совсем без них). И после каждого обновления есть шанс получить много геммороя с поиском причин глюков и перенастройкой. Стандартную поставку очень хреново обновляют. Иногда приходиться его полностью отключать (превращение защиты в театр). Но хоть какая-то защита (по принципу — в плане защиты SELinux не делает хуже, он может сделать "лучше, чем ничего" или ничего не сделать).

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

Всё зависит от степени параноидальности настроек. Но по большому счёту, да эти security-панцири не панацея, а не более чем костыль.

Сложность в создании правил компактного описания разрешений/запретов из-за сложности самого ядра.

В новых версиях SELinux ещё больше интересных возможностей и утилит ... но вся разработка ведётся на Fedora Linux, а в другие дистрибутивы всё переходит очень медленно.

Он [SELinux] по умолчанию почти везде отключен и реально крайне мало где используется.

Есть sandbox'ы, jail'ы, но всё это либо костыли, либо сводится к ослабленной защите метода «разные приложения — только под разными юзерами».

Интереснее подход с псевдовиртуалками (LXC). Сами по себе они не дают безопасности (рут в LXC = рут в системе и выход из псевдовиртуалки). Но для LXC уже сейчас есть специальные правила SELinux, которые исключают такую возможность, делая их допустимо безопасными. Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.

пока у файлов есть только "владелец, группа, другие" + довесок ACL или MAC, а у процессов нет ролей и доменов безопасности и т.п., то хоть чрутьте, хоть ACL используйте — это будет "просто лучше, чем ничего".

Под Linux существует так называемый "укреплённый chroot", в составе набора патчей, "повышающих безопасность". но разработчики ядра оценили этот проект как тупиковый и отказались включать его в ядро.

Знаете что? В гробу я видел ваш SELinux, песочницы, MAC, jail'ы, чруты, псевдовиртуалки и прочую нечисть. Есть механизмы контроля ОС (нет локального рута — нет утечки), и есть механизмы разделения информации между разными ОС через виртуалки (нет удалённого рута или дыры в самой виртуальной машине — значит, всё ОК). Всё остальное — это слишком сложные костыли, да ещё и толком не работающие, их изучение и использование себя не окупает, будет лишь иллюзия контроля и иллюзия безопасности. Я уже не говорю о том, что вопрос «откуда взять правила SELinux для такой-то моей конкретной задачи» практически нерешаем.
[/offtop]
— Гость (25/05/2014 01:19)   <#>
Распишите по шагам, как это сделать через SELinux...
Знаете что? В гробу я видел ваш SELinux, песочницы, MAC, ...

Прямо очередная истеричная баба с семью пятницами на неделе. Теперь понятно, почему берётся рассуждать об информационной безопасности не ведая элементарных азов. Надо будет дом построить — сколотит сарай без фундамента с односкатной крышей. Заявив, что в гробу видал долбатню со всеми этими премудростями. А нанять архитектора и строителя — религия не позволяет, это ведь денег платить придётся. Пусть ему лучше в инете, на борде анонимной, обрисуют весь необходимый ликбез на пальцах. Ну так, чтобы пять лет в строительном уложилось в два-три поста.
— Гость (25/05/2014 01:51)   <#>
Эмоций, срача, оскорблений, толстого троллинга и переходов на личности хватает, недостатка нет. А по существу ответ будет, как это сделать? Или мы имеем классический пример толстого троллинга от анонима, который пытается затроллить всех SELinux'ом при том, что он сам его в глаза ни разу не видел и никогда не настраивал?

Выше были приведены цитаты с мнениями тех, кто пытался с SELinux'ом разобраться. На эту тему в соответствующих топиках было много обсуждений. Получается, тут все кругом дебилы, никто не смог осилить, и только один вы — д'Артаньян? Тогда покажите это на деле.
— Гость (25/05/2014 01:55)   <#>

PGPru — это тематический форум, а не анонимная борда типа двача. Соответственно, ваши срачевбросы, написанные в стиле «щас высрусь», могут быть снесены одним кликом, если не последует конструктив.
— pgprubot (28/08/2015 16:08, исправлен 28/08/2015 16:08)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Один из способов перекидывания паролей/контента от одного юзера другому — это fifo:

userA $ mkfifo /tmp/file
userA $ cat filename > /tmp/file
userB $ cat /tmp/file
Юзер userB сделать cat сможет только один раз, т.е. достигается одноразовость передачи данных, и не нужно помнить, что файл надо стереть после чтения. Ещё бы там автостирание по таймауту было б — и совсем хорошо стало б.

— SATtva (28/08/2015 17:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4116
Уточнение: после создания FIFO-объекта следует изменить его права доступа, убрав общий доступ на чтение. В противном случае вместо userB перехватить данные сможет кто-нибудь другой.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3