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

Комментарии
— SATtva (27/03/2012 22:05)   
Интересное решение, спасибо.
— unknown (27/03/2012 22:10)   
Вот только некоторые пользователи настолько суровы, что даже к sudo относятся с таки подозрением, что совсем его в систему не ставят, а тут gpg-агент и иксовые утилиты :) Но действительно интересно, можно полезное почерпнуть, даже для чего-нибудь другого.
— spinore (27/03/2012 23:42)   
Примерно такие же мысли, как у unknown'а. Для тех, кто не знает, в пику обсуждений про gksu (в окрестности /comment45227[link1]) и этот топик показываю фокус. Внимательно следите за руками:

  1. Логинимся в терминале как
    $ ssh -X другой_юзер@localhost
    Это типа среда для исполнения потенциально опасных приложений (например, Skype). Надеемся, будто бы эта среда реально безопасна.
  2. Из-под другого_юзера запускаем
    $ xwininfo
    Щёлкаем мышкой по понравившемуся нам окну (например, терминалy под стандартным юзером), чтобы получить его идентификатор. После щелчка приглашение комстроки возвращается, и там будет написано что-то в духе
    xwininfo: Window id: 0xXXXXXXX "NAME"
  3. Из-под другого_юзера запускаем
    $ xev -id 0xXXXXXXX > FILE
  4. Возвращаемся в выбранный терминал под стандартным юзером и выполняем что-нибудь типа
    $ gpg -d file.gpg
    Вводим пассфразу.
  5. Открываем файл FILE и читаем его. Каждый символ будет иметь вид (здесь пример для символа «g»):
    KeyPress event, serial 17, synthetic NO, window 0xXXXXXXX,
    root 0xXXX, subw 0xXXXXXXX, time XXXXXXXXX, (XXX,XXX), root:(XXX,XXX),
    state 0x0, keycode 42 (keysym 0x67, g), same_screen YES,
    XLookupString gives 1 bytes: (67) "g"
    XmbLookupString gives 1 bytes: (67) "g"
    XFilterEvent returns: False
  6. PROFIT! LOSS!

И повторю ещё раз, специально для unknown'а: sudo небезопасно :)

Для тех, кто ничего не понял:
Любая программа, запущенная под иксами, имеет возможность ловить все инвенты во всех окнах под этими иксами (простейший кейлоггер можно реализовать на шелл-скрипте), даже если запущена из-под другого юзера, а уж про такую банальность как 
$ scrot -d 5 file.png
из-под другого_юзера я вообще молчу. Думайте над этим, когда запускаете приложения под своими иксами.

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

По поводу топика: проверять таким образом подписи можно, но сильно надеяться на их сверку я бы не стал, делать же что-то более серьёзное (то, что требует пассфразу на ключ) — и тем более.

При неумелом использовании/настройке sudo возникает множество дыр. Про истории, когда посторнний пользователь с шеллом получал права рута из-за того, что судо пароль как-то закэшировало (или наоборот, незакэшировало?) наслышан.
— falkenberg (28/03/2012 00:33, исправлен 28/03/2012 02:13)   

ИМХО – все это параноя. Ну какой смысл взламывать себя самого? В том, что события, переданные *как-бы* из под другого аккаунта будут логированы нет ничего удивительного, ведь X-сессия, в контексте которой запущен xterm в котором запущен ssh, залогиненный на другой аккаунт таки запущена из-под того пользователя, кто собственно запустил X. Логично что события, относящиеся к этой сессия подлежат наблюдению. В "тот шелл", который с другого аккаунта все наши нажатия все равно идут через оригинальную сессию, но что в этом такого? Мы сами установили доверительные отношения между ними, залогинившись ssh-ем. Я не вижу возможности для "внешнего" интрудера перехватить эту сессию, если я что-то пропустил – укажите. Правда не вижу.
Троян под скомпроментированным пользователем вообще может узнать много чего, правда сначала этого пользователя надо скопрометировать. Вообще все, что было под этим самым скопрометированным пользователем лучше всего считать скомпрометированным. В случае PGP правильнее всего просто не хранить мастер-ключ на таком компьютере, а только саб-ключи. В случае их компрометации – просто отозвать.
Еще вопрос: почему не стоит надеяться на сверку подписи? Предложенный способ лишь выводит на экран то, что сделала бы консоль, и ничего более. Почему степень доверия к такой проверке меньше чем к консоли? Думаю должна быть такой же.


