SELinux / SEAndroid Exceptions for System Services

When attempting to add System Services for Android 4.4.4, permission may be denied due to the Security Enhanced (SE) Linux Mechanism. Below is a console log output from Android 4.4.4's boot process whilst trying to add a user defined service named 'foo'. Line 3 shows permission denied by SELinux for an 'add' operation.

	11-04 14:40:39.271 312 312 I SystemServer: Foo Service
	11-04 14:40:39.273 312 312 I FooService: Spawned worker thread
	11-04 14:40:39.275 51 51 E SELinux : avc: denied { add } for service=foo scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager
	11-04 14:40:39.276 51 51 E ServiceManager: add_service('foo',48) uid=1000 - PERMISSION DENIED
	11-04 14:40:39.278 312 312 E SystemServer: Failure starting FooService Service
	11-04 14:40:39.278 312 312 E SystemServer: java.lang.SecurityException
	11-04 14:40:39.278 312 312 E SystemServer: at android.os.BinderProxy.transact(Native Method)
	11-04 14:40:39.278 312 312 E SystemServer: at android.os.ServiceManagerProxy.addService(ServiceManagerNative.java:150)
	11-04 14:40:39.278 312 312 E SystemServer: at android.os.ServiceManager.addService(ServiceManager.java:72)
	11-04 14:40:39.278 312 312 E SystemServer: at com.android.server.ServerThread.initAndLoop(SystemServer.java:834)
	11-04 14:40:39.278 312 312 E SystemServer: at com.android.server.SystemServer.main(SystemServer.java:1217)
	11-04 14:40:39.278 312 312 E SystemServer: at java.lang.reflect.Method.invoke(Native Method)
	11-04 14:40:39.278 312 312 E SystemServer: at java.lang.reflect.Method.invoke(Method.java:372)
	11-04 14:40:39.278 312 312 E SystemServer: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:772)
	11-04 14:40:39.278 312 312 E SystemServer: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:585)

view raw gistfile1.sh hosted with ❤ by GitHub

For security, SELinux operates on a whitelist policy where services must be forward declared in an exceptions list in order to be granted permission to run. The intention is to prohibit any unwanted services granted themselves potentially dangerous permissions hence 'enhancing' the overall security and integrity of the operating system. Read more about SELinux here.

There are 2 methods to allow user defined system services

1. Add exceptions entries the the SELinux service list (recommended)

Android's SELinux service list is stored in file:

/external/sepolicy/service_contexts

'foo' can be added to the list as a system service as shown in the snippet below.

	/*
	*
	*/
	drm.drmManager u:object_r:drmserver_service:s0
	dropbox u:object_r:system_server_service:s0
	entropy u:object_r:system_server_service:s0
	ethernet u:object_r:system_server_service:s0
	foo u:object_r:system_server_service:s0
	gfxinfo u:object_r:system_server_service:s0
	hardware u:object_r:system_server_service:s0
	hdmi_control u:object_r:system_server_service:s0
	inputflinger u:object_r:inputflinger_service:s0
	input_method u:object_r:system_server_service:s0
	/*
	*
	*/

view raw gistfile1.txt hosted with ❤ by GitHub

2. Disable the SELinux Mechanism

The SELinux mechanism can be disabled altogether by altering Linux's initialization process. The init.rc found in

/system/core/rootdir/init.rc

must be modified to include setenforce 0. Alternatively, setenforce 1 or removing the command would re-enable SElinux. The command has been included in init.rc under on init in the snippet below.

	#
	# early init commands
	#
	on init
	# disable Security Enhanced Linux
	setenforce 0
	sysclktz 0
	loglevel 3
	#
	# other on init commands
	#

view raw gistfile1.txt hosted with ❤ by GitHub

Python Script for Location Updates

Below is a simple python script to automate location updates to the emulator.

	# Karun Matharu (ksm113@imperial.ac.uk)
	# Imperial College London
	# A simple python telnet script to connect to the emulator on
	# localhost 5554 and issue geo fix commands
	import sys
	import telnetlib
	import getpass
	import time
	import random
	HOST = "localhost"
	PORT = 5554
	TIMEOUT = 2
	# Sleep time between each location update
	TIME_GAP = 4
	# Starting values for longitude and latitude
	lon = 50.000000
	lat = 50.000000
	tn = telnetlib.Telnet(HOST, PORT, TIMEOUT)
	print tn.read_some()
	while (True):
	a = random.random()
	b = random.random()
	lat = lat + a
	lon = lon + b
	s = "geo fix " + str(lon) + " " + str(lat) + "\n"
	tn.write(s)
	print(s)
	time.sleep(TIME_GAP)

