常用的APT命令參數：

apt-cache search package 搜尋套件
apt-cache show package 獲取套件的相關信息，如說明、大小、版本等

apt-cache depends package 相依性：可以用這個指令來看到某個rpm的所有相依性檔案
apt-cache rdepends package 是查看該套件被哪些套件依賴

sudo apt-get install package 安裝套件
sudo apt-get install package -- reinstall 重新安裝套件
sudo apt-get -f install 修復安裝"-f = --fix-missing"

sudo apt-get remove package 刪除套件，如有相依性套件時會一併移除 
sudo apt-get remove package -- purge 刪除套件，套件括刪除配置文件等

sudo apt-get update 取得在/etc/apt/sources.list 內的遠端伺服器的套件檔案清單
sudo apt-get upgrade 更新已安裝的套件，--fix-missing(如果有些套件無法取得)
sudo apt-get dist-upgrade 升級系統

sudo apt-get build-dep package 安裝相關的編譯環境

apt-get source package 下載該套件的源代碼

sudo apt-get clean 當使用 apt-get install 指令安裝套件，下載下來的rpm會放置於 
                   /var/cache/apt/archives，使用本指令可以將之清除
sudo apt-get check 檢查套件

 

[轉] Android selinux安全策略

基礎知識 SEAndroid在架構和機制上與SELinux完全一样，考慮到移動設備的特點，所以移植到SEAndroid的只是SELinux的一個子集。SEAndroid的安全檢查覆蓋了所有重要的方面


SEAndroid在架構和機制上與SELinux完全一样，考慮到移動設備的特點，所以移植到SEAndroid的只是SELinux的一個子集。SEAndroid的安全檢查覆蓋了所有重要的方面包括了域轉換、類型轉換、進程相關操作、內核相關操作、文件目錄相關操作、文件系統相關操作、對設備相關操作、對app相關操作、對網络相關操作、對IPC相關操作。 
Policy 

policy是整個SEAndroid安全機制的核心之一，除了有好的安全架構外還必須有好的安全策略以確保讓訪問主體只擁有最小權限，使程序既能順利執行基本功能又能防止被惡意使用。 
在SEAndroid中主要采用了兩種強制訪問方法： 
TE 
MLS 
這兩種方法都在policy中得以實現，以下內容會先對policy規則的執行對象安全上下文有一個詳細的介紹，然後再分別對SEAndroid中的TE機制和MLS機制做詳細介紹。 
標記安全上下文 

SEAndroid中的安全上下文 
SEAndroid的安全上下文與SELinux基本一致（除了MLS檢測在SEAndroid中被強制執行），共有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之後的內容可以不需要，冒號後面的內容是category，sensitivity和category組合一起聲明了當前的安全級別(security level)，“-”號左右分別標識了安全級別的最低和最高，這一列的参數將在MLS約束檢查時用到，“15”、“1023”表示了sensitivity和category的最大值，這一参數可在Android.mk中定義。 
安全上下文中最重要的部分就是第三列的type了，對於進程type被稱为domain，type是整個SEAndroid中最重要的一個参量，所有的policy都圍繞這一参量展開，所以为系統中每個文件標記上合适的type就顯得極为重要了。在SEAndroid中關於安全上下文配置的核心文件主要是file_contexts文件、seapp_contexts文件和ocontexts文件。 
安全上下文標記的四種方式 
基於策略語句標記 
在SEAndroid的策略語言type_transition規則可以指定新創建的文件或目錄的標簽（安全上下文），通常情況下新創建文件的標簽和其父目錄的標簽一致，但是可以使用type_transition規則为其指定特定的標簽，有關transition的內容將在之後更詳細地說明。 
默認標記 
默認的標記行为在有關的策略標記規則不存在時使用，以及那些根本就沒有關聯策略標記規則的客體類別使用，大部分客體類別的默認標記都繼承了創建它的進程/或包括客體的容器的安全上下文。 
程序請求標記 
對於某些客體類別，SELinux提供了許多API允許程序明確地請求標記，這對於新創建的和已經存在的客體實例都一样。對於那些存儲在支持標記的文件系統上的與文件有關的客體，SEAndroid通過調用相應API既能在創建文件時設置安全上下文，也能對與文件有關的客體進行重新標記，只需要适當的relabelfrom 和relabelto許可就可以明確地改變一個客體的標記，這些許可由policy進行嚴密控制。 
初始SID標記 
安全上下文在用戶態通過字符串來描述，而在內核中使用context數據結構來表示它。给每個context數據結構都分配一個u32 sid，該sid保存在描述內核數據結構的安全上下文中。內核驅動使用sidtab哈希表來描述所有已經分配了sid的context數據結構，通過查詢該哈希表即可得到一個安全上下文所對應的sid。 
幾乎所有sid的分配和注冊都是在運行時完成的，但是在refpolicy中定義了27個“Initial SID”，用於在內核驅動初始化時、由init進程通過selinuxfs接口加載policy之前，描述相應內核設施的初始安全屬性。 
初始SID提供了一種特殊的默認標記行为，初始SID适用於兩種環境：在系統初始化策略還沒有載入前對一部分內核相關的客體進行標記，以及當客體的安全上下文無效或安全上下文丟失時使用。初始sid的內容被定義在了initial_sids文件中，在ocontexts文件中同時聲明了初始sid相應的安全上下文。 

