id: Гость   вход   регистрация
текущее время 14:41 15/07/2024
Автор темы: falkenberg, тема открыта 27/03/2012 01:57 Печать
Категории: софт, gnupg, операционные системы
https://www.pgpru.com/Форум/РаботаСGnuPG/GPGВУбунтуВИксахДелюсьОпытом
создать
просмотр
ссылки

GPG в убунту в Иксах. Делюсь опытом


Итак, поскольку постоянно обращаться к консоли при попытке прочесть чью-нибудь подпись несколько утомительно, я решил это немного автоматизировать. Успешным опытом чего собираюсь поделиться.


  1. Создаём дефолтный .xbindkeysrc:

  2. Для того чтобы выводить окно с результатом проверки на экран я использую gmessage. Если его нет – установить с помощью atp-get
  3. Для работы с клипбордом использую xclip. Если его нет – установить с помощью atp-get
  4. Редактируем .xbindkeysrc добавив в него следующее:

  5. Проверим что xbindkey запускается при старте X-сессии. В Убунту это так по дефолту.

Все. Теперь для проверки чьей-либо подписи просто выделяем текст мышью и жмем Ctrl-~ (Контрл-тильду). Появится окно с результатом проверки.


Я сделал то же самое для того чтобы аттачить свою подпись к выделенному фрагменту. Для этого добавим в .xbindkeysrc следующее:


Как видим, потребуется еще программа xte. Она позволяет генерировать события в X, в данном случае ее вызов аналогичен нажатию на кнопки Shift-Ins, что то же самое что вставка из буфера обмена. Теперь по нажатию Ctrl-1 выделенный текст будет заменяться на такой же, но подписанный. CAFC2EEE – это ID моего ключа. Соответственно, заменить на свой.


Следует учесть, что Убунту по дефолту запускает xbindkey когда gpg-agent еще не запущен. В этом случае он не сможет расшифровать секретный ключ для подписи на лету. Чтобы это все работало, надо запретить его старт автоматом из Xsession.d Для этого создаем пустой файл в хоумдире с именем .xbindkeys.noauto Теперь xbindkey не запускается сам. Запускаем его либо ручками после запуска сессии, либо добавив его в список автозапускающихся программ. Для этого служит утилита Startup Applications


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (30/12/2012 03:35)   <#>

Вообще, лучше не делать заявлений, а погуглить и разобраться, почему на одних системах это работает, а на других нет. Анонимность/безопасность наугад — плохой метод.
— Гость (30/12/2012 03:53)   <#>
Ваш снобизм совершенно неуместен. Есть че сказать по делу или дальше будете вые*ться?
— Гость (01/01/2013 16:40)   <#>

Ничего не понял в этом хамстве и мате (если это мне).

Ещё раз, если кто не понял: описанное свойство есть, наблюдается не только у меня. Если в каких-то системах оно не работает, то не стоит неосмотрительно кидаться в крайность «всё хорошо, мне ничего не грозит». Может так оказаться, что всё же «грозит», но для этого надо использовать другие команды/интерфейсы. Если где-то в одном месте работает, а в другом — нет, нужно разобраться почему, что вызывает разницу. Только после этого можно быть уверенным в том, что оно безопасно от таких трюков.

Форум публичный, никто никому не обязан, и я не должен рыть землю, только чтобы дать исчерпывающий ответ на то, почему у кого-то где-то оно не сработало. Потрудитесь разобраться сами и написать ответ здесь. Если позже у меня возникнет понимание, из-за чего такое может прозойти, отпишусь, но личного интереса гуглить эту тему и вникать сейчас нет. К тому же, su/sudo — не единственные способы обхода механизма. Если юзер потнециально скомпрометирован, в любом случае нельзя дать никакой гарантии.

