SEPolicy для Android Native Binder клиент - PullRequest
Новая
       57

SEPolicy для Android Native Binder клиент

0 голосов
/ 17 апреля 2019

Я новичок в мире Android

Я хочу знать, как установить SEPolicy для клиентской программы родного связующего (И что же настроить ..)

Я использую ссылку поставщика binder (vndservicemanager) из Использование Binde-IPC

И я добавляю несколько файлов для требуемой SEPolicy

Теперь у меня есть два встроенных исполняемых файла - my_binder_service и my_client

они оба находятся в / vendor / bin /

my_binder_service запускается во время загрузки, и это добавит службу к поставщику servicemanager

my_client - это программа, которая использует binder IPC для выполнения некоторой функции из my_binder_service

Вот мои настройки в init.rc 

service my_binder_service /vendor/bin/my_binder_service
    class main
    class oneshot
    class console
    seclabel u:r:my_binder_service:s0

Что у меня так далеко:

  1. my_binder_service успешно запущен во время загрузки
  2. Может добавить услугу к поставщику servicemanager
  3. my_client ведет себя хорошо при разрешительном режиме

Все вышеперечисленное проверяется в принудительном режиме с помощью ps -AZ и vndservice list command

Однако my_client приводит к ошибке сегментации в принудительном режиме

Я проверяю отклоненное сообщение по 

dmesg | grep avc | grep my_
logcat | grep avc: | grep my_

Но я не нашел ни одного сообщения ни в разрешающем, ни в принудительном режиме

Я также проверяю контексты этих 2 запущенных процессов с помощью ps -AZ : 

u:r:my_binder_service:s0  <- for my_binder_service
u:r:su:s0                 <- for my_client

Я обнаружил, что контекст процесса не установлен правильно для my_client

И я думаю, что это может быть проблема my_client в принудительном режиме

Я думаю, my_binder_service установлен правильно из-за команды seclabel в файле init.rc

Но я не знаю, где установить контекст процесса для my_client

Вот содержимое my_client.te (my_binder_service.te похож на это) 

type my_client, domain;
type my_client_exec, exec_type, file_type, vendor_file_type;

init_daemon_domain(my_client)

allow my_client my_client_exec:file entrypoint;
allow my_client serial_device:chr_file { read write };

vndbinder_use(my_client);
binder_call(my_client, my_binder_service);

и контекст файла указан в file_context file 

/vendor/bin/my_binder_service      u:object_r:my_binder_service_exec:s0
/vendor/bin/my_client              u:object_r:my_client_exec:s0

Чего-то не хватает в части SEPolicy?

Или это не проблема SEPolicy?

1 Ответ

0 голосов
/ 17 апреля 2019

Я нашел решение своего вопроса несколько часов спустя ..

Оказалось, что это не относится к SEPolicy клиентской программы

Сначала я обнаружил, что список vndservice не lisy my_binder_service в принудительном режиме , я перепутал с результатом permissive mode.

Затем я повторно проверяю SOP в С помощью Binder IPC еще раз, чтобы увидеть, пропустил ли я что-нибудь.

А на самом деле! Я скучал по многим вещам ...

Вот все изменения, которые я сделал 

# In vndservice_contexts 
my_binder_service                         u:object_r:my_binder_service:s0

Я думал seclabel в init.rc работает, но оказалось, что эта строка все еще необходима 

# In my_binder_service.te
type my_binder_service, domain, vndservice_manager_type;
allow my_binder_service self:service_manager add;

vndservice_manager_type добавлен и разрешающее правило добавлено на основе logcat | grep avc: результат и audit2allow Команда

Единственное изменение, которое я сделал в my_client.te , - это то, что я удаляю init_domain_daemon () в нем

Поскольку я нахожу это необоснованным после проверки файла te_macros

И, наконец, все работает в принудительном режиме

За исключением того, что контекст процесса для my_client по-прежнему su вместо my_client , что, я думаю, может не иметь отношения к этой проблеме .

Возможно, единственное, что имеет значение для IPC между клиентом и сервером, - это следующие строки 

binder_call(my_client, my_binder_service);
binder_call(my_binder_service, my_client);
...