为文件系統和文件系統中的文件標記安全上下文 
在SEAndroid中存在兩種文件系統，一種是常見的文件系統包括傳統的、本地文件系統都是用來在磁盤上或可移動介質上存儲數據（如ext3和XFS），和为了兼容其它操作系統的非本地文件系統（如iso9660和vfat），另一種是存在於內存中被稱为偽文件系統，它是用於內核和用戶空間之間的通訊（如proc和sysfs），通過selinux庫中提供的API函數完成。 
文件系統的初始安全上下文的標記是在文件系統掛載時完成，另外普通文件系統上的文件在文件創建時就標記好了安全上下文並和文件一起存儲在磁盤上，而偽文件系統只在運行時才會为其中的文件標記安全上下文。 
为文件系統標記安全上下文是對該文件系統的所有inode節點進行安全上下文的標記，這些標記是最原始的標記，之後如有新的文件被創建並賦予了相應的安全上下文標記則將會執行覆蓋操作保留最新的安全上下文。 

對於文件系統的標記SEAndroid依據各文件系統的不同屬性擁有不同的機制： 
基於支持擴展屬性的文件系統標記（即允許保存安全上下文這一擴展屬性的文件系統）（fs_use_xattr） 
這一類文件系統包括yaffs2、jffs2、ext2、ext3、ext4、xfs、btrfs，它們的一個共性是都支持在磁盤上永久保存安全上下文這一擴展屬性信息。它們都用同一個安全上下文u:object_r:labeledfs:s0被統一標記，這些都在ocontexts文件中被聲明，使用fs_use_xattr語法實現。 
另外對於這些有唯一且永久的節點號的傳統文件系統來說，SEAndroid會用一個永久的標記映射來决定文件系統內的節點的安全上下文和文件系統本身的安全上下文，這個永久的標記映射是由一個或多個配置文件組成，在SEAndroid中就是file_contexts文件和seapp_contexts文件，這兩個文件會和policy二進制文件一起構成整個SEAndroid的安全策略體系。 
file_contexts文件對相應目錄的使用正則表達式進行匹配，被匹配到的目錄或文件都將被標記上相應的安全上下文，這個過程發生在文件系統標記完成之後執行。 

基於任務的文件系統標記（fs_use_task） 
使用基於任務的標記時，在SEAndroid中使用 fs_use_task 規則聲明新的與文件有關的客體繼承創建它們的進程的安全上下文。使用基於任務的標記的文件系統不支持程序請求的標記，這種類型的標記行为多用於對於不真實存儲用戶數據但支持某種類型的內核資源的偽文件系統上。在SEAndroid中sockfs，pipefs都是基於這一方式進行安全上下文的標記，具體被標記的安全上下文內容都在ocontexts文件中有詳細聲明。 

基於轉換的文件系統標記（fs_use_trans） 基於轉換的文件系統標記與基於任務的文件系統標記非常類似，都使用的是偽文件系統，不同的是基於轉換的安全上下文標記是基於類型轉換規則（type_transition）實現的。在這样的文件系統上創建的文件都需要有一套相關的type_transition規則來完成。如果沒有找到相應的type_transition規則，文件就會使用文件系統的初始安全上下文，文件系統的初始安全上下文被定義在了ocontexts文件中， 在SEAndroid中有devpfs、tmpfs、devtmpfs、shm、mqueue這些偽文件系統使用這一機制進行安全上下文標記。 

一般方式標記安全上下文（genfscon） 
genfscon語句用於運行時標記偽文件系統和不支持擴展屬性的傳統文件系統。在SEAndroid中文件系統rootfs、proc、selinuxfs、cgroup、sysfs、inotifyfs、vfat、debugfs、fuse，都是采用這一方式進行安全上下文的標記，在ocontexts文件中定義了這些文件系統相應的安全上下文內容。 

