如何解决SELinux阻止虚拟机访问文件

几乎每个人都听说过SELinux（或者更确切地说，他们尝试过打开它），即使没有一些经验，您也不信任SELinux。
然而，随着0day安全漏洞的数量与日俱增，或许现在是时候审视Linux内核中这个已有八年历史的系统控制（MAC）的强制访问了。
SELinux与强制访问控制系统SELinux，全称SecurityEnhancedLinux（Linux安全增强型），是MAC（MandatoryAccessControl，访问控制系统）的一种实现。
.)可以访问进程。
命令访问控制系统的目的是提高系统抵抗0Day攻击（向犯罪分子暴露漏洞的攻击）的能力。
因此，它不会取代网络防火墙或ACL，也不会重复其用途。
例如，Apache系统中发现了一个漏洞，允许远程用户访问系统上的敏感文件（例如系统上用户的/etc/passwd），Apache更新了安全补丁来修复该漏洞。
目前该曝光尚未曝光。
此时SELinux可以实施缓解方案来弥补该漏洞。
由于/etc/passwd没有Apache访问标头，Apache对/etc/passwd的访问将被SELinux阻止。
与其他流行的系统访问控制命令相比，SELinux具有以下优点：●控制策略是可搜索的，而不是编程性的。
无需检查或停止工作即可更改热设计。
●可以从进程初始化、继承和程序执行三个方面进行控制。
●目标控制保存文件系统、目录、文件、文件引导描述符、端口、消息接口和网络接口。
那么SELinux对行为有什么影响呢？SELinux是否会极大地影响通用桌面应用程序和软件开发？然而，随着过去八年SELinux的广泛应用，当前的SELinux策略仍然可以满足典型桌面和软件开发环境中安全性和便利性的要求。
以常规版本的Fedora15为例，在构建完整的娱乐（包括多个第三方原生Linux游戏和Wine游戏）和开发环境（AndroidSDK+Eclipse）的过程中，只有Wine软件受到SELinux的影响。
首次发现时的默认策略。
被阻止，通过单击按钮并在图形“SELinux故障排除程序”的帮助下解决。
了解并配置SELinux1。
含义SELinux已禁用，Permissive仅表示记录日志但不阻止可疑行为，Constraints仅阻止日志记录和可疑行为。
目前常见的发行版中，RHEL和Fedora都是默认运行的，而openset等其他发行版则设置为许可运行。
2、通过命令[Enforcement|Permissive|1|0]改变SELinux的当前状态该命令可以立即改变SELinux的当前状态，在Enforced和Permissive之间切换，效果会一直保持到关机为止。
典型用途是查看SELinux是否导致服务或系统失败。
如果一个服务或程序在setenforce0之后仍然无法运行，那肯定不是SELinux造成的。
如果您想在永久运行环境中更改SELinux系统，可以通过更改配置文件/etc/sysconfig/selinux来实现。
请注意，从禁用模式切换到宽容或限制模式时，需要重新启动计算机并刷新整个系统文件的安全标签（touch/.autorelabel&&reboot）。
3、SELinux运行策略配置文件/etc/sysconfig/selinux还包含SELinux运行信息，这是通过改变SELINUXTYPE变量的值来完成的。
该值有两种可能性：它表示仅针对预定义的网络服务和访问请求。
严格使用SELinux保护意味着所有网络服务和访问请求都经过SELinux他们必须RHEL和Fedora默认设置为目标，其中包括几乎所有已安装的常见网络服务的SELinux策略设置。
如果你想自己编辑SELinux策略，还提供了命令行下和Eclipse下的策略编辑器seed。
Eclipse中的编辑插件。
4.SELinux模式下的coreutils工具常见的coreutils工具如ps、ls等SELinux可以通过添加Z选项来获取信息。

linux之selinux

