SEAndroid策略介绍1
http://en.wikipedia.org/wiki/User:Blueswhen
?
User:Blueswhen
From Wikipedia, the free encyclopediaJump to:?navigation,?searchContents[hide]
|
基礎知識[edit]
SEAndroid在架構(gòu)和機制上與SELinux完全一樣，考慮到移動設備的特點，所以移植到SEAndroid的只是SELinux的一個子集。SEAndroid的安全檢查覆蓋了所有重要的方面包括了域轉(zhuǎn)換、類型轉(zhuǎn)換、進程相關操作、內(nèi)核相關操作、文件目錄相關操作、文件系統(tǒng)相關操作、對設備相關操作、對app相關操作、對網(wǎng)絡相關操作、對IPC相關操作。在有關SELinux的相關內(nèi)容見10.112.25.156/mediawiki/index.php/SEAndroid
Policy[edit]
policy是整個SEAndroid安全機制的核心之一，除了有好的安全架構(gòu)外還必須有好的安全策略以確保讓訪問主體只擁有最小權(quán)限，使程序既能順利執(zhí)行基本功能又能防止被惡意使用。
在SEAndroid中主要采用了兩種強制訪問方法：
- TE
- MLS
這兩種方法都在policy中得以實現(xiàn)，以下內(nèi)容會先對policy規(guī)則的執(zhí)行對象安全上下文有一個詳細的介紹，然后再分別對SEAndroid中的TE機制和MLS機制做詳細介紹。
Policy編譯（考慮刪除）[edit]
在SEAndroid中有關policy的相關源文件都在源碼目錄external/sepolicy中，在Android.mk文件中描述了相關編譯過程，首先會使用m4預處理器將sepolicy中的所有相關文件整合成一個源文件plicy.conf，然后通過checkpolicy 編譯器將policy.conf策略源文件編譯成sepolicy.24的二進制策略文件（24為策略版本號）。checkpolicy編譯器的所有源文件都在external/checkpolicy目錄中，編譯完成的二進制策略文件會在系統(tǒng)啟動時被加載到內(nèi)核中在權(quán)限檢測時使用，而在系統(tǒng)啟動時為一些系統(tǒng)文件添加安全上下文則是依據(jù)另外兩個文件file_contexts和seapp_contexts實現(xiàn)。
標記安全上下文[edit]
SEAndroid中的安全上下文[edit]
SEAndroid的安全上下文與SELinux基本一致（除了MLS檢測在SEAndroid中被強制執(zhí)行），共有4個部分組成分別為user、role、type、sensitivity，以u:object_r:system_data_file:s0為例：
user：安全上下文的第一列為user，在SEAndroid中的user只有一個就是u。
role：第二列表示role，在SEAndroid中的role有兩個，分別為r和object_r。
type：第三列為type，SEAndroid中共定義了139種不同的type。
security level：第四列是專為MLS訪問機制所添加的安全上下文的擴展部分，格式為sensitivity[:category list][- sensitivity[:category list]]，例如s0 - s15:c0.c1023，其中s0之后的內(nèi)容可以不需要，冒號后面的內(nèi)容是category，sensitivity和category組合一起聲明了當前的安全級別(security level)，“-”號左右分別標識了安全級別的最低和最高，這一列的參數(shù)將在MLS約束檢查時用到，“15”、“1023”表示了sensitivity和category的最大值，這一參數(shù)可在Android.mk中定義。
安全上下文中最重要的部分就是第三列的type了，對于進程type被稱為domain，type是整個SEAndroid中最重要的一個參量，所有的policy都圍繞這一參量展開，所以為系統(tǒng)中每個文件標記上合適的type就顯得極為重要了。在SEAndroid中關于安全上下文配置的核心文件主要是file_contexts文件、seapp_contexts文件和ocontexts文件。
安全上下文標記的四種方式[edit]
- 基于策略語句標記
在SEAndroid的策略語言type_transition規(guī)則可以指定新創(chuàng)建的文件或目錄的標簽（安全上下文），通常情況下新創(chuàng)建文件的標簽和其父目錄的標簽一致，但是可以使用type_transition規(guī)則為其指定特定的標簽，有關transition的內(nèi)容將在之后更詳細地說明。
- 默認標記
默認的標記行為在有關的策略標記規(guī)則不存在時使用，以及那些根本就沒有關聯(lián)策略標記規(guī)則的客體類別使用，大部分客體類別的默認標記都繼承了創(chuàng)建它的進程/或包括客體的容器的安全上下文。
- 程序請求標記
對于某些客體類別，SELinux提供了許多API允許程序明確地請求標記，這對于新創(chuàng)建的和已經(jīng)存在的客體實例都一樣。對于那些存儲在支持標記的文件系統(tǒng)上的與文件有關的客體，SEAndroid通過調(diào)用相應API既能在創(chuàng)建文件時設置安全上下文，也能對與文件有關的客體進行重新標記，只需要適當?shù)膔elabelfrom 和relabelto許可就可以明確地改變一個客體的標記，這些許可由policy進行嚴密控制。
- 初始SID標記
安全上下文在用戶態(tài)通過字符串來描述，而在內(nèi)核中使用context數(shù)據(jù)結(jié)構(gòu)來表示它。給每個context數(shù)據(jù)結(jié)構(gòu)都分配一個u32 sid，該sid保存在描述內(nèi)核數(shù)據(jù)結(jié)構(gòu)的安全上下文中。內(nèi)核驅(qū)動使用sidtab哈希表來描述所有已經(jīng)分配了sid的context數(shù)據(jù)結(jié)構(gòu)，通過查詢該哈希表即可得到一個安全上下文所對應的sid。
幾乎所有sid的分配和注冊都是在運行時完成的，但是在refpolicy中定義了27個“Initial SID”，用于在內(nèi)核驅(qū)動初始化時、由init進程通過selinuxfs接口加載policy之前，描述相應內(nèi)核設施的初始安全屬性。
初始SID提供了一種特殊的默認標記行為，初始SID適用于兩種環(huán)境：在系統(tǒng)初始化策略還沒有載入前對一部分內(nèi)核相關的客體進行標記，以及當客體的安全上下文無效或安全上下文丟失時使用。初始sid的內(nèi)容被定義在了initial_sids文件中，在ocontexts文件中同時聲明了初始sid相應的安全上下文。
為文件系統(tǒng)和文件系統(tǒng)中的文件標記安全上下文[edit]
在SEAndroid中存在兩種文件系統(tǒng)，一種是常見的文件系統(tǒng)包括傳統(tǒng)的、本地文件系統(tǒng)都是用來在磁盤上或可移動介質(zhì)上存儲數(shù)據(jù)（如ext3和XFS），和為了兼容其它操作系統(tǒng)的非本地文件系統(tǒng)（如iso9660和vfat），另一種是存在于內(nèi)存中被稱為偽文件系統(tǒng)，它是用于內(nèi)核和用戶空間之間的通訊（如proc和sysfs），通過selinux庫中提供的API函數(shù)完成。
文件系統(tǒng)的初始安全上下文的標記是在文件系統(tǒng)掛載時完成，另外普通文件系統(tǒng)上的文件在文件創(chuàng)建時就標記好了安全上下文并和文件一起存儲在磁盤上，而偽文件系統(tǒng)只在運行時才會為其中的文件標記安全上下文。
為文件系統(tǒng)標記安全上下文是對該文件系統(tǒng)的所有inode節(jié)點進行安全上下文的標記，這些標記是最原始的標記，之后如有新的文件被創(chuàng)建并賦予了相應的安全上下文標記則將會執(zhí)行覆蓋操作保留最新的安全上下文。
對于文件系統(tǒng)的標記SEAndroid依據(jù)各文件系統(tǒng)的不同屬性擁有不同的機制：
- 基于支持擴展屬性的文件系統(tǒng)標記（即允許保存安全上下文這一擴展屬性的文件系統(tǒng)）（fs_use_xattr）
這一類文件系統(tǒng)包括yaffs2、jffs2、ext2、ext3、ext4、xfs、btrfs，它們的一個共性是都支持在磁盤上永久保存安全上下文這一擴展屬性信息。它們都用同一個安全上下文u:object_r:labeledfs:s0被統(tǒng)一標記，這些都在ocontexts文件中被聲明，使用fs_use_xattr語法實現(xiàn)。
另外對于這些有唯一且永久的節(jié)點號的傳統(tǒng)文件系統(tǒng)來說，SEAndroid會用一個永久的標記映射來決定文件系統(tǒng)內(nèi)的節(jié)點的安全上下文和文件系統(tǒng)本身的安全上下文，這個永久的標記映射是由一個或多個配置文件組成，在SEAndroid中就是file_contexts文件和seapp_contexts文件，這兩個文件會和policy二進制文件一起構(gòu)成整個SEAndroid的安全策略體系。
file_contexts文件對相應目錄的使用正則表達式進行匹配，被匹配到的目錄或文件都將被標記上相應的安全上下文，這個過程發(fā)生在文件系統(tǒng)標記完成之后執(zhí)行。
- 基于任務的文件系統(tǒng)標記（fs_use_task）
使用基于任務的標記時，在SEAndroid中使用 fs_use_task 規(guī)則聲明新的與文件有關的客體繼承創(chuàng)建它們的進程的安全上下文。使用基于任務的標記的文件系統(tǒng)不支持程序請求的標記，這種類型的標記行為多用于對于不真實存儲用戶數(shù)據(jù)但支持某種類型的內(nèi)核資源的偽文件系統(tǒng)上。在SEAndroid中sockfs，pipefs都是基于這一方式進行安全上下文的標記，具體被標記的安全上下文內(nèi)容都在ocontexts文件中有詳細聲明。
- 基于轉(zhuǎn)換的文件系統(tǒng)標記（fs_use_trans）?基于轉(zhuǎn)換的文件系統(tǒng)標記與基于任務的文件系統(tǒng)標記非常類似，都使用的是偽文件系統(tǒng)，不同的是基于轉(zhuǎn)換的安全上下文標記是基于類型轉(zhuǎn)換規(guī)則（type_transition）實現(xiàn)的。在這樣的文件系統(tǒng)上創(chuàng)建的文件都需要有一套相關的type_transition規(guī)則來完成。如果沒有找到相應的type_transition規(guī)則，文件就會使用文件系統(tǒng)的初始安全上下文，文件系統(tǒng)的初始安全上下文被定義在了ocontexts文件中， 在SEAndroid中有devpfs、tmpfs、devtmpfs、shm、mqueue這些偽文件系統(tǒng)使用這一機制進行安全上下文標記。
- 一般方式標記安全上下文（genfscon）
genfscon語句用于運行時標記偽文件系統(tǒng)和不支持擴展屬性的傳統(tǒng)文件系統(tǒng)。在SEAndroid中文件系統(tǒng)rootfs、proc、selinuxfs、cgroup、sysfs、inotifyfs、vfat、debugfs、fuse，都是采用這一方式進行安全上下文的標記，在ocontexts文件中定義了這些文件系統(tǒng)相應的安全上下文內(nèi)容。
TE(Type Enforcement)[edit]
TE強制訪問方式是SEAndroid中的最主要的安全手段，所有關于TE的強制訪問規(guī)則都被定義在了后綴為te的文件中，在te文件中基本能總結(jié)為完成如下操作：
- 對type類型的定義和將type歸到相應的attribute中
SEAndroid為所有type共定義了17個attribute：
dev_type:
domain:
這一attribute包含了如下所列的所有關于進程的type，通常策略中的訪問主體也就是進程所在的domain都包含在了這一attribute中。 adbd trusted_app browser_app untrusted_app bluetoothd dbusd debuggerd drmserver gpsd init installd kernel keystore mediaserver netd nfc qemud radio rild servicemanage shell surfaceflinger su system_app system ueventd vold wpa zygotefs_type:
這一attribute包含了所有與文件系統(tǒng)相關的type。如下所列，大多是虛擬文件系統(tǒng)。 device labeledfs pipefs sockfs rootfs proc selinuxfs cgroup sysfs sysfs_writable inotify devpts tmpfs shm mqueue sdcard debugfsfile_type:
這一attribute包含了所有存在于非偽文件系統(tǒng)的相關文件的type，數(shù)量過多不再列舉。exec_type:
這一attribute包含了所有關于domian接入點的type，多被用在domain transition中，如下所列。 bluetoothd_exec dbusd_exec debuggerd_exec drmserver_exec gpsd_exec installd_exec keystore_exec mediaserver_exec netd_exec qemud_exec rild_exec servicemanager_exec surfaceflinger_exec vold_exec wpa_exec zygote_execdata_file_type:
這一attribute包含了所有在/data目錄下的文件type，如下所列。 system_data_file anr_data_file tombstone_data_file apk_data_file dalvikcache_data_file shell_data_file gps_data_file bluetoothd_data_file bluetooth_data_file keystore_data_file vpn_data_file systemkeys_data_file wifi_data_file radio_data_file nfc_data_file app_data_filesysfs_type:
這一attribute包含了在sysfs文件系統(tǒng)下的所有文件的type，在SEAndroid中只有sysfs_writable包含在這個attribute中。node_type:
這一attribute包含了所有與nodes/hosts有關的type，在SEAndroid中只有node包含在這個attribute中。netif_type:
這一attribute包含了所有與網(wǎng)絡接口相關的type，在SEAndroid中只有netif包含在這個attribute中。port_type:
這一attribute包含了所有與網(wǎng)絡端口相關的type，在SEAndroid中只有port包含在這個attribute中。mlstrustedsubject:
這一attribute包含了所有能越過MLS檢查的主體domain。mlstrustedobject:
這一attribute包含了所有能越過MLS檢查的客體type。unconfineddomain:
這一attribute包含了所有擁有無限權(quán)限的type。appdomain:
這一attribute包含了所有與app相關的type，如下所列。 trusted_app browser_app untrusted_app nfc radio shell system_appnetdomain:
這一attribute包含了所有與需要訪問網(wǎng)絡的app相關的type，如下所列。 trusted_app browser_app gpsd mediaserver radio rild systembluetoothdomain:
這一attribute包含了所有與需要訪問bluetooth的app相關的type，如下所列。 trusted_app radio systembinderservicedomain:
這一attribute包含了所有與binder服務相關的type，如下所列。 mediaserver surfaceflinger system- 通過allow語句制定主體客體強制訪問規(guī)則（白名單規(guī)則，不再規(guī)則中的都默認為非法操作）
- 通過type_transition語句制定tpye類型轉(zhuǎn)換規(guī)則
- 通過dontaudit語句聲明對一些被安全策略拒絕的訪問不再進行審核。
SEAndroid為系統(tǒng)定義了33個te策略文件，這33個策略文件是：
adbd.te、file.te、su.te、app.te、gpsd.te、netd.te、system.te、bluetoothd.te、init.te、net.te、ueventd.te、bluetooth.te、installd.te、nfc.te、unconfined.te、cts.te、kernel.te、qemud.te、vold.te、dbusd.te、keystore.te、radio.te、wpa_supplicant.te、debuggerd.te、mediaserver.te、rild.te、zygote.te、device.te、servicemanager.te、domain.te、shell.te、drmserver.te、surfaceflinger.te。
對上述33個文件根據(jù)其策略規(guī)則針對的對象可分為三類：
- 針對attribute的策略制定：
attribute是多個具有共性的type的集合，以下六個文件主要是直接針對attribute制定的策略，這種針對attribute制定的策略也就是同時對多個type制定策略一樣。
unconfined.te
domain.te
主要是為domain屬性制定策略，為所有歸在其中的訪問主體制定一些公共的策略。CTS.te
主要是為appdomain制定策略，這些策略一般是在對app進行CTS測試時用到。bluetooth.te
主要是為bluetoothdomain制定策略。net.te
主要是為netdomain制定策略，這些策略主要是關于對sockets、ports的訪問以及與netd的通信。file.te
這個文件主要定義了各文件系統(tǒng)的type，各文件的type，socket的type，以及制定了在不同文件系統(tǒng)中創(chuàng)建文件的規(guī)則。- 針對daemon domain的策略制定:
adbd.te、gpsd.te、netd.te、bluetoothd.te、zygote.te、ueventd.te、installd.te、vold.te、dbusd.te、keystore.te、debuggerd.te、mediaserver.te、rild.te、drmserver.te、surfaceflinger.te、qemud.te、servicemanager.te、su.te、shell.te、wpa_supplicant.te
這些文件都是為系統(tǒng)中的daemon進程進行策略的制定，它們都有著相應的daemon domain。
- 針對系統(tǒng)其他模塊的策略制定:
最后的7個文件分別對系統(tǒng)的其他模塊進行策略制定。
app.te
system.te
這一文件主要針對的是系統(tǒng)app和system server進程。對系統(tǒng)app訪問binder、system data files、dalvikcatch、keystone等進行權(quán)限控制， 對system server訪問網(wǎng)絡、bluetooth、netlink、app、binder、device、data files、socket、cache files等進行權(quán)限控制。init.te
在這一文件中聲明了init擁有無限權(quán)限。nfc.te
在這一文件中制定了nfc domain對nfc設備和相關數(shù)據(jù)文件的訪問權(quán)限。kernel.te
在這一文件中聲明了kernel擁有無限權(quán)限。radio.te
在這一文件中制定了radio domain對init、rild和相關數(shù)據(jù)文件的訪問權(quán)限。device.te
在這一文件中定義了所有跟設備相關的type，并將這些type都歸到了dev_type屬性中。
接下來對SEAndroid中制定的各種繁多的策略做一個簡單分類：
轉(zhuǎn)換(transition)[edit]
- domain transition
某個程序被執(zhí)行時，其相應的進程會處在相應的domain中，但當程序根據(jù)需要又執(zhí)行了另一個程序時，進程就需要根據(jù)type transition規(guī)則進行domain transition以獲得必要的權(quán)限從而使新進程能順利訪問到相關文件。另一個transition的原因是原有的domain權(quán)限過大，為了不讓新啟動的進程也繼承過大的權(quán)限，因此需要domain transition。 在SEAndroid中幾乎全部daemon進程都需要從init進程中啟動，這就需要從init domian轉(zhuǎn)換到daemon domain這一操作。
需要從init domain轉(zhuǎn)換到daemon domain的進程有bluetoothd、dbusd、debuggerd、drmserver、gpsd、installd、keystore、mediaserver、netd、qemud、rild、servicemanager、surfaceflinger、vold、wpa_supplicant、zygote。
除了從init domain轉(zhuǎn)換到其他daemon domain外，還有從adbd domain轉(zhuǎn)換到shell domain，從shell domain轉(zhuǎn)換到su domain，以及從zygote domain轉(zhuǎn)換到system和appdomain，這主要是因為Android中的大部分進程都是由zygote創(chuàng)建。
- type transition
type_transition 規(guī)則被用在Domain Transition中 或者確定新創(chuàng)建對象的標簽，以重載其默認的、從父目錄(containing directory)所繼承的標簽。通常情況下新創(chuàng)建文件的標簽和其父目錄的標簽一致,但是可以使用type_transition規(guī)則為其指定特定的標簽。
例如在SEAndroid中gpsd domain在以gps_data_file為type的目錄下創(chuàng)建socket文件時，這些文件的type將會依照在策略中設定的type_transition規(guī)則而轉(zhuǎn)換為gps_sokcket。
system domain在以wifi_data_file為type的目錄下創(chuàng)建socket文件時，文件的type將會依照type_transition規(guī)則轉(zhuǎn)變?yōu)閟ystem_wpa_socket。
文件和目錄[edit]
在許多主體訪問客體的情況中都需要對相關文件進行操作，SEAndroid對于牽涉到blk_file,chr_file,fd,fifo_file,lnk_file,sock_file和一般的file都進行了相關的策略制定。
還制定了一些domain指定type的目錄、一般文件和鏈接文件只有讀的權(quán)限的策略，例如dbusd domain對system type和bluetoothd type的目錄和文件只有讀的權(quán)限,domain attribute對proc、sysfs、inotify、cgroup這些虛擬文件系統(tǒng)中的文件和目錄也只有讀的權(quán)限，另外還有mediaserver domain對sdcard type的目錄和文件只有讀的權(quán)限，shell domain對apk_data_file的目錄和文件只有讀的權(quán)限、system domain對mediaserver和appdomain的目錄和文件只有讀的權(quán)限。
也制定了主體domain對不同文件系統(tǒng)的相關操作權(quán)限，以及當某個domain需要創(chuàng)建tmpfs、shmem、ashmem文件時，根據(jù)主體domain定義一個獨特的type并對新創(chuàng)建的文件進行標記的策略。在SEAndroid里這條策略被用在了init、system、ueventd中。
無限權(quán)限[edit]
在SEAndroid中共定義了三個擁有巨大權(quán)限的attribute分別是mlstrustedsubject、mlstrustedobject、unconfineddomain，被分類到mlstrustedsubject的type在充當主體domain是可以越過MLS檢查，被分類到mlstrustedobject的type在充當客體時可以越過MLS檢查，被分到unconfineddomain的type則擁有所有權(quán)限可對客體進行任意操作。
在SEAndroid中被分在mlstrustedsubject attribute中的type有adbd、debuggerd、drmserver、init、installd、kernel、mediaserver、netd、surfaceflinger、su、system、vold、zygote。
被分在mlstrustedobject attribute中的type有alarm_device、ashmem_device、binder_device、log_device、mtp_device、nv_device、powervr_device、ptmx_device、null_device、cgroup、sysfs、sysfs_writable、sysfs_writable、sysfs_writable、debugfs、apk_data_file、cache_file、dnsproxyd_socket。
被分在unconfineddomain的type有init、kernel、su。
設備[edit]
關于設備這里重點提一下bluetooth，在SEAndroid中只對三個type提供bluetooth訪問權(quán)限分別是trusted_app、radio、system。
App[edit]
在SEAndroid中指定了trusted_app、browser_app、untrusted_app、nfc、radio、shell、system_app這些type對系統(tǒng)中的所有app擁有適當?shù)脑L問權(quán)限，并能對ashmem objects使用獨特的type進行標記。
網(wǎng)絡[edit]
SEAndroid對trusted_app、browser_app、gpsd、mediaserver、mediaserver、rild、system這些type授予了訪問網(wǎng)絡的權(quán)限。
在SEAndroid中系統(tǒng)對各類socket都制定了相應的策略，這些socket包括appletalk_socket(轉(zhuǎn)為apple公司產(chǎn)品通信而設)、dccp_socket、netlink_audit_socket、netlink_dnrt_socket、netlink_firewall_socket、netlink_ip6fw_socket、netlink_kobject_uevent_socket、netlink_nflog_socket、、etlink_route_socket、netlink_selinux_socket、netlink_socket、netlink_tcpdiag_socket、netlink_xfrm_socket、packet_socket、rawip_socket、tcp_socket、tun_socket、udp_socket、unix_dgram_socket、unix_stream_socket。
SEAndroid還指定了如下策略允許一個本地socket從指定的客戶端domain通過指定的socket連接到指定的服務端domain，第一列是客戶端domain，第二列是指定的socket，第三列是服務端domain。
另外SEAndroid只允許system和wpa這兩個domain可以讓一個本地socket以system和wpa任何一方為客戶端另一方為服務端并通過某個socket進行數(shù)據(jù)包的發(fā)送。 運行一個本地socket從客戶端domain通過發(fā)送數(shù)據(jù)包到服務端domain。
IPC[edit]
SEAndroid只允許adbd、appdomain、drmserver、mediaserver、surfaceflinger、system這些type或attribute通過servicemanager使用binder IPC。
SEAndroid只允許指定的客戶端domain對指定的服務端domain使用binder IPC，如以下所列，第一列是指定的客戶端domain，第二列是指定的服務端domain。
SEAndroid只允許指定的客戶端domain傳送由服務端創(chuàng)建的binder references，如以下所列，第一列是指定的客戶端domain，第二列是指定的服務端domain。
MLS(Multi-Level Security)[edit]
什么是MLS，為何要引入MLS[edit]
MLS稱為多級別安全是另一種強制訪問控制方法，特別適合于政府機密數(shù)據(jù)的訪問控制，早期對計算機安全的研究大多數(shù)都是以在操作系統(tǒng)內(nèi)實現(xiàn)MLS訪問控制為驅(qū)動的。所有MLS的使用都是建立在TE安全的基礎之上。在SELinux中MLS是一個可選訪問控制方式，而在SEAndroid中則是被作為安全訪問方式的其中之一。
MLS中的相關參量
[edit]
在SEAndroid中mls的相關參量就是安全上下文的第四列稱為security level，在安全上下文第四列中可以有一個或者兩個security level，第一個表示低安全級別，第二個表示高安全級別。
每個security level由兩個字段組成：
- sensitivity
sensitivity有著嚴格的分級，它反應了一個有序的數(shù)據(jù)靈敏度模型，如政府分類控制中的絕密，機密和無密級。
- category
category是無序的，它反應的是數(shù)據(jù)劃分的需要。
基本思路是對于要訪問的數(shù)據(jù)你同時需要足夠的sensivity和正確的category。
在SEAndroid中sensitivity只有一個級別即s0，category共有1024個，因此最低安全級別就是s0，最高安全級別就是s0:c0.c1023。
security level之間的三種運算關系：
- dom
需要主體sensitiviety大于客體，同時客體的category是主體的一個子集。
- domby
與dom完全相反
- eq
主體客體的sensitivity和category分別相同。
高的security level對低的security level擁有dom，低的security level對高的security level關系為domby（與dom相反），同級的security關系是eq，這三種關系運算符是SEAndroid中特有的。
MLS對進程的約束[edit]
- 限制進程的domain轉(zhuǎn)換
對于從一個domain轉(zhuǎn)換到另一個domain的操作要求兩個domain的高級別security level和低級別security level同時相等才能許可轉(zhuǎn)換，除非是待轉(zhuǎn)換的domain屬于對mls無限權(quán)限的type。
- 限制進程讀操作
只有當主體domain的低級別security level對客體domain的低級別security level具有dom關系時，或者主體domian是屬于對mls無限權(quán)限的type，主體才能對客體具有讀操作的許可。
這一讀操作具體是指：
總結(jié)一下就是MLS限制了低級別進程向高級別進程進行讀的操作，即不能上讀。
- 限制進程寫操作
只有當主體domain的低級別security level對客體domain的低級別security level具有domby關系時，或者主體domain是屬于對mls無限權(quán)限的type，主體才能對客體具有寫操作的許可。
寫操作具體是指：
總結(jié)一下就是MLS限制了高級別進程對低級別進程寫的操作，即不能下寫。
MLS對socket的約束[edit]
- 進程對local socket的訪問限制
只有當主體進程的domain的高級別security level和低級別security level分別與客體local socket的type的security level相同時即滿足eq關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，主體進程才對local socket擁有了某些訪問權(quán)限。
這些訪問權(quán)限是指：
- 對socket的datagram發(fā)送的限制
只有當發(fā)送方的低級別security level與接受方的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，發(fā)送方才對接受方擁有了發(fā)送權(quán)限。
- 對客戶端socket和服務端socket建立連接的限制
只有當客戶端的低級別security level與服務端的低級別security level滿足eq關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，客戶端就能獲得連接服務端的權(quán)限。
MLS對文件和目錄的約束[edit]
- 對文件的創(chuàng)建和重新標記的限制
對文件操作時，要求客體的文件安全上下文只有一個security level即沒有低級別和高級別security level或者說是這兩個級別相同。 當主體domain的低級別security level對客體文件的低級別security level相同時，或者主體具有對mls有無限權(quán)限的type時，主體對客體文件擁有創(chuàng)建、和重新標記安全上下文的權(quán)限。
- 對目錄的讀操作的限制
只有當主體的低級別security level對客體目錄的低級別security level滿足dom關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，主體能對目錄擁有如下權(quán)限：
總結(jié)一下就是對目錄的訪問不能上讀。
- 對文件的讀操作的限制
只有當主體的低級別security level對客體文件的低級別security level滿足dom關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，主體能對文件擁有如下權(quán)限：
總結(jié)一下就是對文件的訪問不能上讀。
- 對目錄的寫操作的限制
只有當主體的低級別security level對客體目錄的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，主體能對目錄擁有如下權(quán)限：
總結(jié)一下就是對目錄訪問不能下寫。
- 對文件的寫操作的限制
只有當主體的低級別security level對客體文件的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權(quán)限的type時，主體能對文件擁有如下權(quán)限：
總結(jié)一下就是對文件訪問不能下寫。
MLS對IPC的約束[edit]
- 對IPC創(chuàng)建和銷毀的限制
要求客體的IPC對象只有一個security level。
只有當主體的低級別security level與客體的低級別security level滿足eq關系時，或者主體具有對mls無限權(quán)限的type時，主體能對客體IPC擁有創(chuàng)建和銷毀的權(quán)限。
- 對IPC讀操作的限制
只有當主體的低級別security level對客體IPC的低級別security level滿足dom關系時，或者主體具有對mls無限權(quán)限的type時，主體能對客體IPC擁有如下權(quán)限：
總結(jié)一下就是對IPC訪問不能上讀。
- 對IPC寫操作的限制
只有當主體的低級別security level對客體IPC的低級別security level滿足domby關系時，或者主體具有對mls無限權(quán)限的type時，主體能對客體IPC擁有如下權(quán)限：
總結(jié)一下就是對IPC訪問不能下寫。
Retrieved from "http://en.wikipedia.org/w/index.php?title=User:Blueswhen&oldid=478968612"Navigation menu
Personal tools
- Create account
- Log in
Namespaces
- User page
- Talk
Variants
Views
- Read
- Edit
- View history
Actions
Search
Navigation
- Main page
- Contents
- Featured content
- Current events
- Random article
- Donate to Wikipedia
Interaction
- Help
- About Wikipedia
- Community portal
- Recent changes
- Contact Wikipedia
Toolbox
- What links here
- Related changes
- User contributions
- Logs
- Upload file
- Special pages
- Permanent link
- Page information
Print/export
- Create a book
- Download as PDF
- Printable version
Languages
總結(jié)
以上是生活随笔為你收集整理的SEAndroid策略介绍1的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android Low Battery
- 下一篇： android中SELINUX规则分析和