TE(Type Enforcement) 

TE強制訪問方式是SEAndroid中的最主要的安全手段，所有關於TE的強制訪問規則都被定義在了後綴为te的文件中，在te文件中基本能總結为完成如下操作： 
對type類型的定義和將type歸到相應的attribute中 
SEAndroid在te文件中定義了安全策略中最基本的参量type，同時將具有共性的type歸在一起構成一個稱为attribute的集合，policy的規則執行也能以attribute作为執行對象。 
SEAndroid为所有type共定義了17個attribute： 
dev_type: 
這一attribute包含了所有關於設備的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 
zygote 
fs_type: 
這一attribute包含了所有與文件系統相關的type。如下所列，大多是虛擬文件系統。 
device 
labeledfs 
pipefs 
sockfs 
rootfs 
proc 
selinuxfs 
cgroup 
sysfs 
sysfs_writable 
inotify 
devpts 
tmpfs 
shm 
mqueue 
sdcard 
debugfs 
file_type: 
這一attribute包含了所有存在於非偽文件系統的相關文件的type，數量過多不再列舉。 
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_exec 
data_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_file 
sysfs_type: 
這一attribute包含了在sysfs文件系統下的所有文件的type，在SEAndroid中只有sysfs_writable包含在這個attribute中。 
node_type: 
這一attribute包含了所有與nodes/hosts有關的type，在SEAndroid中只有node包含在這個attribute中。 
netif_type: 
這一attribute包含了所有與網络接口相關的type，在SEAndroid中只有netif包含在這個attribute中。 
port_type: 
這一attribute包含了所有與網络端口相關的type，在SEAndroid中只有port包含在這個attribute中。 
mlstrustedsubject: 
這一attribute包含了所有能越過MLS檢查的主體domain。 
mlstrustedobject: 
這一attribute包含了所有能越過MLS檢查的客體type。 
unconfineddomain: 
這一attribute包含了所有擁有無限權限的type。 
appdomain: 
這一attribute包含了所有與app相關的type，如下所列。 
trusted_app 
browser_app 
untrusted_app 
nfc 
radio 
shell 
system_app 
netdomain: 
這一attribute包含了所有與需要訪問網络的app相關的type，如下所列。 
trusted_app 
browser_app 
gpsd 
mediaserver 
radio 
rild 
system 
bluetoothdomain: 
這一attribute包含了所有與需要訪問bluetooth的app相關的type，如下所列。 
trusted_app 
radio 
system 
binderservicedomain: 
這一attribute包含了所有與binder服務相關的type，如下所列。 
mediaserver 
surfaceflinger 
system 

通過allow語句制定主體客體強制訪問規則（白名單規則，不再規則中的都默認为非法操作） 
通過type_transition語句制定tpye類型轉換規則 
通過dontaudit語句聲明對一些被安全策略拒絕的訪問不再進行審核。 
審核是對於發生了訪問違規或出現了被系統安全規則拒絕的行为進行日志記錄的過程，審核可以幫助系統管理員發現bug和可能的入侵嘗試。 
默認情況下，SEAndroid會記錄被拒絕的訪問檢查，但策略語言dontaudit允許我們取消這些默認的預料之中的拒絕審核消息。 

SEAndroid为系統定義了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個文件根據其策略規則針對的對象可分为三類： 
針對attribute的策略制定： 
attribute是多個具有共性的type的集合，以下六個文件主要是直接針對attribute制定的策略，這種針對attribute制定的策略也就是同時對多個type制定策略一样。 
unconfined.te 
主要是为unconfineddomain屬性制定策略，這些策略基本就是對各種訪問客體擁有所有的權限。 
domain.te 
主要是为domain屬性制定策略，为所有歸在其中的訪問主體制定一些公共的策略。 
CTS.te 
主要是为appdomain制定策略，這些策略一般是在對app進行CTS測試時用到。 
bluetooth.te 
主要是为bluetoothdomain制定策略。 
net.te 
主要是为netdomain制定策略，這些策略主要是關於對sockets、ports的訪問以及與netd的通信。 
file.te 
這個文件主要定義了各文件系統的type，各文件的type，socket的type，以及制定了在不同文件系統中創建文件的規則。 


針對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 
這些文件都是为系統中的daemon進程進行策略的制定，它們都有着相應的daemon domain。 

