㈠ 主要有哪幾種訪問控制策略
三種不同的訪問控制策略：自主訪問控制（DAC）、強制訪問控制（MAC）和基於角色的訪問控制（RBAC），前兩種屬於傳統的訪問控制策略，而RBAC是90年代後期出現的，有很大的優勢，所以發展很快。
每種策略並非是絕對互斥的，我們可以把幾種策略綜合起來應用從而獲得更好、更安全的系統保護——多重的訪問控制策略。
㈡ 安卓系統的自主訪問控制和強制訪問控制是怎麼操作的
自主訪問控制
自主訪問的含義是有訪問許可的主體能夠直接或間接地向其他主體轉讓訪問權。自主訪問控制是在確認主體身份以及（或）它們所屬的組的基礎上，控制主體的活動，實施用戶許可權管理、訪問屬性（讀、寫、執行）管理等，是一種最為普遍的訪問控制手段。自主訪問控制的主體可以按自己的意願決定哪些用戶可以訪問他們的資源，亦即主體有自主的決定權，一個主體可以有選擇地與其它主體共享他的資源。
基於訪問控制矩陣的訪問控製表（ACL）是DAC中通常採用一種的安全機制。ACL是帶有訪問許可權的矩陣，這些訪問權是授予主體訪問某一客體的。安全管理員通過維護ACL控制用戶訪問企業數據。對每一個受保護的資源，ACL對應一個個人用戶列表或由個人用戶構成的組列表，表中規定了相應的訪問模式。當用戶數量多、管理數據量大時，由於訪問控制的粒度是單個用
戶，ACL會很龐大。當組織內的人員發生能變化（升遷、換崗、招聘、離職）、工作職能發生變化（新增業務）時，ACL的修改變得異常困難。採用ACL機制管理授權處於一個較低級的層次，管理復雜、代價高以至易於出錯。
DAC的主要特徵體現在主體可以自主地把自己所擁有客體的訪問許可權授予其它主體或者從其它主體收回所授予的許可權，訪問通常基於訪問控製表（ACL）。訪問控制的粒度是單個用戶。沒有存取權的用戶只允許由授權用戶指定對客體的訪問權。DAC的缺點是信息在移動過程中其訪問許可權關系會被改變。如用戶A可將其對目標O的訪問許可權傳遞給用戶B，從而使不具備對O訪問許可權的B可訪問O。
強制訪問控制
為了實現完備的自主訪問控制系統，由訪問控制矩陣提供的信息必須以某種形式存放在系統中。訪問矩陣中的每行表示一個主體，每一列則表示一個受保護的客體，而矩陣中的元素，則表示主體可以對客體的訪問模式。目前，在系統中訪問控制矩陣本身，都不是完整地存儲起來，因為矩陣中的許多元素常常為空。空元素將會造成存儲空間的浪費，而且查找某個元素會耗費很多時間。實際上常常是基於矩陣的行或列來表達訪問控制信息。
強制訪問控制是「強加」給訪問主體的，即系統強制主體服從訪問控制政策。強制訪問控制（MAC）的主要特徵是對所有主體及其所控制的客體（例如：進程、文件、段、設備）實施強制訪問控制。
為這些主體及客體指定敏感標記，這些標記是等級分類和非等級類別的組合，它們是實施強制訪問控制的依據。系統通過比較主體和客體的敏感標記來決定一個主體是否能夠訪問某個客體。用戶的程序不能改變他自己及任何其它客體的敏感標記，從而系統可以防止特洛伊木馬的攻擊。
Top Secret），秘密級（Secret），機密級（Confidential）及無級別級（Unclassified）。其級別為T>S>C>U，系統根據主體和客體的敏感標記來決定訪問模式。訪問模式包括：
read down）：用戶級別大於文件級別的讀操作；
Write up）：用戶級別小於文件級別的寫操作；
Write down）：用戶級別等於文件級別的寫操作；
read up）：用戶級別小於文件級別的讀操作；
自主訪問控制不能抵禦「特洛伊木馬」攻擊，而強制訪問控制能夠有效的防禦「特洛伊木馬」攻擊。MAC最主要的優勢是它阻止特洛伊木馬的能力 一個特洛伊木馬是在一個執行某些合法功能的程序中隱藏的代碼，它利用運行此程序的主體的許可權違反安全策略 通過偽裝成有用的程序在進程中泄露信息 一個特洛伊木馬能夠以兩種方式泄露信息： 直接與非直接泄露 前者， 特洛伊木馬以這樣一種方式工作， 使信息的安全標示不正確並泄露給非授權用戶； 後者特洛伊木馬通過以下方式非直接地泄露信息： 在返回給一個主體的合法信息中編制 例如： 可能表面上某些提問需要回答， 而實際上用戶回答的內容被傳送給特洛伊木馬。
㈢ 訪問控制技術的類型機制
訪問控制可以分為兩個層次：物理訪問控制和邏輯訪問控制。物理訪問控制如符合標准規定的用戶、設備、門、鎖和安全環境等方面的要求，而邏輯訪問控制則是在數據、應用、系統、網路和許可權等層面進行實現的。對銀行、證券等重要金融機構的網站，信息安全重點關注的是二者兼顧，物理訪問控制則主要由其他類型的安全部門負責。 主要的訪問控制類型有3種模式：自主訪問控制（DAC）、強制訪問控制（MAC）和基於角色訪問控制（RBAC）。
1）自主訪問控制
自主訪問控制（Discretionary Access Control，DAC）是一種接入控制服務，通過執行基於系統實體身份及其到系統資源的接入授權。包括在文件，文件夾和共享資源中設置許可。用戶有權對自身所創建的文件、數據表等訪問對象進行訪問，並可將其訪問權授予其他用戶或收回其訪問許可權。允許訪問對象的屬主制定針對該對象訪問的控制策略，通常，可通過訪問控制列表來限定針對客體可執行的操作。
①每個客體有一個所有者，可按照各自意願將客體訪問控制許可權授予其他主體。
②各客體都擁有一個限定主體對其訪問許可權的訪問控制列表（ACL）。
③每次訪問時都以基於訪問控制列表檢查用戶標志，實現對其訪問許可權控制。
④DAC的有效性依賴於資源的所有者對安全政策的正確理解和有效落實。
DAC提供了適合多種系統環境的靈活方便的數據訪問方式，是應用最廣泛的訪問控制策略。然而，它所提供的安全性可被非法用戶繞過，授權用戶在獲得訪問某資源的許可權後，可能傳送給其他用戶。主要是在自由訪問策略中，用戶獲得文件訪問後，若不限制對該文件信息的操作，即沒有限制數據信息的分發。所以DAC提供的安全性相對較低，無法對系統資源提供嚴格保護。
2）強制訪問控制
強制訪問控制（MAC）是系統強制主體服從訪問控制策略。是由系統對用戶所創建的對象，按照規定的規則控制用戶許可權及操作對象的訪問。主要特徵是對所有主體及其所控制的進程、文件、段、設備等客體實施強制訪問控制。在MAC中，每個用戶及文件都被賦予一定的安全級別，只有系統管理員才可確定用戶和組的訪問許可權，用戶不能改變自身或任何客體的安全級別。系統通過比較用戶和訪問文件的安全級別，決定用戶是否可以訪問該文件。此外，MAC不允許通過進程生成共享文件，以通過共享文件將信息在進程中傳遞。MAC可通過使用敏感標簽對所有用戶和資源強制執行安全策略，一般採用3種方法：限制訪問控制、過程式控制制和系統限制。MAC常用於多級安全軍事系統，對專用或簡單系統較有效，但對通用或大型系統並不太有效。
MAC的安全級別有多種定義方式，常用的分為4級：絕密級（Top Secret）、秘密級（Secret）、機密級（Confidential）和無級別級（Unclas sified），其中T>S>C>U。所有系統中的主體（用戶，進程）和客體（文件，數據）都分配安全標簽，以標識安全等級。
通常MAC與DAC結合使用，並實施一些附加的、更強的訪問限制。一個主體只有通過自主與強制性訪問限制檢查後，才能訪問其客體。用戶可利用DAC來防範其他用戶對自己客體的攻擊，由於用戶不能直接改變強制訪問控制屬性，所以強制訪問控制提供了一個不可逾越的、更強的安全保護層，以防範偶然或故意地濫用DAC。
3）基於角色的訪問控制
角色（Role）是一定數量的許可權的集合。指完成一項任務必須訪問的資源及相應操作許可權的集合。角色作為一個用戶與許可權的代理層，表示為許可權和用戶的關系，所有的授權應該給予角色而不是直接給用戶或用戶組。
基於角色的訪問控制（Role-Based Access Control，RBAC）是通過對角色的訪問所進行的控制。使許可權與角色相關聯，用戶通過成為適當角色的成員而得到其角色的許可權。可極大地簡化許可權管理。為了完成某項工作創建角色，用戶可依其責任和資格分派相應的角色，角色可依新需求和系統合並賦予新許可權，而許可權也可根據需要從某角色中收回。減小了授權管理的復雜性，降低管理開銷，提高企業安全策略的靈活性。
RBAC模型的授權管理方法，主要有3種：
①根據任務需要定義具體不同的角色。
②為不同角色分配資源和操作許可權。
③給一個用戶組（Group，許可權分配的單位與載體）指定一個角色。
RBAC支持三個著名的安全原則：最小許可權原則、責任分離原則和數據抽象原則。前者可將其角色配置成完成任務所需要的最小許可權集。第二個原則可通過調用相互獨立互斥的角色共同完成特殊任務，如核對賬目等。後者可通過許可權的抽象控制一些操作，如財務操作可用借款、存款等抽象許可權，而不用操作系統提供的典型的讀、寫和執行許可權。這些原則需要通過RBAC各部件的具體配置才可實現。 訪問控制機制是檢測和防止系統未授權訪問，並對保護資源所採取的各種措施。是在文件系統中廣泛應用的安全防護方法，一般在操作系統的控制下，按照事先確定的規則決定是否允許主體訪問客體，貫穿於系統全過程。
訪問控制矩陣（Access Contro1 Matrix）是最初實現訪問控制機制的概念模型，以二維矩陣規定主體和客體間的訪問許可權。其行表示主體的訪問許可權屬性，列表示客體的訪問許可權屬性，矩陣格表示所在行的主體對所在列的客體的訪問授權，空格為未授權，Y為有操作授權。以確保系統操作按此矩陣授權進行訪問。通過引用監控器協調客體對主體訪問，實現認證與訪問控制的分離。在實際應用中，對於較大系統，由於訪問控制矩陣將變得非常大，其中許多空格，造成較大的存儲空間浪費，因此，較少利用矩陣方式，主要採用以下2種方法。
1）訪問控制列表
訪問控制列表（Access Control List，ACL）是應用在路由器介面的指令列表，用於路由器利用源地址、目的地址、埠號等的特定指示條件對數據包的抉擇。是以文件為中心建立訪問許可權表，表中記載了該文件的訪問用戶名和權隸屬關系。利用ACL，容易判斷出對特定客體的授權訪問，可訪問的主體和訪問許可權等。當將該客體的ACL置為空，可撤消特定客體的授權訪問。
基於ACL的訪問控制策略簡單實用。在查詢特定主體訪問客體時，雖然需要遍歷查詢所有客體的ACL，耗費較多資源，但仍是一種成熟且有效的訪問控制方法。許多通用的操作系統都使用ACL來提供該項服務。如Unix和VMS系統利用ACL的簡略方式，以少量工作組的形式，而不許單個個體出現，可極大地縮減列表大小，增加系統效率。
2）能力關系表
能力關系表（Capabilities List）是以用戶為中心建立訪問許可權表。與ACL相反，表中規定了該用戶可訪問的文件名及許可權，利用此表可方便地查詢一個主體的所有授權。相反，檢索具有授權訪問特定客體的所有主體，則需查遍所有主體的能力關系表。 通過介紹單點登入SSO的基本概念和優勢，主要優點是，可集中存儲用戶身份信息，用戶只需一次向伺服器驗證身份，即可使用多個系統的資源，無需再向各客戶機驗證身份，可提高網路用戶的效率，減少網路操作的成本，增強網路安全性。根據登入的應用類型不同，可將SSO分為3種類型。
1）對桌面資源的統一訪問管理
對桌面資源的訪問管理，包括兩個方面：
①登入Windows後統一訪問Microsoft應用資源。Windows本身就是一個「SSO」系統。隨著.NET技術的發展，「Microsoft SSO」將成為現實。通過Active Directory的用戶組策略並結合SMS工具，可實現桌面策略的統一制定和統一管理。
②登入Windows後訪問其他應用資源。根據Microsoft的軟體策略，Windows並不主動提供與其他系統的直接連接。現在，已經有第三方產品提供上述功能，利用Active Directory存儲其他應用的用戶信息，間接實現對這些應用的SSO服務。
2）Web單點登入
由於Web技術體系架構便捷，對Web資源的統一訪問管理易於實現。在目前的訪問管理產品中，Web訪問管理產品最為成熟。Web訪問管理系統一般與企業信息門戶結合使用，提供完整的Web SSO解決方案。
3）傳統C/S 結構應用的統一訪問管理
在傳統C/S 結構應用上，實現管理前台的統一或統一入口是關鍵。採用Web客戶端作為前台是企業最為常見的一種解決方案。
在後台集成方面，可以利用基於集成平台的安全服務組件或不基於集成平台的安全服務API，通過調用信息安全基礎設施提供的訪問管理服務，實現統一訪問管理。
在不同的應用系統之間，同時傳遞身份認證和授權信息是傳統C/S結構的統一訪問管理系統面臨的另一項任務。採用集成平台進行認證和授權信息的傳遞是當前發展的一種趨勢。可對C/S結構應用的統一訪問管理結合信息匯流排（EAI）平台建設一同進行。
㈣ 什麼是淘寶自主訪問！
自主訪問是指用戶可以按照自己的意願，通過在瀏覽器輸入網址或者通過淘寶收藏夾的鏈接，或者通過其他推廣方式的鏈接直接對淘寶某店鋪進行訪問，也就是我們通過鏈接進入店鋪或者商品，而不是通過搜索進入。
淘寶的自主訪問是淘寶店鋪的一種流量來源，用戶通過淘寶網內搜索、收藏夾點擊、購物車點擊、微淘點擊等方式進入淘寶店鋪。
(4)自主訪問控制的兩種訪問模式擴展閱讀：
淘寶自主訪問的幾個方式：
1、店鋪收藏：訪客通過於收藏夾的店鋪收藏進入店鋪。
2、寶貝收藏：訪客通過收藏的寶貝進入店鋪。
3、我的淘寶首頁：訪客從我的淘寶首頁點擊進入店鋪。
3、已買到商品：訪客從已買到的寶貝頁面點擊後進入你的店鋪。
4、直接訪問：訪客通過輸入店鋪地址或者通過瀏覽器收藏夾等直接進入你的店鋪。
5、購物車：訪客通過購物車進入你的店鋪。
自主訪問大多數都是為老客戶或者有下單意願的客戶
㈤ 自主訪問控制與強制訪問控制的區別
一、類型不同
1、自主訪問控制：由《可信計算機系統評估准則》所定義的訪問控制中的一種類型。
2、強制訪問控制：在計算機安全領域指一種由操作系統約束的訪問控制。
二、目的不同
1、自主訪問控制：根據主體（如用戶、進程或 I/O 設備等）的身份和他所屬的組限制對客體的訪問。
2、強制訪問控制：目標是限制主體或發起者訪問或對對象或目標執行某種操作的能力。
三、特點不同
1、自主訪問控制：由客體的屬主對自己的客體進行管理，由屬主自己決定是否將自己的客體訪問權或部分訪問權授予其他主體，這種控制方式是自主的。
2、強制訪問控制：每當主體嘗試訪問對象時，都會由操作系統內核強制施行授權規則——檢查安全屬性並決定是否可進行訪問。任何主體對任何對象的任何操作都將根據一組授權規則（也稱策略）進行測試，決定操作是否允許。
㈥ 訪問控制技術的主要類型有哪三種
訪問控制技術主要有3種類型：自主訪問控制、強制訪問控制和基於角色訪問控制。自主訪問控制：用戶通過授權或者回收給其他用戶訪問特定資源的許可權，主要是針對其訪問權進行控制。
強制訪問控制：由系統己經部署的訪問控制策略，按照系統的規定用戶需要服從系統訪問控制策略，比如系統管理員制定訪問策略，其他用戶只能按照規定進行進程、文件和設備等訪問控制。
(6)自主訪問控制的兩種訪問模式擴展閱讀
訪問控制的主要功能包括：保證合法用戶訪問受權保護的網路資源，防止非法的主體進入受保護的網路資源，或防止合法用戶對受保護的網路資源進行非授權的訪問。
訪問控制首先需要對用戶身份的合法性進行驗證，同時利用控制策略進行選用和管理工作。當用戶身份和訪問許可權驗證之後，還需要對越權操作進行監控。因此，訪問控制的內容包括認證、控制策略實現和安全審計。
㈦ 自主訪問控制（DAC）與強制訪問控制（MAC）的原理是什麼，區別在哪裡各有什麼優缺點
雙系統或多系統有什麼優缺點，求祥解。XjU9es
㈧ 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 問題快速分析》的內容，感謝原作者們的辛勤付出。另外，結合源碼和自身開發實踐，增加了一些自身理解和實踐內容。
㈨ 訪問控制的基本原理和常見模型
訪問控制的功能及原理：
訪問控制的主要功能包括：保證合法用戶訪問受權保護的網路資源，防止非法的主體進入受保護的網路資源，或防止合法用戶對受保護的網路資源進行非授權的訪問。訪問控制首先需要對用戶身份的合法性進行驗證，同時利用控制策略進行選用和管理工作。當用戶身份和訪問許可權驗證之後，還需要對越權操作進行監控。因此，訪問控制的內容包括認證、控制策略實現和安全審計。
1、認證。包括主體對客體的識別及客體對主體的檢驗確認；
2、控制策略。通過合理地設定控制規則集合，確保用戶對信息資源在授權范圍內的合法使用。既要確保授權用戶的合理使用，又要防止非法用戶侵權進入系統，使重要信息資源泄露。同時對合法用戶，也不能越權行使許可權以外的功能及訪問范圍；
3、安全審計。系統可以自動根據用戶的訪問許可權，對計算機網路環境下的有關活動或行為進行系統的、獨立的檢查驗證，並做出相應評價與審計。
訪問控制的模型：
主要的訪問控制類型有3種模型：自主訪問控制（DAC）、強制訪問控制（MAC）和基於角色訪問控制（RBAC）。
1、自主訪問控制
自主訪問控制（Discretionary Access Control，DAC）是一種接入控制服務，通過執行基於系統實體身份及其到系統資源的接入授權。包括在文件，文件夾和共享資源中設置許可。用戶有權對自身所創建的文件、數據表等訪問對象進行訪問，並可將其訪問權授予其他用戶或收回其訪問許可權。允許訪問對象的屬主制定針對該對象訪問的控制策略，通常，可通過訪問控制列表來限定針對客體可執行的操作。
2、強制訪問控制
強制訪問控制（MAC）是系統強制主體服從訪問控制策略。是由系統對用戶所創建的對象，按照規定的規則控制用戶許可權及操作對象的訪問。主要特徵是對所有主體及其所控制的進程、文件、段、設備等客體實施強制訪問控制。
3、基於角色的訪問控制
角色（Role）是一定數量的許可權的集合。指完成一項任務必須訪問的資源及相應操作許可權的集合。角色作為一個用戶與許可權的代理層，表示為許可權和用戶的關系，所有的授權應該給予角色而不是直接給用戶或用戶組。
㈩ 訪問控制的訪問控制的類型
訪問控制可分為自主訪問控制和強制訪問控制兩大類。
自主訪問控制，是指由用戶有權對自身所創建的訪問對象（文件、數據表等）進行訪問，並可將對這些對象的訪問權授予其他用戶和從授予許可權的用戶收回其訪問許可權。
強制訪問控制，是指由系統（通過專門設置的系統安全員）對用戶所創建的對象進行統一的強制性控制，按照規定的規則決定哪些用戶可以對哪些對象進行什麼樣操作系統類型的訪問，即使是創建者用戶，在創建一個對象後，也可能無權訪問該對象。 基於對象的訪問控制（OBAC Model：Object-based Access Control Model）：DAC或MAC模型的主要任務都是對系統中的訪問主體和受控對象進行一維的許可權管理。當用戶數量多、處理的信息數據量巨大時，用戶許可權的管理任務將變得十分繁重且難以維護，這就降低了系統的安全性和可靠性。
對於海量的數據和差異較大的數據類型，需要用專門的系統和專門的人員加以處理，要是採用RBAC模型的話，安全管理員除了維護用戶和角色的關聯關系外，還需要將龐大的信息資源訪問許可權賦予有限個角色。
當信息資源的種類增加或減少時，安全管理員必須更新所有角色的訪問許可權設置，如果受控對象的屬性發生變化，和需要將受控對象不同屬性的數據分配給不同的訪問主體處理時，安全管理員將不得不增加新的角色，並且還必須更新原來所有角色的訪問許可權設置以及訪問主體的角色分配設置。
這樣的訪問控制需求變化往往是不可預知的，造成訪問控制管理的難度和工作量巨大。所以在這種情況下，有必要引入基於受控對象的訪問控制模型。
控制策略和控制規則是OBAC訪問控制系統的核心所在，在基於受控對象的訪問控制模型中，將訪問控制列表與受控對象或受控對象的屬性相關聯，並將訪問控制選項設計成為用戶、組或角色及其對應許可權的集合；同時允許對策略和規則進行重用、繼承和派生操作。
這樣，不僅可以對受控對象本身進行訪問控制，受控對象的屬性也可以進行訪問控制，而且派生對象可以繼承父對象的訪問控制設置，這對於信息量巨大、信息內容更新變化頻繁的管理信息系統非常有益，可以減輕由於信息資源的派生、演化和重組等帶來的分配、設定角色許可權等的工作量。
OBAC訪問控制系統是從信息系統的數據差異變化和用戶需求出發，有效地解決了信息數據量大、數據種類繁多、數據更新變化頻繁的大型管理信息系統的安全管理。並從受控對象的角度出發，將訪問主體的訪問許可權直接與受控對象相關聯，一方面定義對象的訪問控制列表，增、刪、修改訪問控制項易於操作，另一方面，當受控對象的屬性發生改變，或者受控對象發生繼承和派生行為時，無須更新訪問主體的許可權，只需要修改受控對象的相應訪問控制項即可，從而減少了訪問主體的許可權管理，降低了授權數據管理的復雜性。 基於任務的訪問控制模型（TBAC Model，Task-based Access Control Model）是從應用和企業層角度來解決安全問題，以面向任務的觀點，從任務（活動）的角度來建立安全模型和實現安全機制，在任務處理的過程中提供動態實時的安全管理。
在TBAC中，對象的訪問許可權控制並不是靜止不變的，而是隨著執行任務的上下文環境發生變化。TBAC首要考慮的是在工作流的環境中對信息的保護問題：在工作流環境中，數據的處理與上一次的處理相關聯，相應的訪問控制也如此，因而TBAC是一種上下文相關的訪問控制模型。其次，TBAC不僅能對不同工作流實行不同的訪問控制策略，而且還能對同一工作流的不同任務實例實行不同的訪問控制策略。從這個意義上說，TBAC是基於任務的，這也表明，TBAC是一種基於實例（instance-based）的訪問控制模型。
TBAC模型由工作流、授權結構體、受託人集、許可集四部分組成。
任務（task）是工作流程中的一個邏輯單元，是一個可區分的動作，與多個用戶相關，也可能包括幾個子任務。授權結構體是任務在計算機中進行控制的一個實例。任務中的子任務，對應於授權結構體中的授權步。
授權結構體（authorization unit）：是由一個或多個授權步組成的結構體，它們在邏輯上是聯系在一起的。授權結構體分為一般授權結構體和原子授權結構體。一般授權結構體內的授權步依次執行，原子授權結構體內部的每個授權步緊密聯系，其中任何一個授權步失敗都會導致整個結構體的失敗。
授權步（authorization step）表示一個原始授權處理步，是指在一個工作流程中對處理對象的一次處理過程。授權步是訪問控制所能控制的最小單元，由受託人集（trustee-set）和多個許可集（permissions set）組成。
受託人集是可被授予執行授權步的用戶的集合，許可集則是受託集的成員被授予授權步時擁有的訪問許可。當授權步初始化以後，一個來自受託人集中的成員將被授予授權步，我們稱這個受託人為授權步的執行委託者，該受託人執行授權步過程中所需許可的集合稱為執行者許可集。授權步之間或授權結構體之間的相互關系稱為依賴（dependency），依賴反映了基於任務的訪問控制的原則。授權步的狀態變化一般自我管理，依據執行的條件而自動變遷狀態，但有時也可以由管理員進行調配。
一個工作流的業務流程由多個任務構成。而一個任務對應於一個授權結構體，每個授權結構體由特定的授權步組成。授權結構體之間以及授權步之間通過依賴關系聯系在一起。在TBAC中，一個授權步的處理可以決定後續授權步對處理對象的操作許可，上述許可集合稱為激活許可集。執行者許可集和激活許可集一起稱為授權步的保護態。
TBAC模型一般用五元組（S，O，P，L，AS）來表示，其中S表示主體，O表示客體，P表示許可，L表示生命期（lifecycle），AS表示授權步。由於任務都是有時效性的，所以在基於任務的訪問控制中，用戶對於授予他的許可權的使用也是有時效性的。
因此，若P是授權步AS所激活的許可權，那麼L則是授權步AS的存活期限。在授權步AS被激活之前，它的保護態是無效的，其中包含的許可不可使用。當授權步AS被觸發時，它的委託執行者開始擁有執行者許可集中的許可權，同時它的生命期開始倒記時。在生命期期間，五元組（S，O，P，L，AS）有效。生命期終止時，五元組（S，O，P，L，AS）無效，委託執行者所擁有的許可權被回收。
TBAC的訪問政策及其內部組件關系一般由系統管理員直接配置。通過授權步的動態許可權管理，TBAC支持最小特權原則和最小泄漏原則，在執行任務時只給用戶分配所需的許可權，未執行任務或任務終止後用戶不再擁有所分配的許可權；而且在執行任務過程中，當某一許可權不再使用時，授權步自動將該許可權回收；另外，對於敏感的任務需要不同的用戶執行，這可通過授權步之間的分權依賴實現。
TBAC從工作流中的任務角度建模，可以依據任務和任務狀態的不同，對許可權進行動態管理。因此，TBAC非常適合分布式計算和多點訪問控制的信息處理控制以及在工作流、分布式處理和事務管理系統中的決策制定。 基於角色的訪問控制模型（RBAC Model，Role-based Access Model）：RBAC模型的基本思想是將訪問許可權分配給一定的角色，用戶通過飾演不同的角色獲得角色所擁有的訪問許可權。這是因為在很多實際應用中，用戶並不是可以訪問的客體信息資源的所有者（這些信息屬於企業或公司），這樣的話，訪問控制應該基於員工的職務而不是基於員工在哪個組或是誰信息的所有者，即訪問控制是由各個用戶在部門中所擔任的角色來確定的，例如，一個學校可以有教工、老師、學生和其他管理人員等角色。
RBAC從控制主體的角度出發，根據管理中相對穩定的職權和責任來劃分角色，將訪問許可權與角色相聯系，這點與傳統的MAC和DAC將許可權直接授予用戶的方式不同；通過給用戶分配合適的角色，讓用戶與訪問許可權相聯系。角色成為訪問控制中訪問主體和受控對象之間的一座橋梁。
角色可以看作是一組操作的集合，不同的角色具有不同的操作集，這些操作集由系統管理員分配給角色。在下面的實例中，我們假設Tch1，Tch2，Tch3……Tchi是對應的教師，Stud1，Stud 2，Stud3 …Studj是相應的學生，Mng1，Mng 2，Mng 3…Mngk是教務處管理人員，那麼老師的許可權為TchMN={查詢成績、上傳所教課程的成績}；學生的許可權為Stud MN={查詢成績、反映意見}；教務管理人員的許可權為MngMN={查詢、修改成績、列印成績清單}。
那麼，依據角色的不同，每個主體只能執行自己所制定的訪問功能。用戶在一定的部門中具有一定的角色，其所執行的操作與其所扮演的角色的職能相匹配，這正是基於角色的訪問控制（RBAC）的根本特徵，即：依據RBAC策略，系統定義了各種角色，每種角色可以完成一定的職能，不同的用戶根據其職能和責任被賦予相應的角色，一旦某個用戶成為某角色的成員，則此用戶可以完成該角色所具有的職能。
如今數據安全成疾，蠕蟲和病毒橫行，如何提高網路安全？選擇網路訪問控制（NAC）成為必然，它能夠幫助企業網路免於多種網路安全威脅。
許多企業往往不願意實施基於角色的訪問控制。因為企業擔心冗長而復雜的實施過程，並且由於雇員訪問權要發生變化，也會對工作效率帶來副作用。完成基於角色的矩陣可能是一個需要花費企業幾年時間的復雜過程。有一些新方法可以縮短這個過程，並當即帶來好處。企業可以採用人力資源系統作為數據源，收集所有雇員的部門、職位、位置以及企業的層次結構等信息，並將這些信息用於創建每個訪問級別的角色。下一步就是從活動目錄等位置獲得當前的權利，以及與不同角色的雇員有關的數據共享。下一步，使數據標准化，確保相同角色的雇員擁有相同的訪問權。可以通過從人力資源和活動目錄、修正報告以及雇員的管理者那裡收集數據，用於檢查和糾正。基於角色的訪問控制應用與身份管理系統結合使用，可以實施管理員在自動模式中做出的變化。此過程可以在包含敏感信息的企業網路的其它應用中多次反復實施，確保訪問權的正確性。