PS. Прочитал тред про gksu[link2]. Пришел к выводу что вообще надо пользоваться отдельными компами для каждой задачи: одним для браузера, другим – для ворда, третьим – для PGP :)) Ну или по крайней мере виртуалками для каждого из оных )
PPS. Удобство = k очумелых_ручек / Безопасность

— spinore (28/03/2012 05:07)   

Простейший пример — эксплуатация злонамеренным сайтом дыры в браузере. Выше был приведён пример скайпа1. Список можно продолжать. Любое приложение, работающее с сетью, таит в себе угрозу, и джаббер-клиент, если имеет доступ к приватному PGP-ключу, тоже.


Система должна быть настроена так, чтобы программы разного рода опасности были бы запущены в разных «песочницах». В реальном мире нет идеальных программ, значит, защиту надо строить так, чтобы бороться с их уязвимостью. Некогда я написал на эту тему черновик[link3] будущего FAQ.


Абсолютно верно. И ключи лучше сделать временными[link4]. И для программ, работающих с приватными ключами автоматически (джаббер-клиенты), лучше иметь отдельный ключ2.


Потому, что обмануть графические приложения в среднем проще. Чем больше степеней свободы у системы, тем больше свободы и у атакующего такую систему. Вы завязываете в один узелок иксовые утилиты, хоткеи и PGP. Достаточно, чтобы в одном месте произошла ошибка, и вы в пролёте. Мне не хочется сейчас фантазировать на эту тему, но мысль должна быть понятна. Даже в консоли есть неожиданности[link5], о которых среднестатистический пользователь даже не подозревает.


Да, и про всё это я уже многократно писал[link6]. По крайней мере, анонимный и неанонимный пользователь3 никак не должны сосуществовать в одной и той же ОС, а программы повышенного риска4 должны работать из-под отдельного пользователя и не иметь доступа к файлам (событиям/окнам) вашего юзера в $HOME вообще.

Основной итог таков, что чем больше знаешь, тем лучше осознаёшь, насколько легко[link7] и дёшево вся защита обходится, а максима
безопасной можно считать лишь систему, котоpая выключена, замуpована в бетонный коpпус, запеpта в помещении со свинцовыми стенами и охpаняется вооpуженным каpаулом, – но и в этом случае сомнения не оставляют меня. ☭[link8]
начинает казаться не художественным преувеличением, а горькой правдой жизни.

1Как потенциально возможного трояна в системе с удалённым управлением.
2Как это SATtva, к примеру, сделал.
3Там, где анонимность — не довесок, а реально критична.
4Браузер, Skype, какие-то другие сетевые.
— unknown (28/03/2012 10:39, исправлен 28/03/2012 11:05)   

Могу привести недавний пример.


Давно не отправлял gpg-писем.
Но поторопился отправить SATtva письмо (так что он не даст соврать :) о переводе материала для сайта.
Продлевал действие ключа, добавлял подключи. Заодно то ли что-то менял до этого в скриптах-алиасах, то ли как.
Ситуацию в точности воспроизвести не удалось, хотя было бы поучительно.


Но, как оказалось, в команде шифрования из-за нагромождения опций --encrypt-to, --hidden-encrypt-to и
неправильного их расположения (сначала нужно было бы ставить опции, а затем операции — --encrypt, --sign) и
злополучном применении опции --armor, то текст выглядел … закодированным в армор, понятное дело.
Но при этом оказался … подписанным, но незашифрованным (опция encrypt тихо проигнорировалась) и в таком виде и был отправлен. А armor кодировка скрыла сей факт от глаз.


Теперь для всех операций делаю gpg -v, перенаправление потоков в отдельные файлы и изучение выхлопа каждой
операции. А перед отправкой чего-либо важного делаю ещё и контрольное расшифрование (если добавлялось шифрование
на свой ключ).


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

— Гость (28/03/2012 11:05)   
А перед отправкой чего-либо важного делаю ещё и контрольное расшифрование (если добавлялось шифрование
на свой ключ).

Этот ваш пгп такая камасутра? А еще нужно с бубном вокруг костра побегать?

К чему это я – если для отправки сообщения в супер-пупер системе нужно сделать перечень телодвижений, то обязательно случится так что пользователь забудет или бубен, или костер...
— unknown (28/03/2012 11:32, исправлен 28/03/2012 11:33)   

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

