Кто шарит в #Wayland? Один из его механизмов безопасности...

Кто шарит в #Wayland?

Один из его механизмов безопасности - доступ к буферу обмена есть только у окна в фокусе, если я правильно понял. Или неправильно?

Если правильно, то значит ли это, что если я буду альт табиться между окнами, то все считают мой пароль?

В общем, как оно тут?

И отсюда два вопроса - а как же работают менеджеры буфера обмена? А что мешает evil programm прикинуться таким же буфером обмена?

Like 1 February at 20:55 | Open on lor.sh

10 comments

mittorn

@umnik
>А что мешает evil programm прикинуться таким же буфером обмена?
То, что ему не место на локалхосте? Wayland хоть т упрощает изоляцию, но не пытается быть полностью секурным в этом плане. Даже в более-менее секурных средах вроде оконного менеджера андройда буффер обмена можно прочитать втихушку. В идеале для менеджеров паролей сделать отдельный интерфейс (вероятно, wayland протокол), который отдаст пароль выбранному клиенту целенаправленно

1 February at 21:25 | Open on masturbated.one

Umnik

@mittorn в Андроид это сложнее.

Начиная с 10, доступ к буферу обмена имеют только IME (клавиатура, простыми словами), установленная по умолчанию (то есть 100 других клавиатур не имеют уже) и окно, находящееся в фокусе.

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

Таким образом в Андроиде нет менеджеров буфера обмена как класс приложений. Его реализуют (именно менеджмент) сами клавиатуры.

1 February at 21:31 | Open on lor.sh

mittorn

@umnik
Даже в android злоумышленник может запустить своё активити находясь сервисом в фоне и забрать текст. Так же может получить фокус оверлейное окно и у него будет возможность читать буффер. У меня так работает с окном терминала отладчика - там есть кнопка "вставить" и она программно получает текст из буффера.
Помимо этого accessibility service может получить доступ по идее.
то, что такой менеджер буффера обмена не пустят в google play это уже отдельный вопрос. Но проще реализовать в IME коненчо, на то он и сделан.
кстати, интересно, можно ли InputMethodService другой клавиатуры создать из IME-враппера и таким образрм добавить менеджер буффера обмена уже к существующему IME? Я пока так не пробовал, но идея интересная

Expand text...

1 February at 21:44 | Open on masturbated.one

Umnik

@mittorn запуск активити из фона также запрещён в последних версиях андроида. Нужен специальный пермишен для этого.

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

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

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

Плюс к этому ацесебилити сервис тоже требует специальных разрешений для работы.

Про враппер не понял идею, честно говоря. Как бы то ни было, проверяется именно на выставление клавы по умолчанию. То есть включенная, но не выбранная клавиатура доступа иметь не будут.

Expand text...

1 February at 21:50 | Open on lor.sh

mittorn

@umnik
>запуск активити из фона также запрещён в последних версиях андроида. Нужен специальный пермишен для этого.
Не сталкивался. Это с какого API?
Насчёт тапов под оверлеями - да, скрытно украсть буффер не получится. Но когда текст будет украден - это не имеет значения. Конечно очевидно, что все эти оверрлеи требуют разрешений, но это может быть приложение которое использует оверлеи для чего-то нужного пользователю. Опять же - пытаться делать компромисс в виде ограничения действий неловеренных приложений - глупая задача. Это должно быть или совсем что-то урезанное, что может работать только на переднем плане как на android go, либо давать разрешения, предполагая уже что доверяешь софту (как можно доверять 100+ мегабайтам лапши на котлине я правда мало себе представляю, там разраб то своим зависимостям доверять не имеет права...)
Про враппер я имел в виду следующее: заспавнить и забиндить сервис клавиатуры (другого пакета) из своего InputMethodService, и прокинуть ему интерфейс InputConnection. Но я боюсь, что не получится добавить его view в своё окно в таком случае

Expand text...

1 February at 22:00 | Open on masturbated.one

Umnik

@mittorn запуск активити из фона ограничен в 10 и выше. Но есть ряд послаблений, среди которых - если ты биндишься к некоторым системным сервисам: https://developer.android.com/guide/components/activities/background-starts Фореграунд сервисы же сюда не входят. Но при этом пендинг интент от сервиса (юзер тапнул на уведомление) таки может запустить активити. Но это уже прямое взаимодействие с компонентом

1 February at 22:08 | Open on lor.sh

mittorn

@umnik старнно - а у меня работает при условии что выставлен ACTIVITY_FORCE_NEW_TASK.
Может дело в том, что я инициирую запуск из AccessibilityService?

1 February at 22:19 | Open on masturbated.one

Umnik

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

Вообще биндинг к ацесебилити даёт право запускать как минимум свои активити из фона. Может и чужие тоже, ХЗ.

1 February at 22:22 | Open on lor.sh

mittorn

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

1 February at 22:25 | Open on masturbated.one

mittorn

@umnik понятное дело, что в контексте "доаверять 100+мегабайтной лапше на котлине нельзя", которое гугол сам развёл своими гайдлайнами им проще сделать чтобы в фоне вообще ничего не работало

1 February at 22:22 | Open on masturbated.one