The incorporation of Security-Enhanced Linux in Android (SEAndroid) is an important security enhancement to the platform. Android is built on top of the Linux kernel, with a collection of traditional and customized Linux libraries and daemons. ....

1. ANDROID SECURITY
‫مدرس‬ ‫تربیت‬ ‫دانشگاه‬ ‫داده‬ ‫پایگاه‬ ‫امنیت‬ ‫درس‬ ‫کالسی‬ ‫ارائه‬
‫دهندگان‬ ‫ارائه‬:
‫آمون‬ ‫مهرناز‬
‫محمدی‬ ‫کاوه‬
‫درس‬ ‫استاد‬:
‫نوگورانی‬ ‫دری‬ ‫صادق‬
‫اول‬ ‫نیمسال‬۹۷-۹۸
1

2. SEANDROID (1/2)
• The incorporation of Security-Enhanced Linux in Android (SEAndroid) is an important security
enhancement to the platform.
• Android is built on top of the Linux kernel, with a collection of traditional and customized Linux
libraries and daemons.
• Early versions of Android relied on Unix’s discretionary access control (DAC) mechanism to protect
daemon-specific resources as well as to isolate apps from one another.
• Security-Enhanced Linux (SELinux), which adds mandatory access control (MAC), has been
integrated into Android to harden the security of the lower layer of Android, resulting in
SEAndroid
• Android Open Source Project (AOSP)
2

3. SEANDROID (2/2)
• SEAndroid enforcement was first adopted in Android version 4.4, but with a
minimally restrictive policy
• Samsung
• HTC
3

4. BASIC CONCEPTS OF ANDROID ACCESS CONTROL POLICY (AACP)
• Android Access Control Policy:
• app permissions,
• middleware MAC,
• Linux DAC,
• and kernel-level MAC (implemented in the SELinux LSM module).
4

5. SEANDROID
• SEAndroid supports three access control models:
• Type Enforcement (TE),
• Role-Based Access Control (RBAC) [22],
• and Multi-Level Security (MLS)
5

6. SECURITY LABEL (1/2)
• In SEAndroid, every subject or object has a security label in the format of
user:role:type:security level.
• The first element represents the user in SEAndroid, the second element role is for
RBAC, the third element type is for TE, and the last element security level is for MLS.
An example of security label is u0:object r:app data file:s0.
• allow Domain Type : Class { Permissions } An example rule is allow untrusted app
system app data file : file { read write } , which allows the domain untrusted app to
read and write files of type system app data file. N
6

7. SECURITY LABEL (2/2)
• SEAndroid includes important context files for labelling subjects and objects in
the system. One such file is file contexts for labelling the file system, and
another is seapp contexts for labelling processes and their related data.
• Each permission group has three characters that represent the read (r, or 4 as
an integer), write (w, or 2), and execute (x, or 1) permissions, respectively.
Therefore, if a file’s permission is set to “r--------” or 400, it means that only
the owner of the file can read it.
7

8. SEANDROID POLICY
• An SEAndroid policy is P𝑀𝐴𝐶 = (𝐿𝑠, 𝐿𝑜, 𝑀𝐿, 𝑆, 𝑂, 𝐴, 𝑀𝐴, 𝑅)
• 𝐿𝑠 and 𝐿𝑜 are the sets of security labels of subjects and objects,
• 𝑀𝐿 : 𝐿𝑠 ∪ 𝐿𝑜 ↦→ 𝑆 ∪ 𝑂 is a mapping for assigning security labels to subjects and
objects
• 𝐴 = {𝑎} is the set of attributes, s.t., 𝐴 ⊂ 𝐿𝑠 ∪ 𝐿𝑜
• 𝑀𝐴 : 𝐿𝑠 ∪ 𝐿𝑜 ↦→ 2 𝐴 is a mapping from security labels to their attribute set
• 𝑅 = {𝑟} is a set of SEAndroid policy rules (defined below).
8

9. SEANDROID POLICY RULE
• An SEAndroid policy rule is a tuple 𝑟 = (𝑙𝑠, 𝑙𝑜, 𝑐𝑟, 𝑃𝑟)
• where 𝑙𝑠 ∈ 𝐿𝑠 is the subject security label (i.e., domain)
• 𝑙𝑜 ∈ 𝐿𝑜 is the object security label (i.e., type)
• 𝑐𝑟 is the object class
• and 𝑃𝑟 is the permission set granted by 𝑟 when subjects with label 𝑙𝑠 access objects with
label 𝑙𝑜.
9

10. DAC RELATED DATA
• To dump file entries for DAC permissions, we use the command:
“adb shell ls -aRZ ”
from the root directory of a phone. Note that the phone must be rooted to list the whole file system,
otherwise only part of the file entries in the phone can be obtained and thus the analysis results may
be incomplete.
• A file pubkey blacklist.txt under the directory /data/misc/keychain/ has read and write
permissions for its owner, read for its group members, and read for all others, respectively. Its user
and group are both system, and its security label is keychain data file. 10

11. MAC RELATED DATA (1/2)
• Pull the SEAndroid policy binary from an Android device through the command
“adb pull sepolicy”
Then we employ SETools to recover rules from the extracted binary with the command “sesearch -A
sepolicy” 2
11

12. POLICIES TO BE ANALYZED
These statistics show that through the evolution of SEAndroid policies, Android 4.4 is quite different from
the later versions, and that the versions after Android 5.0 become more stable, although Android 6.0
adds revisions due to new features like fingerprint.
12