— falkenberg (28/03/2012 15:20, исправлен 28/03/2012 15:34)   

to spinore:
В целом согласен. За исключением пожалуй максимализма

Основной итог таков, что чем больше знаешь, тем лучше осознаёшь, насколько легко и дёшево вся защита обходится...

Оно в целом верно, если рассматривать безопасность как абсолют. В смысле асолюта безопасным себя чувствовать может лишь покойник (правда, ему надо сначала научиться что-то чувствовать – каламбур!) Для всех остальных она определяется с одной стороны степенью защищенности самого слабого звена, а с другой – ценностью того, что можно украсть. Технологически PGP думаю использует те же самые алгоритмы, что защищают ядерный чемоданчик, но было бы наивно считать что супер-мега-данные, хранящиеся у меня на компьютере, защищены с такой же степенью. Да даже если не на компьютере, а на флешке, хранящейся в сейфе. Потому как и его не спасти от взлома.. фомкой. Или там если вежливо попросят. Для хорошей защиты данные надо зашифровать, положить в яйцо, яйцо – в рыбу, рыбу – в птицу, птицу – в зайца, зайца – в клетку, засунуть его в замок, окружить тройным рвом. И еще подписать договор о ненападении со всеми ближлежащими иванами-царевичами. Другое дело что кому нужен доступ до любимой порнушки, чтобы ради нее идти на все это? Да даже ценность моего личного PGP-ключа не такова, чтобы внедрить мне трояна с помощью ментальных волн или каким-нибудь еще более простым способом. Конечно никто не застрахован на 100% от фишероф, но тут сильно помогает простая компьютерная гигиена. Кроме того есть еще какие-то правовые нормы по защите прайваси, не позволяющие внедрять троянов (ну... явных троянов) в программный код производителями ПО, поскольку они ответят за это по закону рублем или долларом. И все это в конце-концов упирается в понятие доверия. Как софту, который ты используешь, так и железу, на котором все это крутиться.
Можно конечно искать компромиссы и пытаться изолировать программы друг от друга. И в целом это неплохо. Но надо понимать что абсолюта не добьешся и в этом случае, а вот удобство работы может сильно пострадать. В современном десктопе приложения глубоко интегрированы друг с другом. В Windows браузер и система используют один и тот же keystore для сертификатов. Это так, лишь пример. Все равно все упрется в итоге в доверие к тому, что используешь. И, исходя из этого, (само)ограничение в доступных средствах.
Исходя из этого я нахожу предложенный способ не таким уж плохим. Если конечно с этого десктопа не управляют атомной станцией :)


PS. Только что пришел с семинара по облачным решениям от COMPAREX. Вот уж где без установления доверительных отношений вообще делать нечего! А ведь это – уже даже не завтрашний день, а сегодня. Имею в виду не именно COMPAREX конечно, а нынешнюю моду на облака.

— sentaus (28/03/2012 15:41)   
Кроме того есть еще какие-то правовые нормы по защите прайваси, не позволяющие внедрять троянов (ну... явных троянов) в программный код производителями ПО, поскольку они ответят за это по закону рублем или долларом.


Вы много таких случаев знаете? :)
— unknown (28/03/2012 15:47)   
Технологически PGP думаю использует те же самые алгоритмы, что защищают ядерный чемоданчик, но было бы наивно считать что супер-мега-данные, хранящиеся у меня на компьютере, защищены с такой же степенью.

Если верить русской википедии (похоже эти факты действительно были):
* Джимми Картер носил коды запуска в пиджаке. Рональд Рейган — в бумажнике.
  • Однажды Джимми Картер забыл свой личный идентификатор (нужный для того, чтобы воспользоваться чемоданчиком) в кармане пиджака, отправленного в химчистку.
  • По утверждению генерала Хью Шелтона, где-то в 2000 году помощник, который хранит коды доступа, признался, что коды утеряны несколько месяцев назад.
Не следует думать, что какие-либо "стратегические объекты" хорошо охраняют (по крайней мере в информационном плане), просто более тщательно скрывают провалы и интенсивнее разыгрывают "театр безопасности".
— sentaus (28/03/2012 16:02)   
Не следует думать, что какие-либо "стратегические объекты" хорошо охраняют