針對系統其他模塊的策略制定: 
最後的7個文件分別對系統的其他模塊進行策略制定。 
app.te 
在這一文件裏將安裝在系統上的第三方app分類为受信任的app和不受信任的app，分別用不同的type表示， 
再分別为這兩種app在訪問網络，bluetooth，sdcard，數據，緩存，binder等等名感位置時設置相應權限。
system.te 
這一文件主要針對的是系統app和system server進程。對系統app訪問binder、system data files、dalvikcatch、keystone等進行權限控制， 
對system server訪問網络、bluetooth、netlink、app、binder、device、data files、socket、cache files等進行權限控制。 
init.te 
在這一文件中聲明了init擁有無限權限。 
nfc.te 
在這一文件中制定了nfc domain對nfc設備和相關數據文件的訪問權限。 
kernel.te 
在這一文件中聲明了kernel擁有無限權限。 
radio.te 
在這一文件中制定了radio domain對init、rild和相關數據文件的訪問權限。 
device.te 
在這一文件中定義了所有跟設備相關的type，並將這些type都歸到了dev_type屬性中。 

接下來對SEAndroid中制定的各種繁多的策略做一個簡單分類： 
轉換(transition) 
domain transition 
某個程序被執行時，其相應的進程會處在相應的domain中，但當程序根據需要又執行了另一個程序時，進程就需要根據type transition規則進行domain transition以獲得必要的權限從而使新進程能順利訪問到相關文件。另一個transition的原因是原有的domain權限過大，为了不讓新启動的進程也繼承過大的權限，因此需要domain transition。 在SEAndroid中幾乎全部daemon進程都需要從init進程中启動，這就需要從init domian轉換到daemon domain這一操作。 
需要從init domain轉換到daemon domain的進程有bluetoothd、dbusd、debuggerd、drmserver、gpsd、installd、keystore、mediaserver、netd、qemud、rild、servicemanager、surfaceflinger、vold、wpa_supplicant、zygote。 
除了從init domain轉換到其他daemon domain外，還有從adbd domain轉換到shell domain，從shell domain轉換到su domain，以及從zygote domain轉換到system和appdomain，這主要是因为Android中的大部分進程都是由zygote創建。 
type transition 
type_transition 規則被用在Domain Transition中 或者確定新創建對象的標簽，以重載其默認的、從父目錄(containing directory)所繼承的標簽。通常情況下新創建文件的標簽和其父目錄的標簽一致,但是可以使用type_transition規則为其指定特定的標簽。 
例如在SEAndroid中gpsd domain在以gps_data_file为type的目錄下創建socket文件時，這些文件的type將會依照在策略中設定的type_transition規則而轉換为gps_sokcket。 
system domain在以wifi_data_file为type的目錄下創建socket文件時，文件的type將會依照type_transition規則轉變为system_wpa_socket。 

文件和目錄 
在許多主體訪問客體的情況中都需要對相關文件進行操作，SEAndroid對於牽涉到blk_file,chr_file,fd,fifo_file,lnk_file,sock_file和一般的file都進行了相關的策略制定。 
還制定了一些domain指定type的目錄、一般文件和鏈接文件只有讀的權限的策略，例如dbusd domain對system type和bluetoothd type的目錄和文件只有讀的權限,domain attribute對proc、sysfs、inotify、cgroup這些虛擬文件系統中的文件和目錄也只有讀的權限，另外還有mediaserver domain對sdcard type的目錄和文件只有讀的權限，shell domain對apk_data_file的目錄和文件只有讀的權限、system domain對mediaserver和appdomain的目錄和文件只有讀的權限。 
也制定了主體domain對不同文件系統的相關操作權限，以及當某個domain需要創建tmpfs、shmem、ashmem文件時，根據主體domain定義一個獨特的type並對新創建的文件進行標記的策略。在SEAndroid裏這條策略被用在了init、system、ueventd中。 
無限權限 
在SEAndroid中共定義了三個擁有巨大權限的attribute分別是mlstrustedsubject、mlstrustedobject、unconfineddomain，被分類到mlstrustedsubject的type在充當主體domain是可以越過MLS檢查，被分類到mlstrustedobject的type在充當客體時可以越過MLS檢查，被分到unconfineddomain的type則擁有所有權限可對客體進行任意操作。 
在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。 
設備 
關於設備這裏重點提一下bluetooth，在SEAndroid中只對三個type提供bluetooth訪問權限分別是trusted_app、radio、system。 
App 
在SEAndroid中指定了trusted_app、browser_app、untrusted_app、nfc、radio、shell、system_app這些type對系統中的所有app擁有适當的訪問權限，並能對ashmem objects使用獨特的type進行標記。 
網络 
SEAndroid對trusted_app、browser_app、gpsd、mediaserver、mediaserver、rild、system這些type授予了訪問網络的權限。 
在SEAndroid中系統對各類socket都制定了相應的策略，這些socket包括appletalk_socket(轉为apple公司產品通信而設)、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。 
adbd, vold, vold                     
adbd, property, init 
untrusted_app, dnsproxyd, netd 
bluetoothd, dbus, dbusd           
netdomain, dnsproxyd, netd 
radio, property, init               
radio, rild, rild 
rild, property, init 
rild, qemud, qemud                     
surfaceflinger, property, init 
system_app, keystore, keystore 
system, property, init 
system, qemud, qemud                  
system, installd, installd 
system, netd, netd               
system, vold, vold                 
system, zygote, zygote 
system, keystore, keystore 
system, dbus, dbusd               
system, gps, gpsd 
system, bluetooth, bluetoothd 
vold, property, init 

