I am trying to add a native service written in C++ to the AOSP build.
The first thing I did was to create a native service and client to the AOSP build.
This worked as expected. I could start the service within an adb shell and call it via binder on a adb shell.
The trouble started when I wanted to start my service with init.
I added a .rc file to my build
service myp /system/bin/myp_service
class main
This did the the trick so that init tried to start it but it failed because of SELinux policies.
So I added a file_contexts
to my device tree and added:
/system/bin/myp_service u:object_r:myp_exec:s0
Next I added a myp.te file and added:
type myp, domain;
type myp_exec, exec_type, file_type;
type myp_service, service_manager_type;
init_daemon_domain(myp)
net_domain(myp)
binder_use(myp)
binder_service(myp)
add_service(myp, myp_service)
binder_call(myp, binderservicedomain)
binder_call(myp, appdomain)
allow myp myp_service:service_manager add;
And finally I added a service_contexts
file with:
myp u:object_r:myp_service:s0
This finally made my service successfully start at boot time. Unfortunalty I cannot use binder against this service. When I try to connect to the service with my client the call
defaultServiceManager()->getService(String16("Demo"))
returns a null pointer.
I cannot find any hints in the dmesg
.
So I assume I am still missing something for the SElinux but I have no clue what I am missing.
If I shutdown the SELinux with setenforce
and restart the service then it works fine.
Can anyone give me a hint what I am missing for SELinux or where I can get more information about which policy blocked something?
You could see the denials like this:
adb logcat | grep "SELinux : avc" > /tmp/logs
adb pull sepolicy
.audit2allow
(located in AOSP source code: external/selinux/prebuilts/bin/audit2allow or in SDK tools. Do this: cat /tmp/logs | .external/selinux/prebuilts/bin/audit2allow -p sepolicy
The audit2allow tool will tell you what permission you are missing for the logcat extracted and the current sepolicy file, watch-out because you could need to do this several times since fixing some permissions will show the next ones required.
If you have a userdebug kind of build you could get setenforce 0
, logcat with it and all the denials will be in logcat even if you will be permited to do the operation desired. This will leave the audit2allow iterations required in 1.