Хочется верить, что их хотя бы хорошо охраняют по старинке, "оффлайново" :)
— falkenberg (28/03/2012 16:26)   
Вера – движущая сила всего и вся :) Только она убеждает нас работать месяц, чтобы получить цыфирьки на свой счет в банке, или обменивать материальные блага или услуги на резаную бумагу. Она же убеждает нас в собсвенной физической и информационной безопасности, что, в общем, совсем неплохо. Иначе было бы гораздо хуже ;)
— unknown (28/03/2012 17:41)   
Ну значит у большинства конвенционализм — своего рода религия.
— Гость (02/04/2012 06:55)   

Напомнило[link9] (SATtva):
если ведётся обработка сверхценных данных, машина должна быть полностью автономной, никаких сетей, всё взаимодействие с внешним миром — через оператора и принтер.
— unknown (02/04/2012 10:03)   
Ещё раз подумал: в практической деятельности скорее работает принцип "конвенционализм на службе прагматизма". Безопасность — из этой же области. :)
— Гость (02/04/2012 11:25)   
Система должна быть настроена так, чтобы программы разного рода опасности были бы запущены в разных «песочницах».
Система (язык) программирования Эрланг?
— spinore (14/04/2012 19:36)   

Вообще, это странно. Обычно, если порядок опций нарушен, gpg ругается, с чем я периодически сталкивался.


IMHO, достаточно зашифрованный файл попытаться расшифровать как gpg -vvv -d file, и сразу всё базовое будет видно (страховка от отправки незашифрованным).


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

— Гость (14/04/2012 21:17)   
Заебали писать мелким и прозрачным шрифтом. Протокол это стенограмма, а не ваша попытка стеганографироваться от читателя.
— sentaus (14/04/2012 22:53)   
(опция encrypt тихо проигнорировалась)


Кстати, злополучная команда сохранилась? Вполне вероятно, что вы баг какой-то нашли :)
— spinore (14/04/2012 23:13)   
Гость (14/04/2012 21:17), чтобы не засорять эту тему оффтопиком, ответил вам в /comment52123[link10].
— unknown (15/04/2012 01:01, исправлен 15/04/2012 01:04)   

Да, удалось разобраться. Это не баг и не то чтобы фича. В команде присутствует --sign, а опцию --encrypt в конце забыл просто скопировать и вставить в нужное место, в таком виде и оставил в скрипте. При этом наличие опций --encrypt-to и --hidden-recipient просто тихо игнорируется, gpg не выдаёт никаких сообщений вида: "вы уверены, а зачем вам эти опции, если мы ничего не шифруем, может забыли поставить --encrypt?"

— Гость (02/06/2012 14:34)   
Хорошее решение, спасибо.
Вот немного изменённая версия с помощью стандартных средств убунту, без xbindkey:

  • sudo apt-get install xsel xautomation
cat > "$HOME/signx" <<EOF
#!/bin/sh

xte 'keydown Control_L' 'key a' 'keyup Control_L'
xsel -o | gpg --no-tty -a --no-emit-version -s | head -c -1 | xsel -ib
xte 'keydown Control_L' 'key v' 'keyup Control_L'
xsel -c
xsel -bc
EOF
  • chmod +x "$HOME/signx"
  • System Settings → Keyboard → Shortcuts → Custom Shortcuts → добавить новый, назначить команду /home/ВАШ ПОЛЬЗОВАТЕЛЬ/signx и забиндить хоткей.
— Гость (28/12/2012 05:46)   
spinore, попытался вытворить у себя ваш фокус и обломался, никаких "KeyPress event" в выводе xev не наблюдаю, при нажатии появляется "PropertyNotify event..." и ничего больше. Я правда схитрил, сделал все через два графических терминала под иксами и sudo, но если честно думал так будет еще уязвимей. ЧЯДНТ?
— Гость (28/12/2012 07:10)   

Проверьте для теста в лоб, как написано в инструкции, для начала. Я сейчас перепроверил с двумя графическими терминалами под одними и теми же иксами, когда в одном терминале запускается xev, а в другом уже сделано su -l root (ещё до запуска xev) и производится ввод пассфразы для шифрования gpg симметричным ключом. Т.е. рут шифрует файл, вводит пароль, а юзер этот пароль записывает в FILE. Например, нажатые символы qw отображаются в FILE как
KeyPress event, serial 17, synthetic NO, window 0x1600009,
    root 0x12d, subw 0x160000e, time 242352810, (303,451), root:(303,451),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False
 
