-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathREADME.android
82 lines (67 loc) · 3.74 KB
/
README.android
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
From https://wiki.ubuntu.com/Touch/ContainerArchitecture:
"On the Ubuntu Touch images we run the Android HAL (Hardware Abstraction Layer)
in a container to make use of the binary drivers and some daemons that are
needed to drive the builtin hardware of a phone."
The current approach is, as mentioned, to start a container with the Android
HAL, and then applications use libhybris to talk to the container. On Ubuntu
Touch, typically the only applications needing to talk to the container are
services rather than the apps themselves (ie, the app talks to a service (eg,
media-hub, media-hub uses the libhybris API, which then talks to the
container). Well-behaved applications that 'talk to the container' may do so in
one of two ways:
* use binder IPC via /dev/binder to communicate with a binder service in the
container
* use libhybris to access functionality of the libraries in the container (eg
in /system/lib)
The contents of the container are a pruned set of binaries from the 'android'
source package (in multiverse) and can be found in /system on an AOSP (Android
Open Source Project) based system. As such, Android CVEs may affect Ubuntu
under certain circumstances.
The projects that the android source package pulls from are: Android Open
Source Project, CyanogenMod, and ClockworkMod.
binder
------
To see what is listening on /dev/binder on an AOSP device (eg, Nexus 4):
$ sudo lxc-console --name android -t0
root@mako:/ # lsof | grep /dev/binder
healthd 15 root 5 ??? ??? ??? ??? /dev/binder
servicema 16 system 3 ??? ??? ??? ??? /dev/binder
servicema 16 system mem ??? 00:10 0 11649 /dev/binder
rild 20 radio 17 ??? ??? ??? ??? /dev/binder
drmserver 21 drm 3 ??? ??? ??? ??? /dev/binder
camera_se 22 media 7 ??? ??? ??? ??? /dev/binder
sensorser 31 root 3 ??? ??? ??? ??? /dev/binder
An application that uses binder directly does not pull in any android code into
its process space.
libhybris
---------
libhybris is essentially a wrapper library around the android libraries in the
container so it can provide a stable API for Ubuntu applications to use when
they need to access android libraries. It is important to remember that
libhybris wraps only a very small subset of the android library API (just
enough for the few things that the libraries are needed for). Also, an
application that uses libhybris will also pull in the required android
libraries into its process space.
CVE Triage
----------
It is a little more difficult to see what the android side uses because
everything is statically linked. However, if you know the affected code and
what library it is in, you can find this out. Eg:
$ ps auxww | grep '/system/' # for what is running in the container
system 1399 0.0 0.0 1356 240 ? S 10:01 0:00 /system/bin/servicemanager
9999 1400 0.0 0.0 2488 380 ? Sl 10:01 0:00 /system/bin/rmt_storage
root 1402 0.0 0.0 1380 300 ? S 10:01 0:00 /system/bin/debuggerd
radio 1403 0.0 0.1 14728 3204 ? Sl 10:01 0:02 /system/bin/rild
...
and/or look to see what is listening on binder (see above).
Then go into the android source for each service and/or see if the affected
library is linked in to each service. Eg, to see if stagefright is linked into
rild:
$ find . -name "rild*"
./device/lge/mako/sepolicy/rild.te
./device/asus/grouper/sepolicy/rild.te
./external/sepolicy/rild.te
./hardware/ril/rild
./hardware/ril/rild/rild.c
$ grep stagefright ./hardware/ril/rild/Android.mk
$