Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what SElinux is". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

background

SELinux(Security-Enhanced Linux) is the National Security Agency's (NSA) implementation of mandatory access control, and is the most outstanding new security subsystem in Linux history. NSA developed an access control system with the help of the Linux community, under which a process can access only those files it needs for its task.

Before SELinux, the security model on Linux was called DAC, which translates to Discretionary Access Control. The core idea of DAC is simple: a process theoretically has the same permissions as the user executing it. For example, start Browser as root user, then Browser has root user privileges, DAC management is too loose, not flexible enough, so SELinux.

role

With this access control system, a process can access only those files it needs for its task.

SELinux uses type coercion to improve mandatory access control. All subjects (program processes) have a TE rule to grant access to objects (files/sockets, etc.). When an application accesses a resource, the system searches all TE rulesets and processes them based on the results. This rule set is described by the Access Vector rule (AV).

The kernel exposes to the outside the resource permissions allowed to access, and TE describes what access rights the principal has. SELinux defines 30 different object classes:

security process system capability filesystem file dir fd lnk_file chr_file blk_file socket_file ...

Each object category defines permissions, for example, there are 19 permissions for file:

`ioctl read write create getattr setattr lock relablefrom relableto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint

View SElinux permissions for processes

In SELinux, everything is given a security attribute, officially called Security Context, Security Context is a string, mainly composed of three parts, for example, in SEAndroid, the process Security Context can be viewed by ps -Z command:

rk3288:/ $ ps -AZu:r:hal_wifi_supplicant_default:s0 wifi 1816 1 11388 6972 0 0 S wpa_supplicantu:r:platform_app:s0:c512,c768 u0_a14 1388 228 1612844 57396 0 0 S android.ext.servicesu:r:system_app:s0 system 1531 228 1669680 119364 0 0 S com.android.gallery3du:r:kernel:s0 root 582 2 0 0 0 0 S [kworker/1:2]u:r:radio:s0 radio 594 228 1634876 89296 0 0 S com.android.phoneu:r:system_app:s0 system 672 228 1686204 141716 0 0 S com.android.settingsu:r:platform_app:s0:c512,c768 u0_a18 522 223 1721656 152116 0 0 S com.android.systemui

The leftmost column above is the Security Context of the process. Take the first process wpa_supplicant as an example.

u:r:hal_wifi_supplicant_default:s0

u means user, SEAndroid defines a SELinux user, the value is u

r means role, role means role, it is a relatively high-level, more convenient permission management ideas in SELinux. Simply put, a u can belong to multiple roles, and different roles have different permissions.

hal_wifi_supplicant_default indicates that the Domain to which the process belongs is hal_wifi_supplicant_default. MAC (Mandatory Access Control) The basic management idea of mandatory access control is actually Type Enforcement Access Control (TEAC for short, usually denoted by TE). For processes, Type is Domain. For example, hal_wifi_supplicant_default requires any permissions, which need to be explained in the te file through the allow statement.

s0 is related to SELinux's Multi-Level Security (MLS) mechanism designed to meet the needs of the military and educational industries. Simply put, MLS classifies the system's processes and files, and different levels of resources require corresponding levels of processes to access them.

access rules

AV is used to describe the subject's access permissions to objects. There are usually four types of AV rules:

allow: indicates that the subject is allowed to perform a permitted operation on the object.

neverallow: indicates that the subject is not allowed to perform the prescribed operation on the object.

auditallow: Indicates that the operation is allowed and records access decision information.

dontaudit: indicates that the decision information of violating the rule is not recorded, and the violation of the rule does not affect the operation `

Common type rule syntax bits:

1 allow platform_app debugfs:file { read ioctl };

Represents a program process of type platform_app that performs read and ioctl operations on files of type debugfs.

mode switching

SELINUX has three options: disabled, permissive, and enforcing.

Disabled is needless to say.

Permissive is Selinux works, but even if you violate the policy it lets you continue to operate, but records your violations. Very useful when we develop policies, is the default mode for UserDebug.

Enforcing means you violate the policy and you can't continue to operate.

The SElinux mode of the system can be switched by using the following command adb shell setenforce 0

0--Permissive

1--Enforcing

adb shell getenforce---View status

How to debug SElinux on Android

In android system development, because selinux permissions generally appear in the user version, but we can verify in the userdebug version by the following ways

The first step is to determine if the problem is caused by a selinux permission problem.

Adb shell gettenforce//View current SePolicy permission status (Enforcing means Open Permissive means Closed)

userdebug version in permissive off state settforce1//Change status to Enforcement, 0 means Permissive Testing, if the problem arises at this point, then it is a selinux permission problem

2. Solution

1. adb shell dmesg---catch kernel log

(Special note: adb shell "cat /proc/kmsg| grep avc" > avc_log.txt can be directly proposed avc log)

2.adb logcat -b events

Keyword:

avc: denied

As shown in the figure:

This is a selinux permission problem, we only pay attention to denied{}, scontext, tcontext and tclass four keywords can

denied{} The content in parentheses indicates the denied permission action

The value of scontext indicates which te file to add

tcontext indicates the target to which permission needs to be granted

tclass indicates the type of permission problem

The fix for this problem is to add the following code to the system_app.te file: allow system_app sysfs_thermal:dir search;

Note: Sometimes not all missing permission logs are visible in Enforcement mode, for example:

This log due to FileNotFoundException problem caused the program will not continue to execute to the end of the code, so there is no execution of the code missing the permission log can not be obtained, but in Permissive mode all permission problems will be printed out, so it is recommended to catch log in Permissive mode or both mode catch

"What is SElinux" content introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.