androiddac

① 索尼1adac怎麼連接安卓手機

1ADAC隨機附送四根連接線，其中有有安卓介面的usb連接線，用它連接手機和1ADAC即可。

② 安卓文件訪問控制的安全服務位於哪一層

SElinux(Security-Enhanced Linux) 是美國國家安全局(NSA)對於強制訪問控制的實現，是 Linux歷史上最傑出的新安全子系統。NSA是在Linux社區的幫助下開發了一種訪問控制體系，在這種訪問控制體系的限制下，進程只能訪問那些在他的任務中所需要文件。SELinux 默認安裝在 Fedora 和 Red Hat Enterprise Linux 上，也可以作為其他發行版上容易安裝的包得到。 SELinux 是 2.6 版本的 Linux 內核中提供的強制訪問控制(MAC)系統。對於目前可用的 Linux安全模塊來說，SELinux 是功能最全面，而且測試最充分的，它是在 20 年的 MAC 研究基礎上建立的。SELinux 在類型強制伺服器中合並了多級安全性或一種可選的多類策略，並採用了基於角色的訪問控制概念。[1] 大部分使用 SELinux 的人使用的都是 SELinux 就緒的發行版，例如 Fedora、Red Hat Enterprise Linux (RHEL)、Debian或 Centos。它們都是在內核中啟用 SELinux 的，並且提供一個可定製的安全策略，還提供很多用戶層的庫和工具，它們都可以使用 SELinux 的功能。 SELinux是一種基於 域-類型 模型(domain-type)的強制訪問控制(MAC)安全系統，它由NSA編寫並設計成內核模塊包含到內核中，相應的某些安全相關的應用也被打了SELinux的補丁，最後還有一個相應的安全策略。任何程序對其資源享有完全的控制權。假設某個程序打算把含有潛在重要信息的文件扔到/tmp目錄下，那麼在DAC情況下沒人能阻止他。SELinux提供了比傳統的UNⅨ許可權更好的訪問控制。 1. 簡介 SELinux帶給Linux的主要價值是：提供了一個靈活的，可配置的MAC機制。 Security-Enhanced Linux (SELinux)由以下兩部分組成： 1) Kernel SELinux模塊(/kernel/security/selinux) 2) 用戶態工具 SELinux是一個安全體系結構，它通過LSM(Linux Security Moles)框架被集成到Linux Kernel 2.6.x中。它是NSA (United States National Security Agency)和SELinux社區的聯合項目。 SELinux提供了一種靈活的強制訪問控制(MAC)系統，且內嵌於Linux Kernel中。SELinux定義了系統中每個【用戶】、【進程】、【應用】和【文件】的訪問和轉變的許可權，然後它使用一個安全策略來控制這些實體(用戶、進程、應用和文件)之間的交互，安全策略指定如何嚴格或寬松地進行檢查。 SELinux對系統用戶(system users)是透明的，只有系統管理員需要考慮在他的伺服器中如何制定嚴格的策略。策略可以根據需要是嚴格的或寬松的。 只有同時滿足了【標准Linux訪問控制】和【SELinux訪問控制】時，主體才能訪問客體。 1.1 DAC與MAC的關鍵區別(root用戶) 安 全增強型Linux(SELinux)開始是由NSA(國家安全局)啟動並加入到Linux系統中的一套核心組件及用戶工具，可以讓應用程序運行在其所需的最低許可權上。未 經修改過的Linux系統是使用自主訪問控制的，用戶可以自己請求更高的許可權，由此惡意軟體幾乎可以訪問任何它想訪問的文件，而如果你授予其root權 限，那它就無所不能了。 在SELinux中沒有root這個概念，安全策略是由管理員來定義的，任何軟體都無法取代它。這意味著那些潛在的惡意軟體所能造成的損害可以被控制在最小。一般情況下只有非常注重數據安全的企業級用戶才會使用SELinux。 操作系統有兩類訪問控制：自主訪問控制(DAC)和強制訪問控制(MAC)。標准Linux安全是一種DAC，SELinux為Linux增加了一個靈活的和可配置的的MAC。 所有DAC機制都有一個共同的弱點，就是它們不能識別自然人與計算機程序之間最基本的區別。簡單點說就是，如果一個用戶被授權允許訪問，意味著程序也被授權訪問，如果程序被授權訪問，那麼惡意程序也將有同樣的訪問權。 DAC最根本的弱點是主體容易受到多種多樣的惡意軟體的攻擊，MAC就是避免這些攻擊的出路，大多數MAC特性組成了多層安全模型。 SELinux實現了一個更靈活的MAC形式，叫做類型強制(Type Enforcement)和一個非強制的多層安全形式(Multi-Level Security)。 在Android4.2中，SELinux是個可選項，谷歌並沒有直接取消root許可權或其他功能。這是一個為企業級用戶或是對隱私數據極為重視的用戶提供的選項，普通消費者則完全可以關閉它。 2. SELinux的運行機制 SELinux決策過程如下圖所示： 當一個subject(如: 一個應用)試圖訪問一個object(如：一個文件)，Kernel中的策略執行伺服器將檢查AVC (Access Vector Cache), 在AVC中，subject和object的許可權被緩存(cached)。如果基於AVC中的數據不能做出決定，則請求安全伺服器，安全伺服器在一個矩陣中查找“應用+文件”的安全環境。然後根據查詢結果允許或拒絕訪問，拒絕消息細節位於/var/log/messages中。 3. SELinux偽文件系統 /selinux/偽文件系統kernel子系統通常使用的命令，它類似於/proc/偽文件系統。系統管理員和用戶不需要操作這部分。/selinux/目錄舉例如下： 代碼如下: -rw-rw-rw- 1 root root 0 Sep 22 13:14 access dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans --w------- 1 root root 0 Sep 22 13:14 commit_pending_bools -rw-rw-rw- 1 root root 0 Sep 22 13:14 context -rw-rw-rw- 1 root root 0 Sep 22 13:14 create --w------- 1 root root 0 Sep 22 13:14 disable -rw-r--r-- 1 root root 0 Sep 22 13:14 enforce -rw------- 1 root root 0 Sep 22 13:14 load -r--r--r-- 1 root root 0 Sep 22 13:14 mls -r--r--r-- 1 root root 0 Sep 22 13:14 policyvers -rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel -rw-rw-rw- 1 root root 0 Sep 22 13:14 user 如cat enforce其值可能如下： 1： enforcing mode 0： permissive mode 4. SELinux配置文件 SELinux配置文件(configuration)或策略文件(policy)位於/etc/目錄下。 4.1 /etc/sysconfig/selinux配置文件 /etc/sysconfig/selinux是一個符號鏈接，真正的配置文件為：/etc/selinux/config 配置SELinux有如下兩種方式： 1) 使用配置工具：Security Level Configuration Tool (system-config-selinux) 2) 編輯配置文件 (/etc/sysconfig/selinux). /etc/sysconfig/selinux中包含如下配置選項： 1) 打開或關閉SELinux 2) 設置系統執行哪一個策略(policy) 3) 設置系統如何執行策略(policy) 4.2 配置文件選項 4.2.1 SELINUX SELINUX=enforcingpermissivedisabled —定義SELinux的高級狀態 • enforcing — The SELinux security policy is enforced. • permissive — The SELinux system prints warnings but does not enforce policy. • disabled — SELinux is fully disabled. SELinux hooks are disengaged from the kernel and the pseudo-file system is unregistered. 4.2.2 SELINUXTYPE(安全策略) SELINUXTYPE=targetedstrict — 指定SELinux執行哪一個策略 • targeted — 只有目標網路daemons保護。每個daemon是否執行策略，可通過system-config-selinux進行配置。保護常見的網路服務，為SELinux默認值。 可使用如下工具設置每個daemon的布爾值： 1) getsebool -a： 列出SELinux的所有布爾值 2) setsebool： 設置SELinux布爾值，如：setsebool -P dhcpd_disable_trans=0，-P表示即使用reboot之後，仍然有效。 • strict — 對SELinux執行完全的保護。為所有的subjects和objects定義安全環境，且每一個Action由策略執行伺服器處理。提供符合Role-based-Access Control(RBAC)之policy，具備完整的保護功能，保護網路服務、一般指令及應用程序。 4.2.3 SETLOCALDEFS SETLOCALDEFS=01 — 控制如何設置本地定義(users and booleans)。 • 1：這些定義由load_policy控制，load_policy來自於文件/etc/selinux/ • 0：由semanage控制 4.3 /etc/selinux/目錄 /etc/selinux/是存放所有策略文件和主要配置文件的目錄。其例子如下： 代碼如下: -rw-r--r-- 1 root root 448 Sep 22 17:34 config drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted 5. SELinux工具 1) /usr/sbin/setenforce — 修改SELinux運行模式，例子如下： • setenforce 1 — SELinux以強制(enforcing)模式運行 • setenforce 0 — SELinux以警告(permissive)模式運行 為了關閉SELinux，你可以修改配置文件：/etc/selinux/config或/etc/sysconfig/selinux 2) /usr/sbin/sestatus -v — 顯示系統的詳細狀態，例子如下： SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted Process contexts: Current context: user_u:system_r:unconfined_t:s0 Init context: system_u:system_r:init_t:s0 /sbin/mingetty system_u:system_r:getty_t:s0 3) /usr/bin/newrole — 在一個新的context或role中運行一個新的shell 4) /sbin/restorecon — 通過為適當的文件或安全環境標記擴展屬性，設置一個或多個文件的安全環境 5) /sbin/fixfiles — 檢查或校正文件系統中的安全環境資料庫 6) getsebool — getsebool -a：查看所有布爾值 7) setsebool — 參數-P，永久性設置 8) chcon 修改文件、目錄的安全上下文 chcon –u[user] chcon –r[role] chcon –t[type] chcon –R 遞歸 6. 類型強制的安全上下文(Type Enforcement Security Context) 安全上下文是一個簡單的、一致的訪問控制屬性，在SELinux中，類型標識符是安全上下文的主要組成部分，由於歷史原因，一個進程的類型通常被稱為一個域(domain)，"域"和"域類型"意思都一樣，我們不必苛刻地去區分或避免使用術語域，通常，我們認為【域】、【域類型】、【主體類型】和【進程類型】都是同義的，即都是安全上下文中的“TYPE”。 SELinux對系統中的許多命令做了修改，通過添加一個-Z選項顯示客體和主體的安全上下文。 1) 系統根據PAM子系統中的pam_selinux.so模塊設定登錄者運行程序的安全上下文; 2) 文件的Security Contex規則如下： • rpm包安裝的：會根據rpm包內記錄來生成安全上下文; • 手動創建的文件：會根據policy中規定的來設置安全上下文; • cp：會重新生成安全上下文; • mv：安全上下文則不變。 3) id -Z 顯示了你的shell的安全上下文; 4) ps -Z 檢查進程的安全上下文; 5) ls -Z 檢查文件、目錄的安全上下文; 6.1 安全上下文格式 所有操作系統訪問控制都是以關聯的客體和主體的某種類型的訪問控制屬性為基礎的。在SELinux中，訪問控制屬性叫做安全上下文。所有客體(文件、進程間通訊通道、套接字、網路主機等)和主體(進程)都有與其關聯的安全上下文，一個安全上下文由三部分組成：用戶、角色和類型標識符。常常用下面的格式指定或顯示安全上下文： USER：ROLE：TYPE[LEVEL[：CATEGORY]] 安全上下文中的用戶和角色標識符除了對強制有一點約束之外對類型強制訪問控制策略沒什麼影響，對於進程，用戶和角色標識符顯得更有意義，因為它們是用於控制類型和用戶標識符的聯合體，這樣就會與Linux用戶賬號關聯起來;然而，對於客體，用戶和角色標識符幾乎很少使用，為了規范管理，客體的角色常常是object_r，客體的用戶常常是創建客體的進程的用戶標識符，它們在訪問控制上沒什麼作用。 標准Linux安全中的用戶ID和安全上下文中的用戶標識符之間的區別，就技術而論，它們是正交標識符，分別用於標準的和安全增強的訪問控制機制，這兩者之間的任一相互關聯都是通過登陸進程按照規范嚴格規定的，而不是通過SELinux策略直接強制實施的。 6.1.1 USER 1) user identity：類似Linux系統中的UID，提供身份識別，用來記錄身份;安全上下文的一部分; 2) 三種常見的 user: • user_u ：普通用戶登錄系統後的預設; • system_u ：開機過程中系統進程的預設; • root ：root 登錄後的預設; 3) 在 targeted policy 中 users 不是很重要; 4) 在strict policy 中比較重要，所有預設的 SELinux Users 都是以 “_u” 結尾的，root 除外。 6.1.2 ROLE 1) 文件、目錄和設備的role：通常是 object_r; 2) 程序的role：通常是 system_r; 3) 用戶的role：targeted policy為system_r; strict policy為sysadm_r、staff_r、user_r;用戶的role，類似系統中的GID，不同角色具備不同的的許可權;用戶可以具備多個role;但是同一時間內只能使用一個role; 4) 使用基於RBAC(Roles Based Access Control) 的strict和mls策略中，用來存儲角色信息 6.1.3 TYPE 1) type：用來將主體(subject)和客體(object)劃分為不同的組，給每個主體和系統中的客體定義了一個類型;為進程運行提供最低的許可權環境; 2) 當一個類型與執行中的進程相關聯時，其type也稱為domain; 3) type是SElinux security context 中最重要的部位，是 SELinux Type Enforcement 的心臟，預設值以_t結尾; LEVEL和CATEGORY：定義層次和分類，只用於mls策略中 • LEVEL：代表安全等級,目前已經定義的安全等級為s0-s15,等級越來越高 • CATEGORY：代表分類，目前已經定義的分類為c0-c1023 6.2 對比SELinux和標准Linux的訪問控制屬性 在標准Linux中，主體的訪問控制屬性是與進程通過在內核中的進程結構關聯的真實有效的用戶和組ID，這些屬性通過內核利用大量工具進行保護，包括登陸進程和setuid程序，對於客體(如文件)，文件的inode包括一套訪問模式位、文件用戶和組ID。以前的訪問控制基於讀/寫/執行這三個控制位，文件所有者、文件所有者所屬組、其他人各一套。 在SELinux中，訪問控制屬性總是安全上下文三人組(用戶：角色：類型)形式，所有客體和主體都有一個關聯的安全上下文。需要特別指出的是，因為SELinux的主要訪問控制特性是類型強制，安全上下文中的類型標識符決定了訪問權。 注意：SELinux是在標准Linux基礎上增加了類型強制(TE: Type Enforcement)，這就意味著標准Linux和SELinux訪問控制都必須滿足先要能訪問一個客體，例如：如果我們對某個文件有SELinux寫入許可權，但我們沒有該文件的w許可，那麼我們也不能寫該文件。下表總結了標准Linux和SELinux之間訪問控制屬性的對比： 標准Linux SELInux 進程安全屬性 真實有效的用戶和組ID 安全上下文 客體安全屬性 訪問模式、文件用戶和組ID 安全上下文 訪問控制基礎 進程用戶/組ID和文件的訪問模式， 此訪問模式基於文件的用戶/組ID 在進程類型和文件類型 之間允許的許可 6.3 小結 1) 系統中每個文件、目錄、網路埠等都被指定一個安全上下文，policy 則給出各安全上下文之間的作用規則。 2) SELinux根據policy及security context規則來決定存取行為是否可執行; 3) Subject(主體)：系統進程，比如/usr/sbin/httpd; 4) Object(客體)：被存取的項目，比如File、Directory、IP、Socket等; 7. 類型強制(TE)訪問控制 在SELinux中，所有訪問都必須明確授權，SELinux默認不允許任何訪問，不管Linux用戶/組ID是什麼。這就意味著在SELinux中，沒有默認的超級用戶了，與標准Linux中的root不一樣，通過指定主體類型(即域)和客體類型使用allow規則授予訪問許可權，allow規則由四部分組成： • 源類型(Source type(s) ) 通常是嘗試訪問的進程的域類型 • 目標類型(Target type(s) ) 被進程訪問的客體的類型 • 客體類別(Object class(es)) 指定允許訪問的客體的類型 • 許可(Permission(s)) 象徵目標類型允許源類型訪問客體類型的訪問種類 舉例如下： 代碼如下: allow user_t bin_t : file {read execute getattr}; 這個例子顯示了TE allow規則的基礎語法，這個規則包含了兩個類型標識符：源類型(或主體類型或域)user_t，目標類型(或客體類型)bin_t。標識符file是定義在策略中的客體類別名稱(在這里，表示一個普通的文件)，大括弧中包括的許可是文件客體類別有效許可的一個子集，這個規則解釋如下： 擁有域類型user_t的進程可以讀/執行或獲取具有bin_t類型的文件客體的屬性。 SELinux allow規則如之前的例子在SELinux中實際上都是授予訪問權的，真正的挑戰是如何保證數以萬計的訪問正確授權，只授予必須的許可權，實現盡可能的安全。 7.1 標准Linux安全中的setuid程序 精通用戶joe想安全地修改現有的密碼問題，Linux解決這個問題的方法是通過給passwd賦一個setuid值，使其執行時具有root許可權，如果你在一個普通Linux系統上列出密碼文件，你看到的會是： 復制代碼 代碼如下: # ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 41292 Sep 7 2012 /usr/bin/passwd 這里注意兩件事，第一個是在所有者許可權的x位置被設置為s了，這就是所謂的setuid位，意思是任何執行這個文件的進程，它的有效UID(即用戶ID)將會被改為文件所有者。這里，root是文件所有者，因此當執行密碼程序時實際上將會以root用戶的ID運行。其執行過程如下圖所示： 從上面的分析中可以看出，passwd以root許可權的身份運行， 它可以訪問系統的任何資源，這給系統帶來了安全問題，其實它只需要訪問shadow及其相關的文件就可以了。而且shadow只需要接受passwd的訪問即可。這在標准Linux中是無法做到的，而TE(類型強制)可實現此功能。 8. 基於角色的訪問控制 SELinux也提供了一種基於角色的訪問控制(RBAC)，SELinux的RBAC特性是依靠類型強制建立的，SELinux中的訪問控制主要是通過類型實現的，角色基於進程安全上下文中的角色標識符限制進程可以轉變的類型，如此，策略編寫器可以創建一個角色，允許它轉變為一套域類型(假設類型強制規則允許轉變)，從而定義角色的限制。 9. SELinux中的多級安全(Multi-Level Security) 類型強制(Type Enforcement)無疑是SELinux引入的最重要的強制訪問控制(MAC)機制，然而，在某些情況下，主要是保密控制應用程序的一個子集，傳統的多級安全(MLS)MAC與類型強制一起使用顯得更有價值，在這些情況下，SELinux總是包括某種格式的MLS功能，MLS特性是可選的，在SELinux的兩個MAC機制中，它通常不是最重要的那個，對大多數安全應用程序而言，包括許多非保密數據應用程序，類型強制是最適合的安全增強的機制，盡管如此，MLS對部分應用程序還是增強了安全性。 在大多數SELinux策略中，敏感度(s0，s1，...)和范疇(c0，c1，...)使用通配名，將它留給用戶空間程序和程序庫，以指定有意義的用戶名。(例如：s0可能與UNCLASSIFIED 關聯，s1可能與SECRET關聯) 為了支持MLS，安全上下文被擴展了，包括了安全級別，如： 復制代碼 代碼如下: user:role:type:sensitivity[:category,...] [-sensitivity[:category,...]] 例子如下所示： 復制代碼 代碼如下: root@luohj-virtual-machine:~# ps -aZ LABEL PID TTY TIME CMD unconfined_u:system_r:insmod_t:s0-s0:c0.c255 4940 pts/0 00:00:00 passwd 注意MLS安全上下文至少必須有一個安全級別(它由單個敏感度和0個或多個范疇組成)，但可以包括兩個安全級別，這兩個安全級別分別被叫做低(或進程趨勢)和高(或進程間隙)，如果高安全級別丟失，它會被認為與低安全級別的值是相同的(最常見的情況)，實際上，對於客體和進程而言，低和高安全級別通常都是相同的，通常用於進程的級別范圍被認為是受信任的主體(即進程信任降級信息)或多層客體，如一個目錄，它又包括了不同安全級別的客體。為了使描述簡單，假設所有的進程和客體都只有一個安全級別。 10. 策略分析工具apol apol(即analyze policy【分析策略】)工具是一個成熟的SELinux策略分析工具，它位於setools工具包中。使用它打開policy.xx文件即可分析所有的相關策略。xx為策略編譯器(checkpolicy)的版本號。 11. 小結 SELinux訪問控制是基於與所有系統資源(包括進程)關聯的安全上下文的，安全上下文包括三個組件：用戶、角色和類型標識符。類型標識符是訪問控制的主要基礎。 在SELinux中，訪問控制的主要特性是類型強制，在主體(即進程)與客體之間通過指定allow規則(主體的類型【也叫做域類型】是源，客體的類型是目標)進行訪問授權，訪問被授予特定的客體類別，為每個客體類別設置細粒度的許可。 類型強制的一個關鍵優勢是它可以控制哪個程序可能運行在給定的域類型上，因此，它允許對單個程序進行訪問控制(比起用戶級的安全控制要安全得多了)，使程序進入另一個域(即以一個給定的進程類型運行)叫做域轉變，它是通過SELinux的allow規則緊密控制的，SELinux也允許通過type_transition 文件使域轉變自動發生。 SELinux在訪問控制安全上下文中不直接使用角色標識符，相反，所有的訪問都是基於類型的，角色用於關聯允許的域類型，這樣可以設置類型強制允許的功能組合到一起，將用戶作為一個角色進行認證。 SELinux提供了一個可選的MLS訪問控制機制，它提供了更多的訪問限制，MLS特性依靠TE機制建立起來的，MLS擴展了安全上下文的內容，包括了一個當前的(或低)安全級別和一個可選的高安全級別。