SELinux，全称SecurityEnhancedLinux，是安全增强型Linux。
它是由国家安全局（NSA）和其他安全机构（例如SCC）联合开发的，旨在增强传统Linux操作系统的安全性并解决传统Linux中的问题。
自由访问控制（DAC）系统中的各种权限系统（如过多的root权限等）。
SELinux提供三种操作模式：Disabled、Permissive和Enforcing，每种模式为Linux系统安全提供不同的好处。
1.禁用工作模式（disablemode）在Disable模式下，SELinux被禁用，并使用默认的DAC访问控制方法。
此模式对于不需要增强安全性的环境很有用。
例如，如果一个正在运行的应用程序从您的角度来看工作正常，但生成大量SELinuxAVC拒绝消息，它最终可能会填满日志文件并使系统无法使用。
在这种情况下，最直接的解决方案是禁用SELinux，但您也可以在应用程序访问的文件上设置适当的安全上下文。
需要注意的是，在禁用SELinux之前，您应该考虑SELinux是否可以在系统上再次使用，如果您决定将来将其设置为Enforcing或Permissive，系统将通过自动SELinux文件重新启动。
下次重新启动。
禁用SELinux的方法也很简单。
2.许可操作模式（permissivemode）在许可模式下，SELinux被启用，但安全策略的规则不被强制执行。
当安全策略规则应拒绝访问时，仍然允许访问。
但是，系统会向日志文件发送一条消息，指示应拒绝访问。
在某些情况下，audit2allow命令可用于读取SELinux审核日志并创建新的SELinux规则以选择性地允许被拒绝的行为。
这也是允许应用程序在不禁用SELinux的情况下运行的一种方法。
3、Enforcing工作模式（enforcementmode）从该模式的名称可以看出，在Enforcing模式下，SELinux启动，并且强制执行安全策略的所有规则。

selinux会使某一个进程的权限变化吗

这些场景限制之一是用户可能通过通用chmod命令暴露文件或目录安全违规，导致访问意外传播。
因此，用户启动的任何进程都可以对该用户的文件执行任意操作，最终，恶意或其他恶意软件可以获得整个系统的根级别访问权限。
考虑到这些限制，美国国家安全局（NSA）率先设计了SELinux，一种按照最小权限模型​​限制对系统对象（如文件、目录、网络接口等）的进程的强制访问控制方法。
访问或执行其他活动的能力，并且这些限制可能会在以后根据需要进行更改。
简而言之，每个系统元素仅被授予特定功能所需的权限。
在RHEL7中，SELinux内置于内核中，并且默认在强制模式下启用。
在本文中我们将简要介绍SELinux的主要概念及其相关操作。
SELinux模式SELinux可以运行在三种不同的模式下：强制模式（Enforcement）：SELinux根据其策略规则拒绝访问，这些规则是用于控制设备安全模式的一系列标准；但如果日志的操作符合紧急顺序，则会被拒绝；已禁用（不言自明，即SELinux并未实际运行）。
getenforce命令可用于配置SELinux，force命令（后跟1或0）用于更改当前模式。
强制模式（Enforcement）或宽容模式（Permissive），但只对当前会话有效。
为了使上述设置在关机并重新启动后仍然有效，您需要编辑/etc/selinux/config文件并将SELINUX变量值设置为强制、许可和弱之一：#getenforce#setenforce0#getenforce#setenforce1#getenforce#cat/etc/selinux/config设置SELinux模式通常，setenforce在SELinux模式之间切换（从强制模式到宽容模式，反之亦然）：解决第一步问题的方法。
如果SELinux当前设置为限制性模式并且您遇到了一些问题，但是当您将SELinux切换到宽松模式时问题不再出现，您可以确信您正在进入SELinux权限。
SELinux上下文SELinux上下文由访问控制环境组成，在该环境中对SELinux用户、角色和类型（以及可选字段）做出决策：SELinux用户是通过分配给SELinux用户帐户的常规Linux用户帐户来完成的，它又被会话中SELinux上下文中的进程使用，以便可以清楚地定义它们的角色和允许的级别。
域和SELinux之间的中间件概念为域上的用户提供服务。
定义可以访问哪些域进程和哪些SELinux文件类型。
这将保护您的系统免受权限提升漏洞的影响。
类型定义SELinux文件或SELinux进程域的类型。
正常情况下，一个进程会被阻止访问其他进程使用的文件以及被其他进程访问。
仅当特定SELinux规则策略允许时才允许访问。
让我们看看这些想法如何在这个例子中发挥作用。
示例1：更改sshd守护进程的默认端口在系列RHCSA（8）：强化SSH，施加主机名和网络服务中，我们解释了更改sshd侦听的默认端口可以强化您的服务器以抵御外部安全攻击。
然后，编辑文件/etc/ssh/sshd_config并将端口更改为9999：Port9999保存更改并重新启动sshd：#systemctlrestartsshd#systemctlstatussshd重新启动SSH服务可以看到，sshd没有启动，但为什么会出现这种情况呢？快速检查文件/var/log/audit/audit.log显示sshd在端口9999上被拒绝访问（SELinux日志消息包含单词“AVC”，因此这种类型很容易消息被利用）以将其与其他信息区分开），因为此端口是为JBoss管理保留的端口：#cat/var/log/audit/audit.log|grepAVC|tail-1要查看SSH日志，请在以下位置在这种情况下，您可以像前面提到的那样禁用SELinux（但我不喜欢这样做！）并尝试重新启动sshd，这可以工作。
然而，种子应用程序可以告诉我们可以从哪里开始，而sshd端口不会出现任何问题。
运行：#semanageport-l|grepssh列出SELinux允许sshd监听的端口：让我们将Semanage工具传递到/etc/ssh/sshd_config中的端口9998，并将该端口添加到sshportt。
文本，然后重新启动sshd服务：#semanageport-a-tssh_port_t-ptcp9998#systemctlrestartsshd#systemctlis-activesshdsemanageAddport可以看到，这次sshd服务启动成功。
这个例子告诉我们SELinux使用它自己的内部端口定义来控制TCP端口号。
示例2：允许httpd访问发送邮件这是SELinux管理一个进程以允许另一进程访问的示例。
如果要在RHEL7服务器上为Apache配置mod_security和mod_evasive，则需要允许httpd电子邮件访问，以便在遭受(D)DoS攻击时可以通过电子邮件收到通知。
在以下命令中，如果您不希望更改在重新引导后仍然存在，请删除-P选项。
#semanageboolean-1|grephttpd_can_sendmail#setsebool-Phttpd_can_sendmail1#semanageboolean-1|grephttpd_can_sendmail允许Apache发送邮件从上面的示例中，您可以知道SELinux布尔设置（或只是布尔值）是相对于SELinux策略中的true或false。
您可以使用semanageboolean,l列出所有布尔值，也可以检查管道来过滤输出。
示例3：在默认目录以外的特定目录中提供静态站点假设您使用与默认目录(/var/www/html)不同的目录来提供静态站点，例如Web目录（例如目录当您在共享网络设备存储上共享网络文件并且需要将其安装在Web目录中时会出现该信息）。
一个）。
这个index.html被标记了类型default_tSELinux已经被改变，Apache无法访问这样的文件：SELinux文件权限b)。
相应的目录块。
然后重新启动阿帕奇。
c).d).应该'使用d)中的SELinux策略：#restorecon-R-v/websites现在重新启动Apache并再次浏览到http://，您可以看到正确显示的html文件：确认本文中排序的Apache页面，我们特别介绍了SELinux的主要信息请注意，由于该主题的广泛性，不可能在一篇文章中完全解释清楚，但我们相信本指南中阐述的基本原则将帮助您理解您想了解的更重要的主题。