view raw gistfile1.py hosted with ❤ by GitHub

Location Updates within a Service

Requesting location updates within a remote service may cause the following exception:

runException Can't create handler inside thread that has not called Looper.prepare()

The requestLocationUpdates() function requires access to a Looper to deal with messages in a queue. When calling this method in a background service, the method may not implicitly have access to the threads Looper. Defining the thread's Looper explicitly by adding an additional argument 'Looper.getMainLooper()' deals with the issue.

	locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 4000, 0, listener, Looper.getMainLooper());

view raw gistfile1.java hosted with ❤ by GitHub

Dealing with System Service Dependencies

As an example of a case where a system service depends on another, below is the constructor for a 'test' service which when constructed, initializes a location manager.

	/*
	Import libraries and variable declarations
	*/
	public TestService(Context context) {
	super();
	mContext = context;
	mWorker = new TestWorkerThread("TestServiceWorker");
	mWorker.start();
	Log.i(TAG, "Spawned worker thread");
	//Initialize the locationManager when the TestService starts
	locationManager = (LocationManager) mContext.getSystemService(Context.LOCATION_SERVICE);
	}
	/*
	Other functions
	*/

view raw gistfile1.java hosted with ❤ by GitHub

The 'test' service requires that the 'LocationManagerService' is running before 'test' is created so that it can successfully initialize  a location manager.

When Android is started, 'init' is a component of the bootloader sequence which initializes a number of daemons which run continuously whilst the operating system is running.

One of those daemons 'Zygote' is the process responsible for starting system services. It does this by executing the initAndLoop() function of the SystemServer Class.

SystemServer located in frameworks/base/services/java/com/android/server/SystemServer.java

In order to ensure 'LocationManagerService' is running before 'test' service, place the 'test' service's addService code anywhere below that of the 'LocationManagerService'.

	//Within initAndLoop()
	if (!disableLocation) {
	try {
	Slog.i(TAG, "Location Manager");
	location = new LocationManagerService(context);
	ServiceManager.addService(Context.LOCATION_SERVICE, location);
	} catch (Throwable e) {
	reportWtf("starting Location Manager", e);
	}
	try {
	Slog.i(TAG, "Country Detector");
	countryDetector = new CountryDetectorService(context);
	ServiceManager.addService(Context.COUNTRY_DETECTOR, countryDetector);
	} catch (Throwable e) {
	reportWtf("starting Country Detector", e);
	}
	}
	/*
	Register Other Services
	*/
	//Register Test Service
	try {
	Slog.i(TAG, "Test Service");
	ServiceManager.addService("test", new TestService(context));
	} catch (Throwable e) {
	Slog.e(TAG, "Failure starting TestService Service", e);
	}

view raw gistfile1.java hosted with ❤ by GitHub

GPS Location updates in AOSP Emulator

Mock GPS location values can be set once the emulator is running by connecting to the virtual device via telnet on port 5554 and using the 'geo fix' command to set longitude and latitude values.

	$ telnet localhost 5554
	$ geo fix <longitude> <latitude>

view raw gistfile1.sh hosted with ❤ by GitHub

More info at http://developer.android.com/tools/help/emulator.html

Using Google Cloud Messaging with AOSP

Google Cloud Messaging for Android (GCM) may have once an open source library within AOSP but the service has since been superseded by GCM within Google Play Services.

Google Play Services being proprietary software is not included in AOSP hence using GCM with open code requires use of the now deprecated GCM library.

The GCM repository is available from 
https://code.google.com/p/gcm/source/checkout 


As I am using GCM on the client side, the folder of interest to me is gcm/gcm-client-deprecated


If using GCM within the android's services, the library must be included to be built with the Android framework by copying it to the framework directory.

	% git clone https://code.google.com/p/gcm/
	% mkdir <AOSP directory>/frameworks/base/core/java/android/gcm
	% cp -r gcm/gcm-client-deprecated/* <AOSP directory>/frameworks/base/core/java/android/gcm

view raw gistfile1.txt hosted with ❤ by GitHub

After rebuilding Android, GCM would be included in the framework and can be imported by apps/services eg. if using the GCM Registrar, import as follows.

	/*
	..
	other imports
	..
	*/
	import com.google.android.gcm.GCMRegistrar;
	/*
	..
	Class code
	..
	*/

view raw gistfile1.java hosted with ❤ by GitHub