init warning: Service myservice needs a SELinux domain defined. Please fix

Question

I want to excute an executable on boot On a target board with Android 5.1 so I add this in init.rc:

on boot
    start myservice

service myservice /system/bin/myservice
    #class main
    user root
    group root
    #oneshot   

I did the unpack and repack job.
When changes are made, however, the screen keeps printing:

 init warning: Service myservice needs a SELinux domain defined. Please fix.
 type=1400 ... avc:denied ... scontext ... tcontext ... #some annoying warning messages like this

SELinux seems a huge project for me. I just want to avoid that. I tried two approaches:

1. setenv kernelargs 'console=ttyS0,115200n8 rootdelay=1 selinux=0' and saveenv
2. set enforce 0

For method 1, printenv gives the result:

kernelargs=console=ttyS0,115200n8 rootdelay=1 selinux=0

So you see, changes have been made. But the warning messages keeps printing after rebooting.
For method 2, it says:

Could not set enforce status. Permission denied.

So now I'm trapped in the dilema have no idea where to go. My questions:

• 1. Anyone knows how to disable or set permissive mode in android?
• 2. Which files should I modify if I want to define domain for the new service?

Besides, ls -Z /system/bin/myservice gives this:

u:object_r:system_file:s0

Sayers

Answer 1

1. you need su to set permissive mode. Or you need source code to disable SELinux, such as disable SELinux in kernel config, or disable SELinux in BOARD_KERNEL_CMDLINE in device/vendor_name/product_name/BoardConfig.mk.

2. if you have the source code, you can define the new domain as you wish.

Please refer to the Android official documents: https://source.android.com/security/selinux/device-policy

section: Label new services and address denials

Warrantee

Since my username is root so I think I have root privilege. My collegue told me that I still need su. After su, I successfully set permissive mode. While for another problem, seems to me that define a new domain is so much a problem: source code should be modified and android should be recompiled. And my whole project should be recompiled. – Sayers

Answer 2

You have to add the seclabel attribute to the service in your init.rc file, but I don't know if your context will work. I just implemented it myself with the init_exec context:

$ grep yourservice system/sepolicy/file_contexts
/system/bin/vpd u:object_r:init_exec:s0

$ ls -Z path/to/system/bin/yourservice
u:object_r:init_exec:s0 path/to/system/bin/yourservice

$ grep yourservice device/brand/product/init.rc  -A 5
service yourservice /system/bin/yourservice
    seclabel u:r:init:s0
    user root
    group root
    oneshot

Disabling SELinux on Android isn't hard and there are many threads treating the question. Just add either one of the following to your kernel command line parameters (i.e bootargs in U-Boot):

androidboot.selinux=permissive
androidboot.selinux=disabled

Maples

Answer 3

Run into a very similar problem myself, and here's what I've found:

When you run ls -Z /system/bin/myservice and get this:

u:object_r:system_file:s0

it means that your file is in the system_file domain. Now that's not good, as system files are not supposed to be executed, or at last not during init (you may still be able to execute it later from terminal the usual way).

In my case I was lucky, 'cause I was replacing an existing system service with a customised one that I've compiled from source. This means I was able to check the security context of the original file I was replacing and that was from ls -Z /system/bin/myservice.bak :

u:object_r:myservice_exec:s0

So I updated my new file to the same using chcon u:object_r:myservice_exec:s0 /system/bin/myservice

After that it was working fine.

If you want to create a brand new service you may need to use a domain that exists in your sepolicies already, as simply setting it to myservice_exec, won't help, as that would be a non-existing domain in your case. If I were in your shoes and wanted to avoid defining custom policy I might try to find a service with similar security, check the domain on that and try to set the same to my service. init_exec may be a good candidate, but your mileage may vary...

Verena