另外SEAndroid只允許system和wpa這兩個domain可以讓一個本地socket以system和wpa任何一方为客戶端另一方为服務端並通過某個socket進行數據包的發送。 運行一個本地socket從客戶端domain通過發送數據包到服務端domain。 
IPC 
SEAndroid只允許adbd、appdomain、drmserver、mediaserver、surfaceflinger、system這些type或attribute通過servicemanager使用binder IPC。 
SEAndroid只允許指定的客戶端domain對指定的服務端domain使用binder IPC，如以下所列，第一列是指定的客戶端domain，第二列是指定的服務端domain。 
adbd, surfaceflinger 
trusted_app, appdomain 
appdomain, binderservicedomain 
appdomain, trusted_app 
drmserver, system 
mediaserver, binderservicedomain 
mediaserver, appdomain 
surfaceflinger, system 
system_app, appdomain 
system, binderservicedomain 
system, appdomain 

SEAndroid只允許指定的客戶端domain傳送由服務端創建的binder references，如以下所列，第一列是指定的客戶端domain，第二列是指定的服務端domain。 
trusted_app, appdomain 
appdomain, binderservicedomain 
appdomain, trusted_app 
system_app, appdomain 
system, binderservicedomain 
system, appdomain 

MLS(Multi-Level Security) 

什麼是MLS，为何要引入MLS 
MLS稱为多級別安全是另一種強制訪問控制方法，特別适合於政府機密數據的訪問控制，早期對計算機安全的研究大多數都是以在操作系統內實現MLS訪問控制为驅動的。所有MLS的使用都是建立在TE安全的基礎之上。在SELinux中MLS是一個可選訪問控制方式，而在SEAndroid中則是被作为安全訪問方式的其中之一。 

MLS中的相關参量 
在SEAndroid中mls的相關参量就是安全上下文的第四列稱为security level，在安全上下文第四列中可以有一個或者兩個security level，第一個表示低安全級別，第二個表示高安全級別。 
每個security level由兩個字段組成： 
sensitivity 
sensitivity有着嚴格的分級，它反應了一個有序的數據靈敏度模型，如政府分類控制中的絕密，機密和無密級。 
category 
category是無序的，它反應的是數據劃分的需要。 

