Hardware platform: Forlinx embedded OKT507-C board

Operating system: Android 10.0

The Version of Forlinx Embedded T507 Board Android system is Android 10.0, with SELinux turned on by default. SElinux, based on the MAC access control model, can better protect our Android systems, such as restricting access to system services, controlling application access to data and system logs, which reduces the impact of malware and prevents the impact on system security due to code defects.

In terms of system security, SELinux is the god of protection, but in terms of software development, SELinux is a double-edged sword.

For example, when we develop an app or increase certain permissions on system services, we must follow the rules of SELinux and set the appropriate security policy for our app, otherwise our app will not have access to data or devices. Let's start with our MAC access control model and take a quick look at the Security Policy for Forlinx Embedded T507 Board Android, and the way to customize the Airplane Embedded T507 Board Android Security Policy.

Access control model DAC, MAC

Access control refers to controlling access to a computer or a resource on a network. Without it, everyone can access any resource. With access control, users must identify, validate, and authorize access to resources before they can actually access them or take action.

The Autonomous Access Control (DAC: Discretionary Access Control) system identifies the user and determines the operational rights that the user has on the object, read, write, exec, based on the permission settings of the object being manipulated. A user who has this object permission, in turn, can assign the permission to another user, which is called Discretionary. The drawback is that the control of permissions is scattered and not easy to manage, for example, it is not possible to simply set uniform permissions on a set of files to a specified group of users.

Forced Access Control (MAC: Mandatory Access Control) MAC was born to compensate for the over-dispersion of DAC permission control. In a MAC model, administrators manage access control. The administrator sets a policy and the user cannot change it. The policy defines which principal can access which object. This access control model increases the level of security because it is policy-based and cannot be performed by any operation that is not explicitly authorized. MAC is developed and implemented in systems that place the highest emphasis on confidentiality. The subject gets a clear marker, and the object gets a classification tag, or security level.

MAC-based SELinux

RELATED LINKS: https://source.android.google.cn/security/selinux

Software typically must run as a Root user account to write data to the original block device.

In a traditional DAC-based Linux environment, if a Root user is compromised, an attacker can use that user's identity to write data to each original block device. Starting with Android 4.3, SELinux has been providing forced access control (MAC) protection for traditional autonomous access control (DAC) environments. As part of the Android security model, Android uses security-enhanced Linux (SELinux) to enforce forced access control (MAC) on all processes, even those running with Root/Super User rights( Linux functionality). For example, you can use SELinux to label these devices so that processes that are assigned Root permissions can only write data to devices specified in the relevant policy. This prevents the process from overriding data and system settings outside of a particular original block device. With SELinux, Android can better protect and restrict system services, control access to app data and system logs, reduce the impact of malware, and protect users from possible bugs in code on mobile devices.

The Forlinx Embedded T507 Board Android system version is Android 10, and SELinux is turned on by default, and even if you get root permission for the system, you can only write data to the devices specified in the relevant policy to better protect and restrict system services and secure the system and data.

Labels, rules, and domains

SELinux relies on tags to match actions and policies. Labels are used to determine what is allowed. Sockets, files, and processes are labeled in SELinux. SELinux makes decisions by referring to two things: the labels assigned to these objects, and the strategy that defines how they interact.

In SELinux, labels take the following form: user:role:type:mls_level, where type is a major part of the access decision and can be modified by forming other components of the label. Objects are mapped to classes, and the different types of access to each class are represented by permissions.

Policy rules take the following form: allow domains types: classes permissions; thereinto:

• Domain - The label of a process or set of processes. Also known as a domain type, because it refers only to the type of process.
• Type - The label of an object (for example, a file, socket), or a set of objects.
• Class - The type of object to access (for example, files, sockets). Permission - The action to take (for example, read, write).

The policy configuration source file

1,external/sepolicy

This is device-independent configuration and cannot generally be modified for the device

2,device///sepolicy

This is a device-specific configuration that selects the policy configuration for the platform based on the BOARD_SEPOLICY_ variable.

In the case of Forlinx Embedded T507 Board, for example, the path to the T507 policy file is as follows:

OKT507-android-source/android$ ls device/softwinner/common/sepolicy/private vendor

Type Enforcement (TE) profile

The domain and type definitions and rules for the corresponding object are saved in the .te file. Typically, each domain has a .te file, such as installd.te. Device and file types are declared in device.te, file.te. Shared rules are stored in some files, such as domain.te, app.te.

In the case of Forlinx Embedded T507 Board, for example, the path of the T507 system_app TE file is as follows:

device/softwinner/common/sepolicy/vendor/system_app.te

Label profile

1, file_contexts: file security context

2, property_contexts: property security context

In the case of the Flying Embedded T507 Board, for example, the T507 security context file path is as follows:

device/softwinner/common/sepolicy/vendor/property_contexts
device/softwinner/common/sepolicy/vendor/file_contexts

SE Android app classification

SELinux (or SEAndroid) divides apps into three main types (depending on the user, there are other domain types):

• 1) untrusted_app third-party app, no Android platform signature, no system permissions
• 2) platform_app have android platform signature, no syncen permission
• 3) system_app have android platform signature and system permissions

