㈠ 主要有哪几种访问控制策略
三种不同的访问控制策略：自主访问控制（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）成为必然，它能够帮助企业网络免于多种网络安全威胁。
许多企业往往不愿意实施基于角色的访问控制。因为企业担心冗长而复杂的实施过程，并且由于雇员访问权要发生变化，也会对工作效率带来副作用。完成基于角色的矩阵可能是一个需要花费企业几年时间的复杂过程。有一些新方法可以缩短这个过程，并当即带来好处。企业可以采用人力资源系统作为数据源，收集所有雇员的部门、职位、位置以及企业的层次结构等信息，并将这些信息用于创建每个访问级别的角色。下一步就是从活动目录等位置获得当前的权利，以及与不同角色的雇员有关的数据共享。下一步，使数据标准化，确保相同角色的雇员拥有相同的访问权。可以通过从人力资源和活动目录、修正报告以及雇员的管理者那里收集数据，用于检查和纠正。基于角色的访问控制应用与身份管理系统结合使用，可以实施管理员在自动模式中做出的变化。此过程可以在包含敏感信息的企业网络的其它应用中多次反复实施，确保访问权的正确性。