③ 安卓usb dac,機器不能調節音量

對於安卓系統，開USB獨占播放DSD是無法控制系統音量的。
對於沒有獨立音量控制的USBDAC無解，但播放PCM則系統音量控制正常。DSD與PCM音質相比，反正我是聽不出任何的區別，體積還比WAV大2～3倍，再說現在的DSD大多是由PCM升頻而來，真正從唱片廠原版的SACD轉存出來的ISO文件少之又少，音質反倒比真正的WAV還差。

④ 安卓系統的自主訪問控制和強制訪問控制是怎麼操作的

自主訪問控制
自主訪問的含義是有訪問許可的主體能夠直接或間接地向其他主體轉讓訪問權。自主訪問控制是在確認主體身份以及（或）它們所屬的組的基礎上，控制主體的活動，實施用戶許可權管理、訪問屬性（讀、寫、執行）管理等，是一種最為普遍的訪問控制手段。自主訪問控制的主體可以按自己的意願決定哪些用戶可以訪問他們的資源，亦即主體有自主的決定權，一個主體可以有選擇地與其它主體共享他的資源。
基於訪問控制矩陣的訪問控製表（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最主要的優勢是它阻止特洛伊木馬的能力 一個特洛伊木馬是在一個執行某些合法功能的程序中隱藏的代碼，它利用運行此程序的主體的許可權違反安全策略 通過偽裝成有用的程序在進程中泄露信息 一個特洛伊木馬能夠以兩種方式泄露信息： 直接與非直接泄露 前者， 特洛伊木馬以這樣一種方式工作， 使信息的安全標示不正確並泄露給非授權用戶； 後者特洛伊木馬通過以下方式非直接地泄露信息： 在返回給一個主體的合法信息中編制 例如： 可能表面上某些提問需要回答， 而實際上用戶回答的內容被傳送給特洛伊木馬。