13. EXAMPLES OF COMPOSITIONAL PRIVILEGE
ESCALATION IN DIFFERENT AOSP POLICIES
13

14. EXAMPLES OF TYPES WITH DIFFERENT GLOBAL
PERMISSIONS IN DAC IN DIFFERENT AOSP POLICIES
14

15. STATISTICS OF SEANDROID POLICIES (ANDROID
5.0) FROM DIFFERENT OEMS
15

16. COMMANDS FOR COLLECTING DATA
16

17. CONTROL YOUR APP PERMISSIONS ON ANDROID
6.0 AND UP
• When you install an app from Google Play on a device running Android 6.0 and up or on a
Chromebook, you control which capabilities or information that app can access—known as
permissions. For example, an app might want permission to see your device contacts or
location. You can control which permissions an app can access after the app installs on your
device.
• Turn permissions on or off
You can change the permissions that apps can access in the main Settings app on your device at
any time. Keep in mind turning off permissions may cause apps on your device to lose
functionality.
17

18. APP PERMISSIONS FOR ANDROID 6.0 AND UP
• Below are the app permissions available on Android 6.0 and up. The permissions you see on your device may vary by
manufacturer.
• To review the permissions on your device, follow the instructions under "Turn permissions on or off" above.
• Body Sensors
• Calendar
• Camera
• Contacts
• Location
• Microphone
• Phone
• SMS
• Storage
18

19. PERMISSIONS OVERVIEW
• The purpose of a permission is to protect the privacy of an Android user.
Android apps must request permission to access sensitive user data (such as
contacts and SMS), as well as certain system features (such as camera and
internet). Depending on the feature, the system might grant the permission
automatically or might prompt the user to approve the request.
19

20. PERMISSIONS OVERVIEW
• A central design point of the Android security architecture is that no app, by
default, has permission to perform any operations that would adversely
impact other apps, the operating system, or the user. This includes reading or
writing the user's private data (such as contacts or emails), reading or writing
another app's files, performing network access, keeping the device awake,
and so on.
20

21. SEE ALL PERMISSIONS FOR EACH APP
• For apps installed on your device
On your device, open the main Settings app .
Tap Apps or Application Manager (depending on your device, this may look different).
Tap the app you want to update.
Tap Permissions.
Turn permissions on or off.
• For instant apps
On your device, open the Settings app .
Go to Google Instant Apps.
Tap the app you want to see more about.
Look under “Permissions”.
21

22. PERMISSION APPROVAL
• An app must publicize the permissions it requires by including <uses-
permission> tags in the app manifest. For example, an app that needs to send
SMS messages would have this line in the manifest:
22

23. RUNTIME REQUESTS (ANDROID 6.0 AND HIGHER)
• If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is
23 or higher, the user isn't notified of any app permissions at install time. Your app must ask
the user to grant the dangerous permissions at runtime. When your app requests permission,
the user sees a system dialog (as shown in figure 1, left) telling the user which permission
group your app is trying to access. The dialog includes a Deny and Allow button.
• If the user denies the permission request, the next time your app requests the permission, the
dialog contains a checkbox that, when checked, indicates the user doesn't want to be
prompted for the permission again (see figure 1, right).
23

24. RUNTIME REQUESTS (ANDROID 6.0 AND HIGHER)
24

25. INSTALL-TIME REQUESTS (ANDROID 5.1.1 AND BELOW)
• If the device is running Android 5.1.1 (API level 22) or lower, or the app's
targetSdkVersion is 22 or lower while running on any version of Android, the
system automatically asks the user to grant all dangerous permissions for your
app at install-time (see figure 2).
25

26. INSTALL-TIME REQUESTS (ANDROID 5.1.1 AND BELOW)
26

27. NORMAL PERMISSIONS
• Normal permissions cover areas where your app needs to access data or resources outside the
app's sandbox, but where there's very little risk to the user's privacy or the operation of other
apps. For example, permission to set the time zone is a normal permission.
• As of Android 9 (API level 28), the following permissions are classified as PROTECTION_NORMAL:
ACCESS_LOCATION_EXTRA_COMMANDS
ACCESS_NETWORK_STATE
ACCESS_NOTIFICATION_POLICY
ACCESS_WIFI_STATE
BLUETOOTH
BLUETOOTH_ADMIN
27

28. DANGEROUS PERMISSIONS AND PERMISSION GROUPS.
28

29. SIGNATURE PERMISSIONS
• The system grants these app permissions at install time, but only when the app that attempts to use a permission
is signed by the same certificate as the app that defines the permission.
• As of Android 8.1 (API level 27), the following permissions that third-party apps can use are classified as
PROTECTION_SIGNATURE:
BIND_ACCESSIBILITY_SERVICE
BIND_AUTOFILL_SERVICE
BIND_CARRIER_SERVICES
BIND_DEVICE_ADMIN
BIND_INCALL_SERVICE
BIND_INPUT_METHOD
BIND_MIDI_DEVICE_SERVICE
BIND_NFC_SERVICE
BIND_NOTIFICATION_LISTENER_SERVICE
BIND_PRINT_SERVICE
29

30. ‫منابع‬
• Chen, Haining, Ninghui Li, William Enck, Yousra Aafer, and Xiangyu Zhang.
"Analysis of SEAndroid Policies: Combining MAC and DAC in Android."
In Proceedings of the 33rd Annual Computer Security Applications Conference,
pp. 553-565. ACM, 2017.
• developer.android.com
• support.google.com
30