linux情景分析(linux搭建测试环境面试)
大家好,今天小编来为大家解答以下的问题，关于linux情景分析，linux搭建测试环境面试这个很多人还不知道，现在让我们一起来看看吧！
linux内核情景分析之execve的实现
Linux内核中的execve函数实现涉及到用户态CPU寄存器在内核栈中的保存和系统调用的细节。首先，理解sys_execve源码中的do_execve函数至关重要。它涉及到一个名为linux_bin_fmt的结构，该结构存储了内核对各种可执行程序格式的支持信息，包括加载和执行函数，以及保存文件路径、参数和环境变量的linux_bin_prm结构。
do_execve的实现从读取可执行文件的头部128字节开始，通过prepare_binprm函数，将文件头部数据放入bprm->buf缓存。内核通过search_binary_handler遍历formats队列，识别文件的正确格式并调用相应的处理函数，如load_aout_binary处理a.out格式。
在load_aout_binary中，如遇到/bin/echo，会调用flush_old_exec，涉及信号处理函数指针复制、内存空间处理（包括信号处理模式、用户空间的清理）和文件关闭等。其中，make_private_signal和exec_mmap函数分别处理信号处理和内存映射，根据close_on_exec位图关闭相关文件。
在载入新程序时，内核会复制可执行文件路径到内核空间，然后查找并打开文件，读取前128字节初始化数据结构。接下来，通过formats队列的遍历，找到合适的代理加载器（如a.out的load_aout_binary）来执行后续的加载和初始化操作，如设置信号处理、用户空间和文件资源等。
最终，新进程会通过各个代理加载器的定制化空间申请和参数映射，调用start_thread启动进程。尽管描述了大致流程，但实际执行中涉及许多细节问题，如线程隔离、用户空间计数处理等，需要深入内核代码才能详细了解。
android系统源代码情景分析 需要具备什么基础知识
Android系统的源代码非常庞大和复杂，我们不能贸然进入，否则很容易在里面迷入方向，进而失去研究它的信心。我们应该在分析它的源代码之前学习好一些理论知识，下面就介绍一些与Android系统相关的资料。
我们知道，Android系统是基于Linux内核来开发的，在分析它在运行时库层的源代码时，我们会经常碰到诸如管道（pipe）、套接字（socket）和虚拟文件系统（VFS）等知识。此外，Android系统还在Linux内核中增加了一些专用的驱动程序，例如用于日志系统的Logger驱动程序、用于进程间通信的Binder驱动程序和用于辅助内存管理的匿名共享内存Ashmem驱动程序。在分析这些Android专用驱动程序的时候，也会碰到Linux内核中与进程、内存管理相关的数据结构。因此，我们有必要掌握一些Linux内核的基础知识，下面就介绍四本典经的Linux内核书籍。
1.Linux Kernel Development.
这本书的作者是Robert Love，目前最新的版本是第3版。这本书对Linux内核的设计和实现提供了一个总览视图，从概念上对Linux内核的各个子系统的设计目标和实现思路进行了清晰的描述，非常适合初学者阅读。如果从软件工程的角度来看，这本书就相当于是Linux内核的概要设计文档。
2.Understanding the Linux Kernel.
这本书的作者是Daniel P. Bovet和Marco Cesati，目前最新的版本是第3版。这本书对Linux内核的实现提供了更多的细节，详细地描述了内核开发中用到的重要数据结构、算法以及编程技巧，非常适合中高级读者阅读。如果从软件工程的角度来看，这本书就相当于是Linux内核的详细设计文档。
3.Linux Device Drivers.
这本书的作者是Jonathan Corbet, Alessandro Rubini和Greg Kroah-Hartman，目前最新的版本是第3版。这本书更加注重实际操作，它详细地讲解了Linux内核驱动程序的实现原理和实现方法，读者可以跟着它来实际地编写出自己的Linux驱动程序。阅读了这本书之后，对我们后续去分析Android的专用驱动程序是有非常大的帮助的。
4.Linux内核源代码情景分析
这本书的作者是毛德操和胡希明，是中国人自己编写的一本经典的Linux内核书籍。这本书最大的特点是从使用情景出发，对Linux内核的源代码作了详细的分析，帮助读者把枯燥无味的源代码给理顺了。
掌握了Linux内核的基础知识之后，还不宜马上就去分析Android系统的源代码，因为这样做是漫无目的的，我们应该带着问题或者目标去分析Android系统的源代码。要把问题或者目标挖掘出来，最好的方法就莫过于是在Android平台上编写自己的应用程序了。通过编写应用程序，我们可以知道Android平台都提供了哪些功能，进而我们就会想去了解这些功能是怎么实现的，这样就可以达到带着问题或者目标去分析Android系统的源代码了。这里介绍两个Android应用程序开发教程的书籍：
1.Professional Android 2 Application Development.
2.Google Android SDK开发范例大全.
这两本书都使用了大量的例子来说明如何使用Android SDK来开发Android应用程序。读者可以根据实际情况来练习一下，主要掌握Android应用程序四大组件（Activity、Service、Broadcast Receiver和Content Provider）的用法，因为Android系统的整个架构和实现就是为了向开发者提供这四大组件来实现各种各样的应用程序的。在学习的过程中，如果遇到其它问题，还可以参考官方文档
SELinux权限
在了解SELinux之前，我们先来了解一下Linux的两种访问控制策略：DAC和MAC
DAC，自主访问控制（Discretionary Access control）。系统只提供基本的验证,完整的访问控制由开发者自己控制。
DAC将资源访问者分成三类：Owner、Group、Other。
将访问权限也分成三类：read、write、execute
资源针对资源访问者设置不同的访问权限。访问者通常是各个用户的进程，有自己的uid/gid，通过uid/gid和文件权限匹配,来确定是否可以访问。DAC机制下，每一个用户进程默认都拥有该用户的所有权限。
DAC有两个严重问题：
问题一：
因为Root用户是拥有所有权限的，所以DAC对Root用户的限制是无效的。并且在Linux Kernel 2.1以后，Linux将Root权限根据不同的应用场景划分成许多的Root Capabilities,普通用户也可以被设置某个Root Capability。普通用户如果被设置了CAP_DAC_OVERRIDE，也可以绕过 DAC限制。
问题二：
用户进程拥有该用户的所有权限，可以修改/删除该用户的所有文件资源,难以防止恶意软件。
可见，DAC有明显的缺陷，一旦被入侵，取得Root权限的用户进程就可以无法无天，胡作非为，早期android版本就深受其害。
MAC，强制性访问控制（Mandatory Access control）。系统针对每一项访问都进行严格的限制,具体的限制策略由开发者给出。
Linux MAC针对DAC的不足,要求系统对每一项访问,每访问一个文件资源都需要根据已经定义好了的策略进行针对性的验证。系统可以针对特定的进程与特定的文件资源来进行权限的控制。即使是root用户，它所属的不同的进程，并不一定能取得root权限，而得要看事先为该进程定义的访问限制策略。如果不能通过MAC验证，一样无法执行相关的操作。
与DAC相比，MAC访问控制的“主体”变成了“进程”而不是用户。这样可以限制了Root权限的滥用，另外要求对每一项权限进行了更加完整的细化,可以限制用户对资源的访问行为。
SELinux就是目前最好的MAC机制，也是目前的行业标准。
SELinux，安全增强Linux（Security-Enhanced Linux），是由美国国家安全局(NSA)发起,多个非营利组织和高校参与开发的强制性安全审查机制（Mandatory Access control，简称MAC）。SELinux最早于2000年12月采用GPL许可发布。目前，Linux Kernel 2.6及以上的版本都已经集成了SELinux。
SELinux分成三种模式：
Android 5.x及以上强制开启，因此，disabled(关闭)模式并没有什么用了。通常在调试时，我们会启用Permissve(宽容模式),以便尽可能的发现多的问题,然后一次修正。在量产时启用Enfocing mode(强制模式)来保护系统。
查看SELinux模式：adb shell getenforce
设置SELinux模式：adb shell setenforce 1//0是Permissve，1是Enfocing
SELinux的访问控制示意图：
通常我们开发的过程中，就是配置Subject、Object、Security Policy。
SELinux给Linux的所有对象都分配一个安全上下文(Security Context)，描述成一个标准的字符串。
安全上下文的标准格式： user:role:type[:range]
Security Label用来绑定被访问资源和安全上下文，描述它们的对应关系。标准格式为：resource security_context。即：res user:role:type[:range]。这里也可以使用通配符，例如 net.就可以绑定所有以net.开头的属性，除此之外，还有类似正则表达式的*、？等等通配符。Security Label都定义在type_contexts当中，例如file的定义在file_contexts中，service定义在service_contexts中，property定义在property_contexts中。
举例：
file_contexts:
service_contexts:
查看进程安全上下文： ps-AZ。例如，查看Settings进程的安全上下文，ps-AZ| grep settings：
u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls-Z。例如，查看文件build.prop的安全上下文：
u:object_r:system_file:s0 build.prop
Type Enforcement(TE)是根据Security Context中的 type进行权限审查,审查 subject type对 object type的某个class类型中某种permission是否具有访问权限，是目前使用最为广泛的MAC审查机制,简单易用。
TE控制语句格式: rule_name source_type target_type: class perm_set
Type Enforcement规则说明：
举个例子，logd.te、tombstoned.te中定义的TE规则：
allow logd runtime_event_log_tags_file:file rw_file_perms;
dontaudit domain runtime_event_log_tags_file:file{ open read};
auditallow tombstoned anr_data_file:file{ append write};
neverallow logd{ app_data_file system_data_file}:dir_file_class_set write;
SELinux中每一个进程或者文件都对应一个type,而每一个type都对应有一个或几个attribute。所有常见的attribute定义在以下文件中：
system/sepolicy/public/attributes
system/sepolicy/prebuilts/api/[build version]/public/attributes
system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即为android版本号，例如android O为28.0。常见的attribute定义：
Type对应一个或者几个attribute，Type的定义格式：
type type_name, attribute1, attribute2；
Type的定义通常分散在各个te文件中。例如，常用普通文件的type定义在file.te中：
SEAndroid对于不同的资源类型，定义了不同的Class。比如普通的file、socket等等，比如SELinux使用的security,比如针对每个process参数的process等定义相关的class。这些class，每一个class都有相对应的permissions。比如file就有 read, write, create, getattr, setattr, lock, ioctl等等.比如process就有fork, sigchld, sigkill, ptrace, getpgid, setpgid等等。这些相关的class,以及他们具有那些Permissions都定义在以下文件中：
system/sepolicy/private/access_vectors
system/sepolicy/reqd_mask/access_vectors
system/sepolicy/prebuilts/api/版本号/private/access_vectors
例如：
定义完之后，在以下对应的security_classes文件中声明定义的classes。
system/sepolicy/private/security_classes
system/sepolicy/reqd_mask/security_classes
system/sepolicy/prebuilts/api/版本号/private/security_classes
例如：
注意，Classes和Permissions的定义与Kernel中相关API是强相关的，普通用户严禁修改。
在SELinux中,我们通常称一个进程是一个domain,一个进程fork另外一个进程并执行(exec)一个执行档时,我们往往会涉及到domain的切换.比如init进程, SELinux给予了它很大的权限,而它拉起的服务,我们要限制这个服务的权限，于是就涉及到从一个domain切换到另外一个domain,不然默认就使用init进程的domain.
在SELinux里面有专门的一条语法: type_transition statement.
在准备切换前我们先要确保有相关的权限操作：
如下面的demo, init拉起apache并且切换到 apache的domain.
(1).首先，你得让init_t域中的进程能够执行type为apache_exec_t的文件
allow init_t apache_exec_t: file{read getattr execute};
(2).然后，你还得告诉SELinux，允许init_t做DT切换以进入apache_t域
allow init_t apache_t: process transition;
(3).然后，你还得告诉SELinux，切换入口（对应为entrypoint权限）为执行apache_exec_t类型的文件
allow apache_t apache_exec_t: file entrypoint;
(4).最后，Domain Transition
type_transition init_t apache_exec_t: process apache_t;
可以看到，整个domain切换过程写起来非常麻烦。因此，Google为了使用方便,在system/sepolicy/public/te_macros文件中定义了宏：
我们可以使用这些宏来完成domain切换。
举例：
kernel启动init进程切换domain:
domain_auto_trans(kernel, init_exec, init)
init启动netd、vold、zygote、installd切换domain:
init_daemon_domain(netd)
init_daemon_domain(vold)
init_daemon_domain(zygote)
init_daemon_domain(installd)
一个进程创建在一个目录下创建文件时,默认是沿用父目录的Security Context,如果要设置成特定的Label,就必须进行Object Transitions.
同样是使用：type_transition statement.
对应的必须有两个前提条件:
下面是一个demo, ext_gateway_t这个domain在类型为in_queue_t的目录下，创建类型为 in_file_t的文件.
(1).首先，你得让ext_gateway_t对in_queue_t目录具备访问权限
allow ext_gateway_t in_queue_t: dir{ write search add_name};
(2).然后，你还得告诉SELinux，允许ext_gateway_t访问in_file_t的文件
allow ext_gateway_t in_file_t: file{ write create getattr};
(3).最后，Object Transition
type_transition ext_gateway_t in_queue_t: file in_file_t;
同样的，为了方便使用，Google也在system/sepolicy/public/te_macros文件中定义了宏:
使用举例：
file_type_auto_trans(factory, system_data_file, factory_data_file)
android O以前sepolicy集中放在boot image。前面提到SELinux在Android的主要变更历史时，有提到android O开始，Google将system image和 vendor image分离。因此，sepolicy也相应的被分离存放到system image以及 vendor image。与system相关的sepolicy就存放system image,与SoC vendor相关的sepolicy就存放在vendor image。
对于原生AOSP，Google设定了不同的存放目录,以便进行分离,以Google默认的sepolicy为例，sepolicy主目录为/system/sepolicy，我们主要关注三个子目录：
对于不同的平台，不同平台厂商也设定了不同的存放目录，以MTK平台为例：
首先，根据不同的platform共用sepolicy、platform独有、project独有，分为：
对应的，不同版本会导入不同目录下的sepolicy配置
以mt6763平台为例，导入时：
[common]路径为：/device/mediatek/sepolicy
[platfrom]路径为：/device/mediatek/mt6763/sepolicy/
具体的定义在BoardConfig.mk文件中:
然后，basic、bsp、full又可以主要细分为：
Google在system/sepolicy中定义了相关的neverallow规则,对SELinux Policy的更新进行了限制,以防止开发者过度开放权限，从而引发安全问题。并且还会通过CTS测试检测开发者是否有违法相关的规则。
因此，我们需要注意以下几点：
出现SELinux Policy Exception时常见的两种解决方案：
(1).修改对应节点的SELinux Security Label,为特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等内置APP开启权限,但严禁为untrsted app开启权限。
(2).通过system server service或者 init启动的service读写操作,然后app通过binder/socket等方式连接访问.此类安全可靠,并且可以在service中做相关的安全审查,推荐这种方法.
情景:定义由 init进程启动的service, factory,其对应的执行档是/vendor/bin/factory。
(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个factory.te,然后将te文件加入编译，如放到这种指定目录下不需要额外配置，sytem/sepolicy/Android.mk中定义的build_policy函数会遍历指定目录导入te文件。
(2).在factory.te中定义factory类型，init启动service时类型转换,
type factory, domain;
type factory_exec, exec_type, file_type, vendor_file_type;
init_daemon_domain(factory)
(3).在file_contexts中绑定执行档
/(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0
(4).根据factory需要访问的文件以及设备,定义其它的权限在factory.te中.
#Purpose: For key and touch event
allow factory input_device:chr_file r_file_perms;
allow factory input_device:dir rw_dir_perms;
情景:添加一个自定义的system property： persist.demo，并为platform_app设置读写权限
(1).在property.te中定义system property类型
type demo_prop, property_type
(2).在property_contexts中绑定system property的安全上下文。
persist.demo u:object_r:demo_prop:s0
(3).在platform_app.te中新增写权限，可以使用set_prop宏。
set_prop(platform_app, demo_prop)
(4).在platform_app.te中新增读权限，可以get_prop宏。
get_prop(platform_app, demo_prop)
情景:有一个设备节点/dev/demo，有一个platform_app进程需要读写这个设备节点。
(1).在device.te中定义device类型
type demo_device dev_type;
(2).在 file_contexts中绑定demo_device
/dev/demo u:object_r:demo_device:s0
(3).在platform_app.te中，允许platform_app使用demo device的权限
allow platform_app demo_device:chr_file rw_file_perms;
情景:有一个扩展的系统服务demo_service供APP调用。
(1).在service.te中定义service类型
type demo_service, app_api_service, system_server_service, service_manager_type;
(2).在service_contexts中绑定service
demo u:object_r:demo_service:s0
(3).在frameworks/base/core/java/android/content/Context.java中定义服务常量
public static final String DEMO_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_manager进行管理。
(6).最后一步，参考其它系统服务，实现DemoManager、DemoService，并定义如IDemoService等等的AIDL接口。
情景:一个native service通过init创建一个socket并绑定在/dev/socket/demo,并且允许某些process访问.
(1).在file.te中定义socket的类型
type demo_socket, file_type;
(2).在file_contexts中绑定socket的类型
/dev/socket/demo_socket u:object_r:demo_socket:s0
(3).允许所有的process访问，使用宏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中定义demo类型，init启动service时类型转换。并可以根据demo需要访问的文件以及设备,定义其它的权限在demo.te中。
type demo, domain;
type demo_exec, exec_type, file_type;
init_daemon_domain(demo)
(3).绑定执行档 file_context类型
/vendor/bin/demo u:object_r:demo_exec:s0
(4).创建demo的入口执行档demo_exec、并配置相应的权限。
(1).将SELinux调整到Permissive模式复测
使用eng/userdebug版本，adb shell setenforce 0将SELinux模式调整到Permissive模式，然后复测。如果还能复现问题，则与SELinux无关；如果原本很容易复现,而Permissive mode不能再复现,那么就可能与SELinux相关。
(2).查看LOG中是否有标准的SELinux Policy Exception.
在Kernel LOG/ Main Log中查询关键字"avc: denied"看看是否有与目标进程相关的SELinux Policy Exception,并进一步确认这个异常是否与当时的逻辑相关。
一般情况我们在符合Google sepolicy策略及neverallow策略的前提下，根据LOG中的内容，需要什么权限就加什么权限。例如LOG：
2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
LOG说明如下：
一般我们需要重点关注的是四个：permission、source type、target type、target class
根据这四个就可以配置出的所需要的selinux权限：
allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied{ read} for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0
解决方案：
按正常的套公式，应该是这样修改platform_app.te，增加：
allow platform_app graphics_debug_prop:file r_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-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied{ read} for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
解决方案：
修改platform_app.te增加：
allow platform_app als_ps_device:chr_file r_file_perms;
(1).不符合neverallow规则或者修改了neverallow规则
编译报错：
neverallow check failed at xxx
CTS测试项failed：
android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
这类问题在android O vendor和system分离之后，尤其容易出现。基本上这类问题都是因为修改或者增加的te配置不符合neverallow规则，导致编译报错。而为了解决编译报错，又修改了neverallow规则，最终在跑CTS时，没法通过相关的测试项。
解决思路：
(2). init进程fork新进程没有做domain切换
CTS测试项failed：
android.security.cts.SELinuxDomainTest# testInitDomain
解决思路：
fork进程时，参考3.4节中做domain切换。
本文主要参考了MTK-Online的Quick-start中《SELinux问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。