⑤ android 哪個版本支持usb音頻輸出

應該是android L這個版本支持的，參考如下內容
如果你還盼望著在你的安卓手機或安卓平板電腦上使用你的USB DAC（數模轉換器）的話，那麼Android L的發布就能滿足你這個願望了，安卓系統之前並不支持USB音頻輸出（某些手機製造商可能添加了該功能，但是很少），現在在Android L上已經原生支持了，谷歌在I/O大會上演示了這一功能。

如果你不清楚這個功能的重要性，也沒關系，一般是比較喜歡音頻設備和音樂製作的人比較注重這個功能，對於這些人來說，這是一個很大的進步，iOS系統一直是音響愛好者和音樂家最喜歡的手機平台，其中的原因之一就是iOS平台有很多的第三方音頻附件可以充分利用該平台的USB外置音頻支持功能，其中就包括DACs——數模轉換器。

⑥ dx90 怎麼設置為安卓dac

您好，很高興為您解答。

DX90在DX50基礎上升級為ES9018-K2M雙解碼，並且加入了繼電器，

消除開關機的電流脈沖雜音，輸出電平提升至:1.7V rms

並且支持USB DAC功能解碼24bit/192k音樂文件，

聲音上細節更豐富，動態響應更快，兩頻延伸更出色。
希望我的回答對您有所幫助，望採納！

