4. Android Security Model

The Android Security Model combines two key access control mechanisms: DAC (Discretionary Access Control) and SELinux (Mandatory Access Control). DAC allows users to control access to their files based on ownership and permissions. SELinux, on the other hand, enforces stricter system-wide security policies, limiting what actions processes and apps can perform, even if they have the necessary permissions. Together, these models enhance Android's security by balancing flexibility and strict control.

Linux Security Model (DAC - Discretionary Access Control):

• The Linux Security Model is the foundation of Android's security framework and uses DAC (Discretionary Access Control). Under this model, each file and resource on the system has an owner, and the owner has the discretion to set permissions on their resources (read, write, execute).

• DAC is implemented in the Linux kernel and is fundamental to enforcing access control for files, processes, and devices in Android. This model ensures that system resources are accessed only by authorized users and processes based on file permissions.

SELinux Security Model (MAC - Mandatory Access Control):

• SELinux (Security-Enhanced Linux) is an advanced security module integrated into the Linux kernel, which is also a fundamental component of Android’s security model. SELinux implements MAC (Mandatory Access Control), providing an additional layer of security on top of the traditional DAC (Discretionary Access Control).

• In MAC, access decisions are not based on user or application discretion, but are enforced by security policies set by the system administrator or security framework. These policies define what each process and user can or cannot do, even if the user has ownership or control over a resource.

Key Features of SELinux in Android:

• Enforcement of Security Policies: SELinux restricts the actions of processes and users by enforcing security policies that govern what is allowed on the system. It operates as an additional access control layer beyond the basic file permissions.

• Security Contexts: Every process and resource (like files and directories) is assigned a security context, which contains labels and identifiers that define the level of access allowed. These contexts are based on SELinux policies, ensuring that only authorized processes can access or modify protected resources.

History of SELinux in Android:

• Android 4.2.2: and blew did not support SELinux.

• Android 4.3: SELinux was introduced in permissive mode for testing purposes.

• Android 5.0 (Lollipop): SELinux was fully enabled and enforced by default on Android devices, strengthening the overall security of the platform.

Modes of SELinux:

1. Enforcing:

   • In enforcing mode, SELinux policies are strictly enforced. Any action that violates the security policies will be denied, and the system will log the violation.

   • Example: If a process attempts to access a file it doesn’t have permission to access according to the policy, the action will be blocked, and a log entry will be created for review.

2. Permissive:

   • In permissive mode, SELinux does not deny any actions. Instead, it logs violations for audit purposes, allowing administrators to observe potential security issues without enforcing policies.

   • This mode is useful for debugging or testing, but it is less secure since no actions are blocked.

3. Disabled:

   • In disabled mode, SELinux is completely turned off, and no policies are applied. This is typically used for troubleshooting or if SELinux needs to be temporarily disabled for compatibility reasons.

SELinux Types:

1. Default:

   • The default type is the standard security policy applied to most processes and resources on the system. It provides basic security without any advanced constraints or role-based requirements.

2. MLS (Multi-Level Security):

   • MLS is a more advanced security policy used in environments that require multiple levels of classification and clearances (e.g., government or military systems). It provides additional layers of access control to ensure that users and processes can only access data that matches their security clearance level.

3. SRC (Strict/Role-Based Access Control):

   • SRC focuses on the roles and behaviors of users or processes. It enforces strict access control policies based on the roles assigned to processes, ensuring that each role can only perform the actions allowed by its defined role.

Permission Categories:

In Android, permissions regulate access to various resources, including sensitive user data, system functionalities, and hardware. Permissions are classified into three categories:

1. Normal Permissions:

   • These permissions do not pose a risk to user privacy or device integrity. The system automatically grants these permissions without needing user approval. Examples include permissions to set the device’s wallpaper or change the system's time settings, Vibrate and ACCESS_NETWORK_STATE.

2. Dangerous Permissions:

   • Dangerous permissions involve access to sensitive data or functions that could affect user privacy or security. These permissions require explicit user consent at runtime. For instance, accessing the device's camera, microphone, or location requires the user to approve the request during app usage. Examples include:

     • ACCESS_FINE_LOCATION: Allows access to precise location data.

     • READ_CONTACTS: Allows access to the user's contacts.

3. Signature Permissions:

   • These permissions are granted only if the app requesting them is signed with the same certificate as the app that declared the permission. This category is commonly used for system or suite apps that need to interact securely. For example, an app that shares certain functionalities with another app signed by the same developer might request signature-level permissions.