SEAndroid安全機(jī)制中的安全上下文關(guān)聯(lián)分析.doc

SEAndroid安全機(jī)制中的文件安全上下文關(guān)聯(lián)分析前面一篇文章提到，SEAndroid是一種基于安全策略的MAC安全機(jī)制。這種安全策略實施在主體和客體的安全上下文之上。這意味著安全策略在實施之前，SEAndroid安全機(jī)制中的主休和客體是已經(jīng)有安全上下文的。在SEAndroid安全機(jī)制中，主體一般就是進(jìn)程，而客體一般就是文件。文件的安全上下文的關(guān)聯(lián)有不同的方式。本文主要分析文件安全上下文的設(shè)置過程，接下來的一篇文章再分析進(jìn)程安全上下文的設(shè)置過程。在SEAndroid中，文件的安全上下文是在文件的創(chuàng)建過程中設(shè)置的。在Android系統(tǒng)中，文件的產(chǎn)生方式主要分為兩種，一種是預(yù)置在ROM里面的，另外一種是動態(tài)創(chuàng)建的，即在系統(tǒng)在運行的過程中創(chuàng)建的。對于預(yù)置在ROM里面的文件，例如打包在system.img里面的文件，它們的安全上下文在是制作ROM的過程中設(shè)置的。而對于動態(tài)創(chuàng)建的文件，它們的安全上下文如果沒有特別指定，就與父目錄的安全上下文一致。 假設(shè)動態(tài)創(chuàng)建的文件的安全上下文來自于父目錄。這時候就有一個問題需要解決，就是最開始的父目錄的安全上下文是怎么來的呢？如果最開始的父目錄是預(yù)置在ROM里面的，那么這個問題就很好解決。但是有一些目錄，它們并不是預(yù)置在ROM的，而是在系統(tǒng)啟動或者運行的過程中動態(tài)安裝的，即我們平時所說的虛擬文件系統(tǒng)，例如我們在前面一篇文章中提到的selinux文件系統(tǒng)。這些虛擬文件系統(tǒng)在安裝的時候，SEAndroid安全機(jī)制會根據(jù)安全策略給它們的根目錄設(shè)置相應(yīng)的安全上下文，這樣以后在里面創(chuàng)建的文件就可以從父目錄繼承安全上下文了。 此外，有些文件的安全上下文是不適合使用父目錄的安全上下文的，例如應(yīng)用程序數(shù)據(jù)文件，它們的安全上文需要根據(jù)一定的規(guī)則來特別指定。在前面一篇文章中提到，SEAndroid安全機(jī)制根據(jù)應(yīng)用程序類型的簽名來給其數(shù)據(jù)文件設(shè)置不同的安全上下文，以區(qū)分系統(tǒng)應(yīng)用程序和第三方應(yīng)用程序的數(shù)據(jù)文件。由于無論是系統(tǒng)應(yīng)用程序，還是第三方應(yīng)用程序，它們的數(shù)據(jù)文件都是位于data分區(qū)的data子目錄中的，因此我們需要有一種機(jī)制給在/data/data目錄中創(chuàng)建的數(shù)據(jù)文件設(shè)置不同的安全上下文。我們知道，應(yīng)用程序在安裝的時候，PackageManagerService會通過守護(hù)進(jìn)程installd在/data/data目錄中創(chuàng)建相應(yīng)的數(shù)據(jù)目錄，以后應(yīng)用程序在運行的過程中默認(rèn)創(chuàng)建的數(shù)據(jù)文件就位于對應(yīng)的數(shù)據(jù)目錄中，因此只要給這些數(shù)據(jù)目錄設(shè)置不同的安全上下文，就可以讓不同類型的應(yīng)用程序在運行的過程中創(chuàng)建不同安全上下文的數(shù)據(jù)文件。 我們通過圖1總結(jié)上面描述的文件安全上下文創(chuàng)建方式，如下所示：接下來，我們就分別詳細(xì)分析上述三種文件安全上下文關(guān)聯(lián)方式。 1. 設(shè)置打包在ROM里面的文件的安全上下文 這里我們以ROM里面的system.img為例，說明打包在ROM里面的文件的安全上下文的設(shè)置過程。在前面一篇文章中，我們已經(jīng)分析過system.img的制作過程了，因此這里我們只關(guān)注與安全上下文設(shè)置相關(guān)的邏輯。 生成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.txt $(1) endef $(BUILT_SYSTEMIMAGE): $(FULL_SYSTEMIMAGE_DEPS) $(INSTALLED_FILES_FILE) $(call build-systemimage-target,$) 從這里就可以看出，system.img由命令build-system-target生成。build-system-target命令在執(zhí)行的過程中，又會執(zhí)行兩個子命令。第一個子命令是generate-userimage-prop-dictionary，用來生成一個屬性文件system_image_info.txt。第二個子命令是build_image，用來制作system.img鏡像文件。注意，第二個命令在制作system.img鏡像文件的過程中，會用到第一個命令生成的屬性文件system_image_info.txt。 第一個子命令generate-userimage-prop-dictionary也是實現(xiàn)在build/core/Makefile文件中，如下所示：plain view plain copy 在CODE上查看代碼片派生到我的代碼片SELINUX_FC := $(TARGET_ROOT_OUT)/file_contexts . # $(1): the path of the output dictionary file # $(2): additional key=value pairs to append to the dictionary file. define generate-userimage-prop-dictionary $(if $(INTERNAL_USERIMAGES_EXT_VARIANT),$(hide) echo fs_type=$(INTERNAL_USERIMAGES_EXT_VARIANT) $(1) $(if $(BOARD_SYSTEMIMAGE_PARTITION_SIZE),$(hide) echo system_size=$(BOARD_SYSTEMIMAGE_PARTITION_SIZE) $(1) $(if $(BOARD_USERDATAIMAGE_PARTITION_SIZE),$(hide) echo userdata_size=$(BOARD_USERDATAIMAGE_PARTITION_SIZE) $(1) $(if $(BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE),$(hide) echo cache_fs_type=$(BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE) $(1) $(if $(BOARD_CACHEIMAGE_PARTITION_SIZE),$(hide) echo cache_size=$(BOARD_CACHEIMAGE_PARTITION_SIZE) $(1) $(if $(BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE),$(hide) echo vendor_fs_type=$(BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE) $(1) $(if $(BOARD_VENDORIMAGE_PARTITION_SIZE),$(hide) echo vendor_size=$(BOARD_VENDORIMAGE_PARTITION_SIZE) $(1) $(if $(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG),$(hide) echo extfs_sparse_flag=$(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG) $(1) $(if $(mkyaffs2_extra_flags),$(hide) echo mkyaffs2_extra_flags=$(mkyaffs2_extra_flags) $(1) $(hide) echo selinux_fc=$(SELINUX_FC) $(1) 這里傳過來的第一個參數(shù)便是指向上述的屬性文件system_image_info.txt，它的內(nèi)容是通過一系列的echo命令生成的，每一行都是“key=value“形式。其中，與文件安全上下文相關(guān)的是最后一行：plain view plain copy 在CODE上查看代碼片派生到我的代碼片selinux_fc=$(SELINUX_FC) 變量SELINUX_FC指向一個file_contexts文件。這個file_contexts文件就是我們在前面一篇文章中提到的file_contexts文件，用來描述文件的安全上下文。我們知道，system.img鏡像文件是安裝在目標(biāo)設(shè)備上的/system目錄的，因此我們就觀察一下在file_contexts文件中與/system目錄相關(guān)的文件的安全上下文是如何設(shè)置的。 文件file_contexts最開始是位于build/external/sepolicy目錄中的，經(jīng)過編譯后，就會保存在$OUT/root目錄中，其中$OUT指向的是產(chǎn)品輸出目錄。打開$OUT/root/file_contexts文件，我們就可以看到與/system目錄相關(guān)的文件的安全上下文的設(shè)置規(guī)則：plain view plain copy 在CODE上查看代碼片派生到我的代碼片# # System files # /system(/.*)? u:object_r:system_file:s0 /system/bin/ash u:object_r:shell_exec:s0 /system/bin/mksh u:object_r:shell_exec:s0 /system/bin/sh - u:object_r:shell_exec:s0 /system/bin/run-as - u:object_r:runas_exec:s0 /system/bin/app_process u:object_r:zygote_exec:s0 /system/bin/servicemanager u:object_r:servicemanager_exec:s0 /system/bin/surfaceflinger u:object_r:surfaceflinger_exec:s0 /system/bin/drmserver u:object_r:drmserver_exec:s0 /system/bin/vold u:object_r:vold_exec:s0 /system/bin/netd u:object_r:netd_exec:s0 /system/bin/rild u:object_r:rild_exec:s0 /system/bin/mediaserver u:object_r:mediaserver_exec:s0 /system/bin/dbus-daemon u:object_r:dbusd_exec:s0 /system/bin/installd u:object_r:installd_exec:s0 /system/bin/keystore u:object_r:keystore_exec:s0 /system/bin/debuggerd u:object_r:debuggerd_exec:s0 /system/bin/bluetoothd u:object_r:bluetoothd_exec:s0 /system/bin/wpa_supplicant u:object_r:wpa_exec:s0 /system/bin/qemud u:object_r:qemud_exec:s0 /system/bin/sdcard u:object_r:sdcardd_exec:s0 /system/bin/dhcpcd u:object_r:dhcp_exec:s0 /system/bin/mtpd u:object_r:mtp_exec:s0 /system/bin/pppd u:object_r:ppp_exec:s0 /system/bin/tf_daemon u:object_r:tee_exec:s0 /system/bin/racoon u:object_r:racoon_exec:s0 /system/etc/ppp(/.*)? u:object_r:ppp_system_file:s0 /system/etc/dhcpcd(/.*)? u:object_r:dhcp_system_file:s0 /system/xbin/su u:object_r:su_exec:s0 /system/vendor/bin/gpsd u:object_r:gpsd_exec:s0 /system/bin/ping u:object_r:ping_exec:s0 接下來我們再來看第二個子命令build_image的實現(xiàn)，它是由文件build/tools/releasetools/build_image.py實現(xiàn)的，它的入口函數(shù)main的實現(xiàn)如下所示：python view plain copy 在CODE上查看代碼片派生到我的代碼片def main(argv): . in_dir = argv0 glob_dict_file = argv1 out_file = argv2 glob_dict = LoadGlobalDict(glob_dict_file) image_filename = os.path.basename(out_file) mount_point = if image_filename = system.img: mount_point = system elif image_filename = userdata.img: mount_point = data elif image_filename = cache.img: mount_point = cache elif image_filename = vendor.img: mount_point = vendor else: print sys.stderr, error: unknown image file name , image_filename exit(1) image_properties = ImagePropFromGlobalDict(glob_dict, mount_point) if not BuildImage(in_dir, image_properties, out_file): print sys.stderr, error: failed to build %s from %s % (out_file, in_dir) exit(1) if _name_ = _main_: main(sys.argv1:) 參數(shù)argv1指向的就是我們上面提到的屬性文件system_image_info.txt，最終保存在本地變量glob_dict_file中。另外一個參數(shù)argv2指向的要輸出的system.img文件路徑，最終保存在本地變量out_file中。 函數(shù)LoadGlobalDict用來打開屬性文件system_image_info.txt，并且將它每一行的key和value提取出來，并且保在字典glob_dict中。注意，這個字典glob_dict包含有一個key等于selinux_fc、value等于file_contexts文件路徑的項。 接下來再通過os.path.basename將輸出的文件路徑out_file的最后一項提取出來，就可以得到image_filename的值為”system.img“，因此再接下來就會得到本地變量mount_point的值為”system“，表示我們現(xiàn)在正在打包的是system.img文件。 函數(shù)ImagePropFromGlobalDict用來從字典glob_dict中提取與安裝點mount_point相關(guān)的項，并且保存在另外一個字典中返回給調(diào)用者，它的實現(xiàn)如下所示：python view plain copy 在CODE上查看代碼片派生到我的代碼片def ImagePropFromGlobalDict(glob_dict, mount_point): Build an image property dictionary from the global dictionary. Args: glob_dict: the global dictionary from the build system. mount_point: such as system, data etc. d = def copy_prop(src_p, dest_p): if src_p in glob_dict: ddest_p = str(glob_dictsrc_p) common_props = ( extfs_sparse_flag, mkyaffs2_extra_flags, selinux_fc, skip_fsck, ) for p in common_props: copy_prop(p, p) dmount_point = mount_point if mount_point = system: copy_prop(fs_type, fs_type) copy_prop(system_size, partition_size) elif mount_point = data: copy_prop(fs_type, fs_type) copy_prop(userdata_size, partition_size) elif mount_point = cache: copy_prop(cache_fs_type, fs_type) copy_prop(cache_size, partition_size) elif mount_point = vendor: copy_prop(vendor_fs_type, fs_type) copy_prop(vendor_size, partition_size) return d 從這里就可以看出，函數(shù)ImagePropFromGlobalDict返回給調(diào)用者的字典包含一個以selinux_fc為key值的項，它的值指向上述分析的file_contexts文件。 回到函數(shù)main中，最后它調(diào)用另外一個函數(shù)BuildImage來生成最終的system.img文件，它的實現(xiàn)如下所示：python view plain copy 在CODE上查看代碼片派生到我的代碼片def BuildImage(in_dir, prop_dict, out_file): Build an image to out_file from in_dir with property prop_dict. Args: in_dir: path of input directory. prop_dict: property dictionary. out_file: path of the output image file. Returns: True iff the image is built successfully. build_command = fs_type = prop_dict.get(fs_type, ) run_fsck = False if fs_type.startswith(ext): build_command = mkuserimg.sh . build_command.extend(in_dir, out_file, fs_type, prop_dictmount_point) . if selinux_fc in prop_dict: build_command.append(prop_dictselinux_fc) else: build_command = mkyaffs2image, -f . build_command.append(in_dir) build_command.append(out_file) if selinux_fc in prop_dict: build_command.append(prop_dictselinux_fc) build_command.append(prop_dictmount_point) exit_code = RunCommand(build_command) . return exit_code = 0 參數(shù)prop_dict指向的就是前面調(diào)用ImagePropFromGlobalDict獲得的字典，如果它里面包含有一個key為fs_type的項，并且它的value等于ext，那么就意味著將要制作ext格式的system.img鏡像文件，否則的話，就意味著將要制作yaffs2格式的system.img鏡像文件。前者通過命令mkuserimg來生成，而后者通過命令mkyaffs2image來生成。無論生成的是什么格式的system.img鏡像文件， 只要參數(shù)prop_dict包含有一個key為selinux_fc的項，那么都會將它的value提取出來，并且作為一個參數(shù)傳遞給命令mkuserimg或者mkyaffs2image使用。 根據(jù)前面我們的分析，參數(shù)prop_dict描述的字典包含有key為selinux_fc的項，并且它的value描述的就是我們在上面提到的file_contexts的路徑。當(dāng)我們將這個file_contexts文件路徑傳遞給命令mkuserimg或者mkyaffs2image時，后者就會根據(jù)它設(shè)置的規(guī)則給打包在system.img里面的文件關(guān)聯(lián)安全上下文。這樣我們就獲得了一個關(guān)聯(lián)有安全上下文的system.img鏡像文件了。 2. 設(shè)置虛擬文件系統(tǒng)的安全上下文 這里我們以selinux虛擬文件系統(tǒng)的安裝過程為例，說明虛擬文件系統(tǒng)的安全上下文的設(shè)置過程。在前面的一篇文章中提到，系統(tǒng)啟動之后，會由init進(jìn)程在/sys/fs/selinux中安裝一個selinux虛擬文件系統(tǒng)，接著再加載SEAndroid安全策略到內(nèi)核空間的SELinux LSM模塊中去。 SEAndroid安全策略是由external/sepolicy模塊生成的。觀察external/sepolicy模塊的編譯腳本Android.mk，我們就會發(fā)現(xiàn)，SEAndroid安全策略包含有文件genfs_contexts定義的安全上下文設(shè)置規(guī)則，如下所示：plain view plain copy 在CODE上查看代碼片派生到我的代碼片# include $(CLEAR_VARS) LOCAL_MODULE := sepolicy LOCAL_MODULE_CLASS := ETC LOCAL_MODULE_TAGS := optional LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT) include $(BUILD_SYSTEM)/base_rules.mk sepolicy_policy.conf := $(intermediates)/policy.conf $(sepolicy_policy.conf): PRIVATE_MLS_SENS := $(MLS_SENS) $(sepolicy_policy.conf): PRIVATE_MLS_CATS := $(MLS_CATS) $(sepolicy_policy.conf) : $(call build_policy, security_classes initial_sids access_vectors global_macros mls_macros mls policy_capabilities te_macros attributes *.te roles users initial_sid_contexts fs_use genfs_contexts port_contexts) mkdir -p $(dir $) $(hide) m4 -D mls_num_sens=$(PRIVATE_MLS_SENS) -D mls_num_cats=$(PRIVATE_MLS_CATS) -s $ $ $(hide) sed /dontaudit/d $ $.dontaudit $(LOCAL_BUILT_MODULE) : $(sepolicy_policy.conf) $(HOST_OUT_EXECUTABLES)/checkpolicy mkdir -p $(dir $) $(hide) $(HOST_OUT_EXECUTABLES)/checkpolicy -M -c $(POLICYVERS) -o $ $ $(hide) $(HOST_OUT_EXECUTABLES)/checkpolicy -M -c $(POLICYVERS) -o $(dir $)/$(notdir $).dontaudit $.dontaudit built_sepolicy := $(LOCAL_BUILT_MODULE) sepolicy_policy.conf := 生成的SEAndroid安全策略保存在一個名稱為policy.conf文件中。在生成這個policy.conf文件的過程中，會調(diào)用一個build_policy函數(shù)。傳遞給函數(shù)build_policy的參數(shù)包含了生成SEAndroid安全策略所需要的源文件。其中，源文件genfs_contexts描述的是虛擬文件系統(tǒng)的安全上下文設(shè)置規(guī)則，它的內(nèi)容如下所示：plain view plain copy 在CODE上查看代碼片派生到我的代碼片# Label inodes with the fs label. genfscon rootfs / u:object_r:rootfs:s0 # proc labeling can be further refined (longest matching prefix). genfscon proc / u:object_r:proc:s0 genfscon proc /net/xt_qtaguid/ctrl u:object_r:qtaguid_proc:s0 # selinuxfs booleans can be individually labeled. genfscon selinuxfs / u:object_r:selinuxfs:s0 genfscon cgroup / u:object_r:cgroup:s0 # sysfs labels can be set by userspace. genfscon sysfs / u:object_r:sysfs:s0 genfscon inotifyfs / u:object_r:inotify:s0 genfscon vfat / u:object_r:sdcard_external:s0 genfscon debugfs / u:object_r:debugfs:s0 genfscon fuse / u:object_r:sdcard_internal:s0 從這里我們就可以看出selinux虛擬文件系統(tǒng)關(guān)聯(lián)的安全上下文為”u:object_r:selinuxfs:s0“，這意味著只有那些對Type為”selinuxfs“的文件有訪問權(quán)限的進(jìn)程才可以訪問selinux虛擬文件系統(tǒng)，也就是/sys/fs/selinux目錄下的文件。 3. 設(shè)置應(yīng)用程序數(shù)據(jù)文件的安全上下文 在Android系統(tǒng)中，每一個應(yīng)用程序在/data/data目錄下都有一個以包名命名的目錄，用來作為數(shù)據(jù)保存目錄。這個數(shù)據(jù)目錄是在應(yīng)用程序安裝的時候由守護(hù)進(jìn)程installd創(chuàng)建的。守護(hù)進(jìn)程installd在創(chuàng)建應(yīng)用程序數(shù)據(jù)目錄的時候，會同時設(shè)置它的安全上下文，以便可以對它進(jìn)行保護(hù)。Android應(yīng)用程序的詳細(xì)安裝過程可以參考前面一文，這里只關(guān)注應(yīng)用程序數(shù)據(jù)目錄的創(chuàng)建及其安全上下文設(shè)置的過程。 PackageManagerService負(fù)責(zé)安裝Android應(yīng)用程序，它在啟動的時候會通過SELinuxMMAC類的靜態(tài)成員函數(shù)readInstallPolicy讀取我們在前面一文分析的mac_permissions.xml文件，如下所示：java view plain copy 在CODE上查看代碼片派生到我的代碼片public class PackageManagerService extends IPackageManager.Stub . public PackageManagerService(Context context, Installer installer, boolean factoryTest, boolean onlyCore) . synchronized (mInstallLock) / writer synchronized (mPackages) . mFoundPolicyFile = SELinuxMMAC.readInstallPolicy(); . / synchronized (mPackages) / synchronized (mInstallLock) . 這個函數(shù)定義在文件frameworks/base/services/java/com/android/server/pm/PackageManagerService.java文件中。 SELinuxMMAC類的靜態(tài)成員函數(shù)readInstallPolicy的實現(xiàn)如下所示：java view plain copy 在CODE上查看代碼片派生到我的代碼片public final class SELinuxMMAC . / Signature seinfo values read from policy. private static final HashMap sSigSeinfo = new HashMap(); / Package name seinfo values read from policy. private static final HashMap sPackageSeinfo = new HashMap(); / Locations of potential install policy files. private static final File INSTALL_POLICY_FILE = new File(Environment.getDataDirectory(), system/mac_permissions.xml), new File(Environment.getRootDirectory(), etc/security/mac_permissions.xml), null; . public static boolean readInstallPolicy() return readInstallPolicy(INSTALL_POLICY_FILE); . private static boolean readInstallPolicy(File policyFiles) FileReader policyFile = null; int i = 0; while (policyFile = null & policyFiles != null & policyFilesi != null) try policyFile = new FileReader(policyFilesi); break; catch (FileNotFoundException e) Slog.d(TAG,Couldnt find install policy + policyFilesi.getPath(); i+; . try XmlPullParser parser = Xml.newPullParser(); parser.setInput(policyFile); XmlUtils.beginDocument(parser, policy); while (true) XmlUtils.nextElement(parser); if (parser.getEventType() = XmlPullParser.END_DOCUMENT) break; String tagName = parser.getName(); if (signer.equals(tagName) String cert = parser.getAttributeValue(null, signature); . Signature signature; try signature = new Signature(cert); catch (IllegalArgumentException e) . String seinfo = readSeinfoTag(parser); if (seinfo != null) . sSigSeinfo.put(signature, seinfo); else if (default.equals(tagName) String seinfo = readSeinfoTag(parser); if (seinfo != null) . / The null signature is the default seinfo value sSigSeinfo.put(null, seinfo); else if (package.equals(tagName) String pkgName = parser.getAttributeValue(null, name); . String seinfo = readSeinfoTag(parser); if (seinfo != null) . sPackageSeinfo.put(pkgName, seinfo); else XmlUtils.skipC