⑦ 如何在Android平台上使用USB Audio設備

需求:USB Headset插上去後，聲音要從本地CODEC切換到USB Headset輸出/輸入。 上網搜了有關USB Audio Hotplug的東西，比較適用的資源如下:1、Hotplugging USB audio devices (Howto) 題目看起來很吻合我們的問題，事實上並沒有多少參考價值。其中腳本 /etc/hotplug/usb/extigy或許可以捕捉到USB Audio設備的熱插拔事件，應該可以進一步驗證和利用，留意這點。 2、Example to map USB Ports to ALSA card numbers and add each sound card to a combined, single interface device 這是利用udev來獲取USB熱插拔事件，雖然Android沒有udev，但例子程序對熱插拔事件字元串的處理值得參考。 3、USB mic on Linux 其實我們工作的第一步:驗證USB Headset是否可以回放錄音。 3.1、插上USB Headset，可以看到alsa的確載入了USB Audio，如下: ~ # cat /proc/asound/cards 0 [WMTSOC ]: HWDAC - WMT_SOC WMT_SOC (HWDAC) 1 [default ]: USB-Audio - C-Media USB Headphone Set 3.2、參考了這個鏈接，寫了如下的配置文件/etc/asond.conf: pcm.!default {type asymplayback.pcm {type plugslave.pcm hw:1,0}capture.pcm {type plugslave.pcm hw:1,0}} 重啟後，聲音就從Headset出來了。 hw:1,0對應card1即USB-Audio - C-Media USB Headphone Set4、Linux下USB設備熱插拔 到此，需要考慮在Android平台切換USB Audio的實現問題了。有幾個途徑:1/ hotplug/usb;2/ udev;3/ netlink。這里就是netlink的實現方式，鏈接里有個證實可用的例子程序，目前可能需要做熱插拔事件字元串的處理。 難點:Android音頻設備的切換底層入口是alsa_default.cpp，目前看來需要在asound.conf定義好local CODEC和USB Audio的plug;還需要修改 alsa_default.cpp，最主要Android要知道USBAudio插上時打開 USB Audio的plug， USB Audio拔下時打開local CODEC的plug。這樣一想，修改的幅度還是蠻大的。而且未能確定如果在播放的過程中，切換音頻設備是否有影響?如果alsa允許只是配置好asound.conf達到同樣的目的，那就好辦了，可惜目前找不到這方面的資料，應該沒有這個便利了。 進展:2011/9/19:按照以上難點分析，大致完成了整個Android框架層的代碼和ALSA配置文件，基本實現了USB Audio熱插拔時的音頻設備切換。但有個很大的問題:在播放時切換音頻設備會導致AudioFlinger服務crash(之前做2G通話時也遇到這個問題，用其他辦法規避了)。看來在切換音頻設備時，應該停止播放;等切換完成後，再恢復播放。

