[android-security-discuss] SELinux help for new system app

[GPS]

I have a new system service that needs to access a protected system file
/dev/mydev0.

I was able to setup policies for a native daemon to access this file. But
daemon is started from init*.rc file. This works because init.rc files can
specify a SELinux domain to assign to daemon.

How do I start my android service so that service will be assigned a
specifc SELinux domain? Can an android service be launched from init.rc?

Alternatively, if I launch my service on BOOT_COMPLETED intent, how do
assign it correct SELinux domain?

I also asked
here: http://stackoverflow.com/questions/33779286/selinux-policy-definition-for-android-system-service-how-to-setup

Thanks

[Stephen Smalley]

Post by GPS
I have a new system service that needs to access a protected system file
/dev/mydev0.
I was able to setup policies for a native daemon to access this file.
But daemon is started from init*.rc file. This works because init.rc
files can specify a SELinux domain to assign to daemon.

You should only need to specify the SELinux context in init.rc if the
daemon executable lives in the rootfs. If it lives in /system, you can
assign it a file context that will trigger a domain transition
automatically in policy without needing to specify a context in init.rc.

Post by GPS
How do I start my android service so that service will be assigned a
specifc SELinux domain? Can an android service be launched from init.rc?
Alternatively, if I launch my service on BOOT_COMPLETED intent, how do
assign it correct SELinux domain?
I also asked
here: http://stackoverflow.com/questions/33779286/selinux-policy-definition-for-android-system-service-how-to-setup

1. You could keep it as a native daemon and have it expose a socket or
binder interface that can be used by apps. You don't have to expose the
device directly to apps at all.

2. If you need to assign a specific domain to a system app, you can use
seapp_contexts for that purpose.

[GPS]

Hi Stephen, Thanks for taking time to reply.

Post by Stephen Smalley
2. If you need to assign a specific domain to a system app, you can use
seapp_contexts for that purpose.

This is precisely what I need help with. I would like to keep a system apk,
instead of a daemon. I have written an apk that implements my service, its
own aidl etc.

This service is meant to be called from apps, which might come from
play-store etc (i.e. will be untrusted/third party, but might consider
signature security etc). Ideally I would like the service to be started or
bound from these apps, but, if required, I can also start the service from
BOOT_COMPLETED intent if it helps.

Can you please guide me on what to modify in seapp_contexts file? I do not
fully understand this file. In AOSP, following are the contents of file
externals/sepolicy/seapp_contexts:

....
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
...

What does it represent? Do all apps started by "system" user get
"system_app" context? How to ensure that a specific *user* owns the process
of the service I am interested in? Or is it the other way around?

Thanks

[Joshua Brindle]

Post by GPS
Hi Stephen, Thanks for taking time to reply.

Post by Stephen Smalley
2. If you need to assign a specific domain to a system app, you can use
seapp_contexts for that purpose.

This is precisely what I need help with. I would like to keep a system apk,
instead of a daemon. I have written an apk that implements my service, its
own aidl etc.
This service is meant to be called from apps, which might come from
play-store etc (i.e. will be untrusted/third party, but might consider
signature security etc). Ideally I would like the service to be started or
bound from these apps, but, if required, I can also start the service from
BOOT_COMPLETED intent if it helps.
Can you please guide me on what to modify in seapp_contexts file? I do not
fully understand this file. In AOSP, following are the contents of file
....
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
...
What does it represent? Do all apps started by "system" user get
"system_app" context? How to ensure that a specific *user* owns the process
of the service I am interested in? Or is it the other way around?

system_app is a domain, as defined in the SELinux policy. Per the
seapp_contexts above all apps that run as the system UID will get the
system_app context. An app is run as the system UID if the
AndroidManifest.xml has android:sharedUserId="android.uid.system".

If your app will not run as the system UID (and it should not, unless
there is a good reason) then the way to run it in a different context is
to either add the signature to mac_permissions.xml (see the setool
program in AOSP) and to give it a unique seinfo, and then use the seinfo
in your seapp_contexts like:

user=_app seinfo=YOUR_SEINFO domain=YOUR_app type=app_data_file
levelFrom=user

However, if it is signed with the platform signing key then you'd need
to use name=, like:

user=_app seinfo=platform name=YOUR_PACKAGE_NAME domain=YOUR_app
type=YOUR_app_data_file levelFrom=user

Does that make sense?

Post by GPS
Thanks

[Stephen Smalley]

Post by GPS
Hi Stephen, Thanks for taking time to reply.
2. If you need to assign a specific domain to a system app, you can use
seapp_contexts for that purpose.
This is precisely what I need help with. I would like to keep a system
apk, instead of a daemon. I have written an apk that implements my
service, its own aidl etc.
This service is meant to be called from apps, which might come from
play-store etc (i.e. will be untrusted/third party, but might consider
signature security etc). Ideally I would like the service to be started
or bound from these apps, but, if required, I can also start the service
from BOOT_COMPLETED intent if it helps.
Can you please guide me on what to modify in seapp_contexts file? I do
not fully understand this file. In AOSP, following are the contents of
....
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
...
What does it represent? Do all apps started by "system" user get
"system_app" context? How to ensure that a specific *user* owns the
process of the service I am interested in? Or is it the other way around?

First, if you haven't already seen them, let me point you to some
resources for Android SELinux information:
SELinux in Android, https://source.android.com/security/selinux/index.html
SE for Android web site, http://seandroid.bitbucket.org/index.html
SE for Android mailing list, subscribe via email to
seandroid-list-***@tycho.nsa.gov
SELinux mailing list, subscribe via email to selinux-***@tycho.nsa.gov
Presentation from ABS2014 (slides 29- on Labeling Apps),
http://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf

Yes, by default, all apps that run with the system UID (if they specify
that in their manifest, via sharedUserId) are automatically placed into
the system_app domain, and likewise for other predefined platform UIDs.
However, most apps do not need to specify a particular UID and will
just run in a system-selected app UID, which corresponds to the entries
with user=_app in seapp_contexts. You can run your app in a specific
domain by specifying an entry that also includes a name= field with your
app's package name, but you'll need to then also specify a seinfo= field
that ties the app to a particular signature (which you can add to
mac_permissions.xml if it is not already defined).

Suggest taking follow-ups to seandroid-list.