I want to add multiple services with:
MyService sv1 = MyService::getInstance(mode::mode1);
defaultServiceManager()->addService(String16("Service1"), sv1);
MyService sv2 = MyService::getInstance(mode::mode2);
defaultServiceManager()->addService(String16("Service2"), sv2);
And here are my sepolicy files:
myservice.te:
type myservice, domain, coredomain;
service.te
type my_service, system_api_service, service_manager_type;
I want to register 2 services with different name, so I added these in service_contexts
Service1 u:object_r:my_service:s0
Service2 u:object_r:my_service:s0
But when I run, the logcat return avc error:
E SELinux : avc: denied { add } for pid=431 uid=1000 name=Service1 scontext=u:r:myservice:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=1
I think Service1 and Service2 did not registered to servicemanager, so avd shows default_android_service in tcontext.
How can I register my own services in sepolicy?
Thank you.
I do not have a reference service to check, but maybe you only forgot to use binder_use and add_service.
type myservice, domain, coredomain;
type my_service, system_api_service, service_manager_type;
# Allow myservice to use binder
binder_use(myservice)
# Allow myservice to add the service "my_service"
add_service(myservice, my_service)
Related
Hi I am adding my koushikservice in aospCodebase/frameworks/base/services/java/com/android/server/SystemServer.java like this
KoushikService koushikservice = null;
try{
traceBeginAndSlog("KOUSHIK_SERVICE adding trace");
koushikservice = new KoushikService(mSystemContext);
ServiceManager.addService(Context.KOUSHIK_SERVICE,koushikservice);
}catch(Throwable e){
Slog.e(TAG, "Starting KOUSHIK_SERVICE failed!!! ", e);
}
traceEnd();
I am getting "KOUSHIK_SERVICE adding trace" log but then getting avc denied. Please let me know if you need further info.
You need to add SELinux rules to allow that service. By default SELinux is deny unless explicitly allowed.
Your easiest way forward to do this would be to compare to an existing service and rules for that.
Otherise based on what I added for a service on my case, and assuming that value of Context.KOUSHIK_SERVICE = "koushik" here's roughly what should be added :
File: koushik.te
type koushik, domain;
In file service_contexts, add:
koushik u:object_r:koushik_service:s0
In file service.te add:
type koushik_service, service_manager_type;
In file system_server.te, add:
add_service(system_server,koushik_service)
Lastly, if you want to allow a domain to find and use your service, for example from platform_app, you add in platform_app.te:
allow platform_app koushik_service:service_manager find;
when i add a new service, and find the error as follow:
SELinux : avc: denied { add } for service=xxxManagerService pid=3798 uid=1000 scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0
then i add allow in system_server.te:
allow system_server default_android_service:service_manager { add };
but build error happened:
libsepol.report_failure: neverallow on line 517 of system/sepolicy/public/domain.te (or line 10355 of policy.conf) violated by allow system_server default_android_service:service_manager { add };
libsepol.check_assertions: 1 neverallow failures occurred
Error while expanding policy
out/host/linux-x86/bin/checkpolicy: loading policy configuration from out/target/product/sti6030d111/obj/ETC/sepolicy_neverallows_intermediates/policy.conf
[ 11% 22/200] target thumb C++: libpqcontrol <= vendor/amlogic/common/frameworks/services/systemcontrol/PQ/SSMAction.cpp
what should i do to make it, and pass cts.
Android comes with a long list of neverallow rules that make sure you don't give permissions which break the security of your device. Fortunately, these neverallow rules are well documented in the code. If you look up line 517 in system/sepolicy/public/domain.te you'll find this:
Do not allow service_manager add for default service labels.
Instead domains should use a more specific type such as
system_app_service rather than the generic type.
New service_types are defined in {,hw,vnd}service.te and new mappings
from service name to service_type are defined in {,hw,vnd}service_contexts.
You probably used the audit2allow to create the rule. This seems to be an easy solution at first, but it will almost always result in rule set that is hard to read. In the end there is no other way than understanding the basics of SELinux in Android.
See here for more information.
I cannot give you an example of what to do now as the things you need to do depend on the type of service you want to add.
Note: I am beginner in SELinux policy and followed vndservicemanager by Android
I have a java service(MyService) that starts on the BootComplete receiver.
Now i am adding myservice to ServiceManager in onCreate of MyService.java.
ServiceManager.addService(mysystemservice, mybinder);
As per treble architecture,
I moved my application to vendor image partition by adding below in Android.mk of application.
LOCAL_VENDOR_MODULE := true
I made below changes in OEM SELinux policy, earlier it was written for system service now as i moved application to vendor so made changes for vendor service, providing both old and current SE policy.
Created Context "my_service"
OLD
In private/service_contexts
mysystemservice u:object_r:my_service:s0
NOW
In vendor/common/vndservice_contexts
mysystemservice u:object_r:my_service:s0
Defined Service Type
OLD
In public/service.te
type my_service, service_manager_type;
NOW
In vendor/common/vndservice.te
type my_service, vndservice_manager_type;
Now giving add permission
OLD
In public/servicemanager.te
allow system_app my_service:service_manager add;
NOW
In abc.te
type abc, domain;
type abc_exec, exec_type, vendor_file_type, file_type;
init_daemon_domain(abc)
vndbinder_use(abc)
binder_call(abc, system_app)
add_service(abc, my_service)
allow abc my_service:service_manager find;
allow abc my_service:service_manager add;
After above changes and giving full build I can see my service context is part of out/product/target/vendor/etc/selinux/vndservice_contexts..inplace of out/product/target/system.
But once Myservice.java try to add "mysystemservice" in ServiceManager by
ServiceManager.addService(mysystemservice, mybinder);
I get below **avc denied ** error
E/SELinux: avc: denied { add } for service=mysystemservice pid=7588 uid=1000 scontext=u:r:system_app:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0
2019-11-14 12:44:39.613 592-592/? E/ServiceManager: add_service('mysystemservice',b0) uid=1000 - PERMISSION DENIED
As we can see in log above Target context is taking default "tcontext=u:object_r:default_android_service:s0" inplace of "my_service"
Note: If i keep changes for system image everything works fine only issue is when i move SE policy changes to vendor.
Please let me know if i missed something or any other way is to add Service.
One problem I can see is that you are using abc.te, but you have not defined this in your seapp_context inside vendor/common/.
You should define something like below:
user=system
seinfo=platform
name=your.package.name
domain=adbc
type=system_app_data_file
After this change avc error will point to abc app domain.
I am getting avc denial issue after giving permission. Error message:
avc: denied { transition } for pid=189 comm="init"
path="/system/bin/androlircd" dev="mmcblk0p9" ino=145
scontext=u:r:init:s0 tcontext=u:object_r:lircd_exec:s0 tclass=process
I have given transition permission in init.te as :
type_transition init lircd_exec:process lircd;
allow init lircd_exec:file execute;
allow init lircd:process transition;
after giving permission also the issue is happening.
Is there any way to solve this. please help.
my androlircd service is as :
service androlircd /system/bin/androlircd
class core
user root
group root system system
seclabel u:object_r:lircd_exec:s0
oneshot
I just got it corrected.
I need to assign selinux labels for the device node that was created,in device.te file. Label for the androlircd service in service.te and edited the service as
service androlircd /system/bin/androlircd
class main
oneshot
Policies were written as required.
I've been looking on SEAndroid, and i've been trying to understand how is a process domain given.
So far what i got is that in the init.rc file, under some of the services declaration, there is a token called seclabel:
service adbd /sbin/adbd --root_seclabel=u:r:su:s0
class core
socket adbd stream 660 system system
disabled
seclabel u:r:adbd:s0
Which later in init.c is being set by setexeccon to the context that was written:
if (svc->seclabel) {
if (is_selinux_enabled() > 0 && setexeccon(svc->seclabel) < 0) {
ERROR("cannot setexeccon('%s'): %s\n", svc->seclabel, strerror(errno));
_exit(127);
}
}
In the example above the domain will be adbd.
But i didnt get to find what happens when there is no seclabel token in the service declaration. The thing that happens in init.c is that it will not call setexeccon, Meaning.. keep the parents domain?
A call to:
ps -Z
in adb shell, which shows all the processes and their domains, shows otherwise.
For example, the servicemanager in init.rc:
class core
user system
group system
critical
onrestart restart healthd
onrestart restart zygote
onrestart restart media
onrestart restart surfaceflinger
onrestart restart drm
but call to ps -Z shows:
u:r:servicemanager:s0 system 53 1 /system/bin/servicemanager
Whats going on?!
Ok, i looked at the code and finally got the answer!
The file: /external/sepolicy/seapp_contexts found on the root file system in the android image includes the following content:
isSystemServer=true domain=system_server
user=system domain=system_app type=system_app_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=shared_relro domain=shared_relro
user=shell domain=shell type=shell_data_file
user=_isolated domain=isolated_app levelFrom=user
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
user=_app domain=untrusted_app type=app_data_file levelFrom=user
This defines the security settings (outputs) for each process according to some inputs. We can see in this example in the first line:
If its the system server, its domain will be system_server
Or in the last line:
The _app keyword stands for every app which doesn't have a rule associated to it. So by default, applications domain will be untrusted_app and the files belongs to it label will be app_data_file.
More documentation on the syntax of the file is found inside the file.