SELinux权限

在了解SELinux之前，我们先了解一下Linux的两种访问控制机制：DAC和MAC

DAC，DiscretionaryAccessControl。
系统只提供基本的认证，完整的访问控制由开发者自己控制。
DAC将资源访问者分为三类：所有者、组和其他。
将资源的访问权限分为读、写、执行三类，为资源访问者设置不同的访问权限。
浏览器通常是每用户进程，有自己的uid/gid，通过匹配uid/gid和文件权限来决定是否可以访问。
在DAC方法中，每个用户进程默认拥有所有用户权限。
DAC有两个严重的问题：问题一：DAC对root用户的限制无效，因为root用户拥有所有权限。
而LinuxKernel2.1之后，Linux根据不同的应用场景将Root权限划分为多个RootCapability，普通用户可以配置为特定的RootCapability。
如果设置了CAP_DAC_OVERRIDE，普通用户可以覆盖DAC限制。
问题2：用户进程拥有用户的所有权限，可以修改/删除用户的所有文件资源，难以防范恶意软件。

一旦DAC被攻破，获取Root权限的过程可能会非法，早期版本的Android会受到严重影响。

MAC，强制访问控制（MandatoryAccessControl）。
系统严格限制每次访问，开发者给出了一定的限制策略。

针对DAC的弱点，LinuxMAC要求系统按照指定的策略对每次访问、每个文件源进行针对性的认证。
系统可以控制某些进程和某些文件资源的权限。
root用户虽然是root用户，但是其内部的各种进程并不一定具有root权限。
如果无法通过Mac认证，将无法进行相关操作。