KeyRelease event, serial 17, synthetic NO, window 0x1600009,
    root 0x12d, subw 0x160000e, time 242352920, (303,451), root:(303,451),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False
 
KeyRelease event, serial 17, synthetic NO, window 0x1600009,
    root 0x12d, subw 0x160000e, time 242353059, (303,451), root:(303,451),
    state 0x0, keycode 25 (keysym 0x77, w), same_screen YES,
    XLookupString gives 1 bytes: (77) "w"
    XFilterEvent returns: False
 
KeyPress event, serial 17, synthetic NO, window 0x1600009,
    root 0x12d, subw 0x160000e, time 242353059, (303,451), root:(303,451),
    state 0x0, keycode 25 (keysym 0x77, w), same_screen YES,
    XLookupString gives 1 bytes: (77) "w"
    XmbLookupString gives 1 bytes: (77) "w"
    XFilterEvent returns: False
(почему каждый символ дважды — не знаю). Короче, УМВР. Или у вас оба терминала были под su/sudo? Тот терминал, под которым запускается xev, должен соответствовать текущим основным иксам. Могу гипотетически предположить, что как-то влияет тип оконного менеджера, но это вряд ли.
— Гость (28/12/2012 07:50)   
Чтоб делать в лоб, нужно поднимать sshd, а я не хочу.

Давайте по порядку, может я тупой.
1. Запускаю две сакуры (Sakura – эмулятор терминала)
2. В одной пишу su -l root
3. Там же пишу gpg -c .rnd
4. Иду в другую сакуру, пишу xwininfo | grep "Window id", получаю

5. Там же ввожу xev -id 0x3a00004
6. Иду в первый терминал, начинаю вводить пароль
7. Получаю:

И т.д. (надеюсь нигде не спалился :) Причем вот эти PropertyNotify event – именно при нажатии на клавиши появляются.
Ах да, ось конечно далеко не бубунта, но линух. И в файл я не пишу, смотрю все в терминале. Отличий вроде больше нет.
...

Ладно, гружу в VirtualBox Tails, чтоб типа эталон был. Делаю все тоже самое, так вот там на нажатия клавиш вообще никакой реакции от xev.
— Гость (29/12/2012 07:29)   

После запуска xwininfo щёлкаете по выбранному окну (тому, где запущено gpg -c .rnd)?

А если просто, т.е. без всяких ssh и su? Один терминал с xev может ловить нажатия клавиш, которые происходят в другом терминале под тем же юзером?

Может быть, указанное поведение как-то отключается в настройках иксов и в Tails и/или новых версиях иксов отключено. Пусть другие читатели форума проверят. Unknown, у вас работает?
— unknown (29/12/2012 10:33)   
Всё работает, только если после xwininfo щёлкнуть мышью по нужному окну и скопировать оттуда id.
— Гость (29/12/2012 10:42)   
Ну, без этой операции с xwininfo команда xev просто не будет знать, события с какого окна ему слушать.
— Гость (30/12/2012 02:15)   

Естественно, иначе откуда бы реакция на нажатия.

То же самое.

Короче, можно юзать su и sudo, я понял :)
— Гость (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)   
Насколько помню, сама 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)   
Что-то странное, не получается залогиниться в другого юзера на локальной машине через 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)   

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

Уязвимость была даже не по вине программистов VMware. Дело в том, что веб-интерфейс этого менеджера (висит на TCP-порту 9084) использует в качестве веб-сервера
Т.е. за такое надо убивать сразу. Какое ещё «управление виртуалкой из браузера»?! Это для секретуток делают в фирмах, которые принимают заказы «клиентов», а мозги куринные. Управление всем — только с консоли.

Ссылки
[link1] http://www.pgpru.com/comment45227

[link2] https://www.pgpru.com/comment45227

[link3] http://www.pgpru.com/chernowiki/rukovodstva/voprosykandidatyvfaq/anonimnostjobschievoprosy

[link4] http://www.pgpru.com/comment47553

[link5] http://www.pgpru.com/comment17076

[link6] http://www.pgpru.com/comment48146

[link7] http://www.pgpru.com/comment31177

[link8] http://www.pgpru.com/comment18132

[link9] http://www.pgpru.com/comment24254

[link10] http://www.pgpru.com/comment52123

[link11] http://www.pgpru.com/comment57364