SEAndroid安全机制中的文件安全上下文关联分析.doc

SEAndroid安全机制中的文件安全上下文关联分析 前面一篇文章提到，SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略实施在主体和客体的安全上下文之上。这意味着安全策略在实施之前，SEAndroid安全机制中的主休和客体是已经有安全上下文的。在SEAndroid安全机制中，主体一般就是进程，而客体一般就是文件。文件的安全上下文的关联有不同的方式。本文主要分析文件安全上下文的设置过程，接下来的一篇文章再分析进程安全上下文的设置过程。 在SEAndroid中，文件的安全上下文是在文件的创建过程中设置的。在Android系统中，文件的产生方式主要分为两种，一种是预置在ROM里面的，另外一种是动态创建的，即在系统在运行的过程中创建的。对于预置在ROM里面的文件，例如打包在system.img里面的文件，它们的安全上下文在是制作ROM的过程中设置的。而对于动态创建的文件，它们的安全上下文如果没有特别指定，就与父目录的安全上下文一致。 假设动态创建的文件的安全上下文来自于父目录。这时候就有一个问题需要解决，就是最开始的父目录的安全上下文是怎么来的呢？如果最开始的父目录是预置在ROM里面的，那么这个问题就很好解决。但是有一些目录，它们并不是预置在ROM的，而是在系统启动或者运行的过程中动态安装的，即我们平时所说的虚拟文件系统，例如我们在前面一篇文章中提到的selinux文件系统。这些虚拟文件系统在安装的时候，SEAndroid安全机制会根据安全策略给它们的根目录设置相应的安全上下文，这样以后在里面创建的文件就可以从父目录继承安全上下文了。 此外，有些文件的安全上下文是不适合使用父目录的安全上下文的，例如应用程序数据文件，它们的安全上文需要根据一定的规则来特别指定。在前面一篇文章中提到，SEAndroid安全机制根据应用程序类型的签名来给其数据文件设置不同的安全上下文，以区分系统应用程序和第三方应用程序的数据文件。由于无论是系统应用程序，还是第三方应用程序，它们的数据文件都是位于data分区的data子目录中的，因此我们需要有一种机制给在/data/data目录中创建的数据文件设置不同的安全上下文。我们知道，应用程序在安装的时候，PackageManagerService会通过守护进程installd在/data/data目录中创建相应的数据目录，以后应用程序在运行的过程中默认创建的数据文件就位于对应的数据目录中，因此只要给这些数据目录设置不同的安全上下文，就可以让不同类型的应用程序在运行的过程中创建不同安全上下文的数据文件。 我们通过图1总结上面描述的文件安全上下文创建方式，如下所示： 接下来，我们就分别详细分析上述三种文件安全上下文关联方式。 1. 设置打包在ROM里面的文件的安全上下文 这里我们以ROM里面的system.img为例，说明打包在ROM里面的文件的安全上下文的设置过程。在前面一篇文章中，我们已经分析过system.img的制作过程了，因此这里我们只关注与安全上下文设置相关的逻辑。 生成system.img的命令位于build/core/Makefile文件中，如下所示： [plain] view plain copy 在CODE上查看代码片派生到我的代码片 BUILT_SYSTEMIMAGE := $(systemimage_intermediates)/system.img # $(1): output file define build-systemimage-target @echo Target system fs image: $(1) @mkdir -p $(dir $(1)) $(systemimage_intermediates) rm -rf $(systemimage_intermediates)/system_image_info.txt $(call generate-userimage-prop-dictionary, $(systemimage_intermediates)/system_image_info.txt, skip_fsck=true) $(hide) PATH=$(foreach p,$(INTERNAL_USERIMAGES_BINARY_PATHS),$(p):)$$PATH \ ./build/tools/releasetools/build_image.py \ $(TARGET_OUT) $(systemimage_intermediates)/system_image_info.tx