LINUX.ORG.RU

Защита содержимого буфера обмена от несанкционированного доступа

 , , , ,


2

2

Допустим, есть софт, которому мы не можем полностью доверять. Назовём его, например, Skype, для определённости. Любые совпадения случайны.

Допустим, мы обложили его политиками SELinux и AppArmor и всем, что только бывает. Но Skype постоянно выполняет действия по получению содержимого буфера обмена, аналогично команде *

xclip -out -sel clip
и сливает полученные данные, к примеру, сюда.

Итак, допустим, что у нас в буфере обмена периодически содержатся секретные данные. **

Итак, вопрос: как мы можем защититься от такого несанкционированного доступа, в теории и на практике?

Единственный толковый вариант, который приближённо можно назвать решением, реализован в Qubes OS - защищённый буфер обмена на уровне dom0. Без явного действия со стороны пользователя ни одна гостевая OC (domU) не получит новое содержимое буфера обмена.

---------------------

* Конечно, Skype не вызывает /usr/bin/xclip (выполнение сторонних бинарей недоступно из-за политик доступа), а делает то же, что делает xclip в коде. Насколько я понял, xclip работает через API-вызовы - XOpenDisplay() и т. п.

** Предупрежу предложение пользоваться встроенным в браузер менеджером паролей, который сам сразу вставляет данные в формы на сайтах. Предлагаю пример из другой области: берём токен доступа, сгенерированный github.com для автоматизированных действий от имени вашей учётки; токен нужно вставить в конфиг-файл в текстовом редакторе.

Если бы только буфер обмена, в иксах вообще никакой изоляции нет. Запускай в отдельном, вложенном X сервере, например xephyr.

surefire ★★★
()
Ответ на: комментарий от Andrey_Utkin

Да потому что кроме двух с половиной параноиков это никому и не нужно. Но вообще как вариант можно еще вообще отказаться от «передачи» паролей через буфер обмена - использовать всякие временные файлы и прочие fifo, для браузера использовать дополнения, которые будут дергать пароли из хранилища (того же keepass).

alozovskoy ★★★★★
()
Ответ на: комментарий от Andrey_Utkin

Браузер через плагин кладет пароли в хранилище (и дергает аналогичным образом), временные файлы для тех ситуаций когда пароль нужно из одного места в другое переместить (не могу придумать юзкейсы - наверно почты всякие да аналогичные «сервисы»)

alozovskoy ★★★★★
()
Ответ на: комментарий от alozovskoy

Я ещё не разобрался, что именно вы предлагаете - не соизволите разобрать по шагам?

Если мы запрашиваем токен в браузере, то нам из браузера нужно выносить этот токен, проблема.

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

Andrey_Utkin ★★
() автор топика
Ответ на: комментарий от Andrey_Utkin

Хранилище паролей отдельно, curl отдельно, браузер отдельно. Curl'ом дергаем API GitHub, получаем нужный токен и пишем его в файл (все на уровне shell, браузер не используется).

Браузер при помощи плагина обращается в хранилище паролей, то есть опять все происходит без копипаста а на уровне внутренней магии (взаимодействия компонентов).

Curl получает пароль из хранилища (средствами оболочки, вот пример для keepass http://keepass.info/help/base/cmdline.html, вот какая-то еще консольная обвязка http://kpcli.sourceforge.net/ - не знаю на сколько все это актуально, не пробовал, просто первые линки из поисковой выдачи), шлет запрос в github, полученный токен также средствами shell'а кладет в нужный файл или обратно в хранилище.

alozovskoy ★★★★★
()
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

Во, еще один вариант придумал для GUI-приложений, которые не могут тянуть пароль из хранилища - взять какой-нибудь xdotool, который возьмет пароль из хранилища\файлика и «введет» его в поле ввода приложения.

alozovskoy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.