P.S. Есть у sudo ещё и такая тонкость, как подцепление переменных из текущего шелла, что может быть легко использовано для компрометации. Чтобы этого избежать, советуют писать su -l username или su -- (не помню, один там минус или два должно быть).
— Гость (02/01/2013 18:01)   <#>
При импорте ключа пишется
gpg: next trustdb check due at 2013-XX-XX
Такой trustdb check подразумевает самостоятельное подключение gpg к интернету? И, вообще, бывают ли какие-то случаи, когда gpg или гномовские приблуды вокруг неё самостоятельно лазят за чем-нибудь в интернет? Насколько безопасно для анонимности хранить публичные ключи в обычной связке? Не сольёт ли gpg куда-нибудь факт обладания соответствующими публичными ключами в связке?
— unknown (02/01/2013 21:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Насколько помню, сама GnuPG в инет не лазает без явного указания соответствующих команд.

Проверка базы — это взаимная верификация подписей на ключах, которая действительно занимает очень много времени при большой связке, поэтому результаты кэшируются, а сама эта проверка для обновления кэша запускается с определённой периодичностью (не устарели ли подписи? и др.) и, возможно по ещё каким-то критериям. Но, по идее это чисто оффлайновая процедура.
— Гость (03/01/2013 10:06)   <#>
Но, по идее это чисто оффлайновая процедура.
ОК, спасибо, успокоили.
— Гость (12/03/2013 12:26)   <#>
— spinore (27/03/2012 23:42)- протестил предложенную схему под Debian AMD64, только с gksu, а не с ssh.
Иногда работает, иногда – нет. Так, если я запускаю через gksu gnome-terminal под другим юзером, xev ни с одной, ни с другой стороны не показывает вводимые в нем знаки (хотя вскую лабуду показывает, не связанную с клавиатурой, не совсем понимаю, что это, типа такого:

И что значит root в контексте данного лога?
Далее, если под одним юзером запускаю тор-браузер, и запускаю гном-терминал через gksu, в последнем xev также не видит, что я ввожу в адресной строке, поисковых запросах, веб-формах и т.п. Наоборот – тоже.
xev под "родным" терминалом тоже не видит букв, например, что я ввожу сейчас в этой форме.
А вот если запустить скайп из-под одного юзера в другом, xev в терминале первого видит все буквы, вводимые в окошке скайпа.
Как это объяснить?
P.S. Что-то странное, не получается залогиниться в другого юзера на локальной машине через ssh (и с X-форвардингом, который включен, и без):

Хотя с удаленных машин логинюсь. Туплю что-то. Вроде никаких специальных настроек раньше не требовалось...
— SATtva (12/03/2013 12:46)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Что-то странное, не получается залогиниться в другого юзера на локальной машине через ssh

ssh -v поможет в отладке.
— Гость (12/03/2013 15:11)   <#>
ssh -v поможет в отладке.





– настройки фаервола (прозрачной торификации) мешают.
Сейчас попробовал, между незаторенными юзерами все нормально проходит.
P.S. Если открыть возможность локального коннекта между прозрачно заторенными юзерами – это будет "дыра"? Или лучше локально gksu использовать, если не очень критично?
А если открыть возможность внутрисетевого (в домашней сети, где все компы как бы доверенные, если сетку не ломанули, конечно) – насколько большая получиться дыра?
— Гость (12/03/2013 15:47)   <#>
Если открыть возможность локального коннекта между прозрачно заторенными юзерами – это будет "дыра"? Или лучше локально gksu использовать, если не очень критично?

Критично или нет — понятие растяжимое. Кому-то критично до такой степени, что параметры машины пытаются замаскировать, запуская ОС в вирталке. Если оба юзера прозрачно торифицированы, то, казалось бы, можно сделать между ними связь, но раз их два, а не один, отличие между ними есть. Например, с каждым юзером может быть связан свой профиль, а смешивание профилей быть нежелательным. В этом случае наличие прямого коннекта от одного юзера к другому облегчает атаку на связывание профилей.

В идеале торифицированные юзеры
  1. Не должны ходить куда-либо в обход Tor, даже локально.
  2. Работать в ОС, которая должна откатываться в предыдущее «чистое» состояние после каждой рабочей сессии.
  3. Не должны иметь доступ к параметрам железа и файлам той ОС, под которой ведётся неанонимная работа.
Каждый может ослаблять эти общие правила для себя в зависимости от паранои и резонности.
— Мистер_Грин (12/03/2013 16:08, исправлен 12/03/2013 16:11)   <#>
  1. Не должны ходить куда-либо в обход Tor, даже локально.
  2. Работать в ОС, которая должна откатываться в предыдущее «чистое» состояние после каждой рабочей сессии.
  3. Не должны иметь доступ к параметрам железа и файлам той ОС, под которой ведётся неанонимная работа.

А как это сделать? Первый пункт решается настройкой Privoxy\Polipo, третий тоже более-менее ясен. Скажите, а как быть со вторым пунктом.

— Гость (12/03/2013 18:00)   <#>
а как быть со вторым пунктом.
Работать с виртуальными машинами. Гостевая ОС каждый раз перед стартом восстанавливается из чистого состояния. Кто-то здесь писал, что даже Tails LiveCD в таком режиме использует, т.е. загружает его в виртуальной машине.
— Мистер_Грин (12/03/2013 18:16)   <#>
А пробовал кто-нибудь запускать под вайном приложения в Sandboxie? Это было бы удобнее.
— Гость (12/03/2013 22:53)   <#>
Также тут многократно приводилась инфа о нежелательности работы с виртуальными машинами. Что типа в них могут быть "дыры", позволяющие приложениям, в них запущенных, контролировать физическую систему.
Как все сложно!!!
— Гость (13/03/2013 00:41)   <#>

Говорят, можно пострелять себе в т.ч. в ногу, если сильно хочется, но я бы не пользовался так называемым выборочным цитированием, как вы это пытаетесь. Если вы про это, то

Уязвимость была даже не по вине программистов VMware. Дело в том, что веб-интерфейс этого менеджера (висит на TCP-порту 9084) использует в качестве веб-сервера
Т.е. за такое надо убивать сразу. Какое ещё «управление виртуалкой из браузера»?! Это для секретуток делают в фирмах, которые принимают заказы «клиентов», а мозги куринные. Управление всем — только с консоли.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3