与DAC相比，MAC访问控制的“主体”是“进程”而不是用户。
这样可以限制Root权限的滥用，并且需要对每个权限进行比较完整的修改，这样可以限制用户对资源的访问。

SELinux是目前最好的Mac操作系统，也是当前的行业标准。

SELinux，安全增强型Linux（安全增强型Linux）Linux）是美国国家安全局（NSA）为营利组织和大学推出的一种强制安全评估方法（称为强制访问控制，MAC）。
SELinux于2000年12月首次在GPL许可下发布。
目前LinuxKernel2.6及以上版本集成了SELinux。

SELinux分为三种模式：

Android5.x及以上是强制开启的，所以禁用（关闭）模式是没有用的。
通常在调试时，我们启用Permissive（宽容模式），以便一次发现并调试尽可能多的问题。
启用Enfocingmode以在量产期间保护系统。

查看SELinux模式：adbshel​​lgetenforce设置SELinux模式：adbshel​​lsetenforce1//0是愿意，1是强制

SELinux访问控制图：

我们通常设置流程。
包括主体、客体和安全策略配置。

SELinux为Linux中的所有对象分配一个SecurityContext，它被定义为一个常规字符串。

安全标签用于绑定访问的资源和安全上下文，并描述它们的对应关系。
默认格式为：resourcesecurity_context。
即：resuser:角色:类型[:范围]。
这里也可以使用通配符，可以将所有的功能与net联系起来。
此外，还有*、？等待百搭符号。
SecurityLabel在type_context中定义。
例如，在file_context中定义文件，在service_context中定义服务，在property_context中定义属性。
示例：file_contexts：

service_context：

查看进程安全上下文：ps-AZ。
例如，查看设置进程的安全上下文：ps-AZ|grepsettings:u:r:system_app:s0system1381585423450420107200Scom.android.settings查看文件的安全上下文：ls-Z。
例如查看文件build.prop的安全上下文：u:object_r:system_file:s0build.prop

TypeEnforcement（TE）是根据安全上下文中的类型来评估和评估权限。
具有对象类型的特定类类型具有特定的权限才能拥有访问权限，但它是目前使用最广泛的Mac评估方法，简单易用。

执行规则说明：

例如logd.te和tombstoned.te中定义了TE规则： allowlogdruntime_event_log_tags_file:filerw_file_perms; dontauditdomainruntime_event_log_log_tags{penread  auditallowtombstonedanr_data_file:文件{appendwrite}; neverallowlogd{app_data_filesystem_data_file}:dir_file_class_setwrite;

在SELinux上其中每个进程或者文件对应一种类型，每种类型又对应一种或多种。
所有公共属性都在以下文件中定义：system/cpolicy/public/propertiessystem/cpolicy/prebuild/api/[build]/public/propertiessystem/privacy/prebuild/api/[build]/private/properties其中[build]version]]是Android版本号，例如androidO是28.0。
常见属性声明：

一种类型对应一个或多个属性。
例如，常用的常见文件类型在file.te中定义：

SEAndroid针对不同的资源类型定义了不同的类。
比如普通文件、套接字等，比如SELinux使用的安全性，比如为每个进程入口定义对应的类。
每个组件都有关联的许可证。
例如文件读取、写入、创建、getattr、setattr、lock、ioctl等。
例如进程有fork、sigchild、sigkill、pitrace、getpid、setupgid等。
这些相关的类及其权限在以下文件中定义：system/private/private/access_vectorssystem/sepolicy/reqd_mask/access_vectorssystem/sepolicy/prebuilts/api/version/private/access_vectors例如：<

含义完成后，在下面相应的security_classes文件中声明指定的类。
system/private/security_classessystem/sepolicy/reqd_mask/security_classessystem/sepolicy/prebuilts/api/versionnumber/private/security_classes例如：

与内核中的API最相关的类和权限的定义，以便普通用户不得更改它们。

在SELinux中，我们称一个进程为域，当一个进程派生另一个进程并执行一个可执行文件（exec）时，我们常常会包含一个域开关，例如登录进程，SELinux就被授予了非常好的权限。
权限，而对于服务来说，这个服务我们需要限制权限，其中包括从一个域切换到另一个域，否则会默认使用登录流程。