⑧ 手機繞過安卓src後用aux介面播放音樂高采樣率的音樂效果好嗎請懂的來解答。

我認為直接輸出，或者帶dac輸出，或者hifi晶元輸出，接同樣的音箱效果都一樣。普通人分辨不出來。
無論你是直接用耳機孔，或者是帶dac的usb轉接線，或者是帶hifi晶元的手機，比如lg v30等。用aux連接音響或者功放，效果上都差別不大。以現在的硬體來說，什麼32bit,24bit,或者cd的16bit,只要是高音質文件，播放起來都一樣。
區別主要就是音效，有些軟體的音效，或者手機自動的音效對聲音影響很大，不過這個比較主觀，而且很多人不喜歡開音效，可能帶hifi晶元心理感覺更好一些。另外一些環繞立體聲，虛擬5.1之類有時候還可以。
好一些的就是底噪小一些，用音箱聽，有限的底噪其實沒什麼關系。
強迫症就是多花些錢，我就燒過一些機器，花費不少錢。只能說音色不同。
有時候音箱影響更大，全頻喇叭確實效果更好。

⑨ 樂之邦md12 android驅動

作為一款DAC外置音效卡，現在很多手機都是不支持的，sonyZ2在聲音選項中有DAC音效卡的選項，但是一般手機都是沒有的，限制於諸多因素不會載入這個驅動。你的手機如果原生不支持DAC音效卡的話，請谷歌USB Audio Recorder Pro這個驅動，基本上能讓安卓2.3以上手機支持現今市面上大部分DAC音效卡，請注意把OTG線連接正確。如果裝上軟體還是用不了的話請自行刷入google服務框架。因為現在市面上的定製UI大部分都刪除了谷歌服務，還不行的話再問我