基本思路是對於要訪問的數據你同時需要足夠的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對進程的約束 
限制進程的domain轉換 
對於從一個domain轉換到另一個domain的操作要求兩個domain的高級別security level和低級別security level同時相等才能許可轉換，除非是待轉換的domain屬於對mls無限權限的type。 
限制進程讀操作 
只有當主體domain的低級別security level對客體domain的低級別security level具有dom關系時，或者主體domian是屬於對mls無限權限的type，主體才能對客體具有讀操作的許可。 
這一讀操作具體是指： 
能獲取進程優先權 
能獲取另一進程的session id 
能獲取到進程的group id 
能獲取到系統的capabilities 
能獲取文件的屬性信息 
能追蹤父程序或子程序的執行 
允許通過clone或fork進程實現狀態信息共享 
總結一下就是MLS限制了低級別進程向高級別進程進行讀的操作，即不能上讀。 
限制進程寫操作 
只有當主體domain的低級別security level對客體domain的低級別security level具有domby關系時，或者主體domain是屬於對mls無限權限的type，主體才能對客體具有寫操作的許可。 
寫操作具體是指： 
能發送SIGKILL信號 
能發送SIGSTOP信號 
能發送一個非SIGKILL、SIGSTOP、SIGCHLD的信號 
能設置進程優先級 
能設置進程group id 
能設置系統的capabilities 
能改變進程hard limits 
能追蹤父程序或子程序的執行 
允許通過clone或fork進程實現狀態信息共享 
總結一下就是MLS限制了高級別進程對低級別進程寫的操作，即不能下寫。 
MLS對socket的約束 
進程對local socket的訪問限制 
只有當主體進程的domain的高級別security level和低級別security level分別與客體local socket的type的security level相同時即滿足eq關系時，或者主體客體任何一個具有對mls無限權限的type時，主體進程才對local socket擁有了某些訪問權限。 
這些訪問權限是指： 
讀操作 
寫操作 
新建操作 
能獲取對象屬性信息 
能設置對象的屬性信息 
能對對象重新標記安全上下文 
能進行bind操作 
能發起一個連接請求 
能監聽連接事件 
能接受一個連接請求 
能獲取到socket options 
能關閉socket連接 
對socket的datagram發送的限制 
只有當發送方的低級別security level與接受方的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權限的type時，發送方才對接受方擁有了發送權限。 
對客戶端socket和服務端socket建立連接的限制 
只有當客戶端的低級別security level與服務端的低級別security level滿足eq關系時，或者主體客體任何一個具有對mls無限權限的type時，客戶端就能獲得連接服務端的權限。 
MLS對文件和目錄的約束 
對文件的創建和重新標記的限制 
對文件操作時，要求客體的文件安全上下文只有一個security level即沒有低級別和高級別security level或者說是這兩個級別相同。 當主體domain的低級別security level對客體文件的低級別security level相同時，或者主體具有對mls有無限權限的type時，主體對客體文件擁有創建、和重新標記安全上下文的權限。 
對目錄的讀操作的限制 
只有當主體的低級別security level對客體目錄的低級別security level滿足dom關系時，或者主體客體任何一個具有對mls無限權限的type時，主體能對目錄擁有如下權限： 
能讀目錄 
能獲得目錄的屬性信息 
能獲得某個正在被訪問文件的所有上層目錄訪問權（search權限） 
總結一下就是對目錄的訪問不能上讀。 
對文件的讀操作的限制 
只有當主體的低級別security level對客體文件的低級別security level滿足dom關系時，或者主體客體任何一個具有對mls無限權限的type時，主體能對文件擁有如下權限： 
能讀文件 
能獲得文件的屬性信息 
能執行該文件 
總結一下就是對文件的訪問不能上讀。 
對目錄的寫操作的限制 
只有當主體的低級別security level對客體目錄的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權限的type時，主體能對目錄擁有如下權限： 
能對目錄寫操作 
能設置屬性信息 
能重命名目錄 
能添加一個文件到目錄中 
能從目錄中刪除一個文件 
能改變父目錄 
能刪除一個空目錄 
總結一下就是對目錄訪問不能下寫。 
對文件的寫操作的限制 
只有當主體的低級別security level對客體文件的低級別security level滿足domby關系時，或者主體客體任何一個具有對mls無限權限的type時，主體能對文件擁有如下權限： 
能對文件進行寫操作 
能設置文件屬性信息 
能對文件內容作append操作 
能對文件創建鏈接 
能刪除一個文件的鏈接 
能對文件重命名 
總結一下就是對文件訪問不能下寫。 
MLS對IPC的約束 
對IPC創建和銷毀的限制 
要求客體的IPC對象只有一個security level。 
只有當主體的低級別security level與客體的低級別security level滿足eq關系時，或者主體具有對mls無限權限的type時，主體能對客體IPC擁有創建和銷毀的權限。 
對IPC讀操作的限制 
只有當主體的低級別security level對客體IPC的低級別security level滿足dom關系時，或者主體具有對mls無限權限的type時，主體能對客體IPC擁有如下權限： 
獲取文件屬性信息 
能對IPC文件執行讀操作 
能關聯一個key 
能執行由IPC操作要求的讀操作 
總結一下就是對IPC訪問不能上讀。 
對IPC寫操作的限制 
只有當主體的低級別security level對客體IPC的低級別security level滿足domby關系時，或者主體具有對mls無限權限的type時，主體能對客體IPC擁有如下權限： 
能對文件執行write和append操作 
能執行由IPC操作要求的write和append操作 
總結一下就是對IPC訪問不能下寫。