SELinux中有一种特殊的语法：在我们准备更改type_transitionstatement之前，我们需要确保存在适当的授权函数：

如屏幕截图所示下面，init拉取apache并切换到apache域(1)首先，必须使进程能够在init_t域中运行apache_exec_t类型的文件。
allowinit_tapache_exec_t:file{readgetrexecute};(2)然后你必须告诉SELinux允许init_t进入apache_t域allowinit_tapache_t:processtransition;(3)(入口点右边对应的限制类型)apache_exec_tallowedapache_tapache_exec_t:fileentrypoint;(4)最后，DomainTransition;type_transitioninit_tapache_exec_t:processapache_t;

可以看到，整个域切换过程非常难写，所以，为了方便，Google在system/policy/public/te_macros文件中定义了宏：

要完成域切换我们可以使用宏。

例如内核启动登录进程并更改域： Domain_auto_trans(kernel,init_exec,init)启动netd、vold、zygote，并加载改变域：init_daemon_domain(vold)init_daemon_d在目录中创建文件默认使用父目录安全，如果要设置的话到另一个帐户，

接下来显示的是_queue_t目录有访问权限allowext_gateway_tin_queue_t:dir{writesearchadd_name};那么你必须告诉SELinux访问ext_gateway_t文件t_gateway_tin_queue_t:filein_file_t;同样，为了方便使用，谷歌它还在system/system/public/macros文件中定义了宏：

使用示例：file_type_auto_trans(factory,system_data_file,factory_data_file)

Android操作系统过去只关注启动图像。
之前我在提到Android中SELinux的演变时，提到过从androidO开始，Google将操作系统镜像和供应商进行了分离。
所以Cpolicy也存储在系统镜像和销售中。
系统特定的CPolicy存储在系统映像中，供应商特定的CPolicy存储在供应商中。

对于不同的平台，不同的平台厂商设置了不同的repository目录，以MTK平台为基础例如根据Cpolicy、平台特定和项目特定，分为

。
>同理，不同版本会导入不同目录下的Sepolicy配置

以mt6763平台为例：导入时：[common]路径：/device/mediatech/sepolicy(platfrom)路径：/device/mediatek/mt6763/sepolicy/特殊定义在boardConfig.mk文件中。
那么主要可以分为basic、bsp和full你可以：

Google在系统/策略中定义了禁止规则，并在SELinuxPolicy上限制更新，以防止开发者过于开放。
Issues和CTS测试用于确定开发者是否违反了相关法律。

因此，要注意以下几点：

出现SELinuxPolicyException时常见的两种解决方法：

（1）修改对应的SELinuxSecurityLabel。
Node，对某些主题如system_app、platform_app、priv_app（如Settings、SystemUI等内置APP）开放权限，但严禁对unrstedapp开放权限。
（2）用systemserverservice或init开始读写服务，应用程序将连接并使用binder/socket等。
该类型安全可靠，建议在服务中做相关安全审查。

无需进一步配置，system/sepolicy/android.mk中定义的Build_policy函数会遍历指定目录并导入T文件。
(3)绑定file_context  /()system/vendor|vendor)/bin/factory:object_r:factory_exec:s0中的可执行文件