From the above division, permission level, theoretically: untrusted_app < platform_app < system_app

APP's domain and type

View seapp_contexts files, the domain and type of the APP are determined by the two parameters of user and seinfo

system/sepolicy/private/seapp_contexts

isSystemServer=true domain=system_server_startup

user=_app seinfo=platform name=com.android.traceur domain=traceur_app type=app_data_file levelFrom=all

user=system seinfo=platform domain=system_app type=system_app_data_file

user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file

user=network_stack seinfo=network_stack domain=network_stack levelFrom=all

type=radio_data_file

user=nfc seinfo=platform domain=nfc type=nfc_data_file

user=secure_element seinfo=platform domain=secure_element levelFrom=all

user=radio seinfo=platform domain=radio type=radio_data_file

user=shared_relro domain=shared_relro

user=shell seinfo=platform domain=shell name=com.android.shell type=shell_data_file

user=webview_zygote seinfo=webview_zygote domain=webview_zygote

user=_isolated domain=isolated_app levelFrom=al

luser=_app seinfo=app_zygote domain=app_zygote levelFrom=all

user=_app seinfo=media domain=mediaprovider name=android.process.media type=app_data_file

levelFrom=user

user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user

user=_app isEphemeralApp=true domain=ephemeral_app type=app_data_file levelFrom=all

user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user

user=_app minTargetSdkVersion=29 domain=untrusted_app type=app_data_file levelFrom=all

user=_app minTargetSdkVersion=28 domain=untrusted_app_27 type=app_data_file levelFrom=all

user=_app minTargetSdkVersion=26 domain=untrusted_app_27 type=app_data_file

levelFrom=user

user=_app domain=untrusted_app_25 type=app_data_file levelFrom=user

user=_app minTargetSdkVersion=28 fromRunAs=true domain=runas_app levelFrom=all

user=_app fromRunAs=true domain=runas_app levelFrom=user

user

RELATED LINKS http://www.https://blog.csdn.net/huilin9960/article/details/81530568

User can be understood as a UID. Android's UID and linux's UIDs are fundamentally different, Linux's UIDs are used to distinguish users from multi-user operating systems, and Android's UIDs are used for system rights management. The article in the reference link makes it very clear about the generation of uid.

seinfo

Different signatures create the corresponding selinux context.

Android.mk

LOCAL_CERTIFICATE:= platform

There is a platform signature, so seinfo is platform.

LOCAL_CERTIFICATE role

Refer to the documentation https://blog.csdn.net/hnlgzb/article/details/107823874

You can view the default signature files available under the Android source code build/target/product/security/directory, which may vary from platform to platform: the Flygt Embedded T507 board provides signature files for six different permissions: media, networkstack, platform, shared, testkey, and verity.

Take Forlinx Embedded T507 board, for example, to see the currently running application information:

console:/ # ps -Z

u:r:system_app:s0 system 15712 1861 1050628 110868 SyS_epoll_wait

0 S forlinx.example.app

u:r:untrusted_app_27:s0:c512,c768 u0_a62 30259 1861 1052120 114132 SyS_epoll_wait

0 S com.forlinx.changelogo

The two apps currently running, forlinx.example.app's UID (user) is system, with platform signatures, and its domain and type are system_app.

com.forlinx.changelogo does not set the default settings used by the UID, its UID is u0_a62, and no signature file is set, its domain and type is the untrusted_app.

T507 Custom Security Policy

For the two running apps above, we add additional permissions for the two apps, which correspond to TE profiles system_app.te, untrusted_app.te, and the path is:

device/softwinner/common/sepolicy/vendor/system_app.te

device/softwinner/common/sepolicy/vendor/untrusted_app.te

For forlinx.example.app example, we add execution rights for can devices:

OKT507-android-source/android$vi vi device/softwinner/common/sepolicy/vendor/system_app.te

...

allow system_app vendor_shell_exec:file { getattr open read execute execute_no_trans };

allow system_app shell_exec:file { getattr open read execute execute_no_trans };

allow system_app shell:file { getattr open read execute execute_no_trans };

...

Configured as a policy rule (allow domains types:classes permissions)

Analysis: domains: system_app

types：vendor_shell_exec

classes：file

permissions：getattr open read execute execute_no_trans

neverallow failures

Sometimes we increase the permissions, the system default configuration is not allowed, such as the above to the forlinx.example.app to increase the permissions to execute the script, errors are as follows:

libsepol.report_failure: neverallow on line 9 of system/sepolicy/private/system_app.te

(or line 41463 of policy.conf) violated by allow system_app shell:file { read open };

libsepol.report_failure: neverallow on line 22 of system/sepolicy/private/shell.te

(or line 40025 of policy.conf) violated by allow system_app shell:file { read open };

libsepol.check_assertions: 2 neverallow failures occurred

The path to the system's default security policy is system/sepolicy/, and according to the error report, we can modify the default configuration, modify the system/sepolicy/private/system_app.te and system/sepolicy/private/shell.te, thus completing the granting of permissions.

That's the context of Android security policy and how to customize your security policy under Forlinx Embedded T507 board Android system.