(4）工厂根据要访问的文件和设备在Forkeyandtouchevent中指定其他权限allowfactoryinput_device：chr_filer_file_perms ;allowfactoryinput_device:dirrw_dir_perms;

条件：添加自定义系统属性：persist.demo，并为platform_app设置读写权限

（1）在property中定义系统属性,property_type

(2)在property_context中绑定系统属性的安全上下文。
-persist.demou:object_r:demo_prop:s0

(3)可以使用set_prop宏为platform_app.te添加写权限。
ˆset_prop(platform_app,demo_prop)

(4)为platform_app.te添加读取权限，并使用get_prop宏。
 get_prop(platform_app,demo_prop)

场景：有一个设备节点/dev/demo，有一个platform_app进程需要对该设备节点进行读写操作。

(1)在设备中指定设备类型。

3）在platform_app.te中，允许platform_app使用demodevice权限-allowplatform_appdemo_device:chr_filerw_file_perms;

显示：有扩展系统服务demo供APP调用。

(1)在service.te中-typedemo_service、app_api_service、system_server_service、service_manager_type；

(2)在ce_contexts demou:object_r:demo_service:s0中定义服务

(3)在frameworks/base/core/java/android/content/context.java中定义服务常量p。
uublicstaticfinalStringDEMO_SERVICE="demo";

(4)引用frameworks/base/core/java/android/app/SystemServiceRegistry.java中的其他系统服务注册demo_service

(5)在frameworks/base/services/java/com/android/server/SystemServer.java中，启动DemoService，并将其添加到管理service_admin中。

情况：本机服务在输入端创建一个套接字并绑定到/dev/socket/demo并允许某些进程访问它。

(1)在file.te中定义sockett typedemo_socket类型，file_type;

(2)socket类型在file_context /dev/socket/demo_socketu:object_r:demo_socket:s0

(3)允许所有进程访问，使用宏unix_socket_connect(clientdomain,socket,serverdomain)unix_socket_connect(appdomain,demo,demo)

(1)。
在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建demo.te。

（2）在demo.te中定义显示类型，并在init启动服务时进行类型转换。
并且您可以根据您希望演示访问的文件和设备在demo.te中定义其他权限。
输入演示，域；类型demo_exec，exec_type，file_type；init_daemon_domain(demo)

(3)可执行文件上下文类型/vendor/bin/demou:object_r:demo_exec:s0

4).

如果问题仍然可以重现，则与SELinux无关，如果容易重现但在Permissivemode下无法重现，则可能与SELinux有关。

(2)检查LOG中是否有常规SELinuxPolicyException检查KernelLOG/MainLog中是否有关键字SELinuxPolicyException并进一步检查。
这种特殊情况是否与当时的逻辑有关。

一般情况下，在符合Google的政策和绝不允许政策的情况下，我们可以根据LOG中的内容添加所需的权限。
示例日志：2020-03-2714：11：02.5961228-1228/com.android.systemuiW/FaceIdThread：type=1400audit（0.0：481）：avc：拒绝{read}forname=“als_ps”dev=“tmpfs”=10279scontext=u:r:平台_app:s0:c512,c768tcontext=u:object_r:als_ps_device:s0tclass=chr_filepermissive=0

日志描述如下：

一般我们应该重点关注四个：permission、sourcetype,targettype,targetclass

因此，您只需使用以下一项即可配置所需的Selinux权限：允许[源[目标类型]:[目标类][权限]示例1:03-2703:45:22.63229582958WCamera:type=1400audit(0.0:314):avc:禁止{阅读}forname="u:object_r:graphics_debug_prop:s0"dev="tmpfs"ino=2649scontext=u:r:platform_app:s0:c512,c768tcontext=u:object_r:graphics_debug_prop:s0tclass=filepermissive=0

解决办法：根据通常的公式，platform_app.te应修改如下：添加： allowplatform_appgraphics_debug_prop:filer_file_perms;在system/sepolicy/te_macros中我们使用定义的宏get_prop：

更多相关宏定义请参见system/sepolicy/public/te_macros。
因此，在最后一次简化之后，修改platform_app.te并添加：get_prop(platform_app,graphics_debug_prop)

示例2:03-2714:11:02.5961228-1228/com.android.systemuiW/BackThread:type:0audit(0.0:481):avc:被拒绝{read}forname="als_ps"dev="tmpfs"ino=10279scontext=u:r:platform_app:s0:c512,c768tcontext=u:object_r:als_ps_device:s0tclass=r_filepermissive=0

解决方案：更新platform_app.te和添加： allowplatform_appals_ps_device:chr_filer_file_perms;

(1)决不允许违反规则或编译错误： neverallowcheckfailedatxxxCTS测试项失败： android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX这种问题尤其在Android烤箱和系统之后会发生分开了。
基本上，这类问题是由于修改或添加了T的配置，不符合任何不允许的规则，从而导致编译错误。
为了解决编译错误，修复了neverallowed规则，最终在运行CTS时，相关测试对象无法通过。

解决方案：

解决方案：更改流程时，请参阅第3.4节。

本文主要参考了MTK-OnlineQuick-Start中的“SELinux问题快速分析”内容，感谢他们的辛苦付出。
此外，随着源代码和开发实践本身，还添加了一些个人见解和实用内容。