linux 服务 权限 linux权限详解

老铁们，大家好，相信还有很多朋友对于linux 服务 权限和linux权限详解的相关问题不太懂，没关系，今天就由我来为大家分享分享linux 服务 权限以及linux权限详解的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

linux下文件夹权限设置

1、Linux权限说明

linux的文件夹也有三种权限分别是：

r(Read读取)：对文件有读取文件内容的权限(cat指令)；对目录有查看目录下内容的权限(ls命令)。

x(eXecute执行)：对文件有执行文件的权限(./指令)；对目录该有进入目录的权限(cd命令)。

w(Write写入)：对文件有增加、删除、修改文件内容的权限；对目录有增加、删除、修改目录下内容的权限。w是可以在目录下创建、修改、删除文件，不仅可以修改自己的文件也可以修改别人的文件，因此增加了一个t权限对 x权限进行了限制，表示只可以修改自己的文件。

umask命令可以设置系统的权限掩码，即可以控制文件夹、文件生成时的默认权限。文件夹的默认权限是755、文件的权限644.root帐号的umask是022，而普通用户的umask是002，这代表root用户的文件对于其他用户来说默认的权限更少。文件的默认权限是用666减umask，而文件夹的默认权限是用777减umask,这样的话相当于无论何时生成的文件的默认权限都是不可能有运行的权限。umask的设置可以在配置文件/etc/bashrc中进行设置、更改。

2、改变权限

改变拥有者chown(change owner)：

chown yly tmp//改变文件tmp的拥有者为yly用户

chown-R yly:yly tmp//改变tmp文件及其下的文件和子目录的权限为yly用户:yly组

说明：要改变的文件拥有者，也就是用户名必须存在于/etc/passwd文件中，否则就会显示错误。另外用户密码

是保存在/etc/shadow文件夹中的。

改变群组chgrp(change group)：

chgrp yly tmp//改变tmp文件的群组为yly组

说明：要改变的目标群组名称必须在于/etc/group文件中存在，否则就会显示错误。

注意：当使用cp指令复制文件时，被复制的文件拥有者和群组仍没有改变，此时需要使用以上指令进行设置。

改变文件权限chmod

文件服务器权限管理怎么做

如何做一台文件服务器\x0d\x0a假如你是某公司的系统管理员，现在公司要做一台文件服务器。公司购买了一台某品牌的服务器，在这台服务器内插有三块硬盘。 \x0d\x0a公司有三个部门---销售，财务，技术。每个部门有三个员工，其中一名是其部门经理（另两名是副经理）1.在三块硬盘上共创建三个分区（盘符）,并要求在创建分区的时候，使磁盘实现容错的功能； \x0d\x0a2.在服务器上创建相应的用户帐号和组； \x0d\x0a命名规范，如：用户名：sales-1，sales-2??；组名：sale，tech?? \x0d\x0a要求用户帐号只能从网络访问服务器，不能在服务器本地登录 \x0d\x0a3.在文件服务器上创建三个文件夹分别存放各部门的文件，并要求只有本部门的用户能访问其部门的文件夹（完全控制的权限），每个部门的经理和公司总经理可以访问所有文件夹（读取），另创建一个公共文件夹，使得所有用户都能在里面查看和存放公共的文件； \x0d\x0a4.每个部门的用户可以在服务器上存放最多100M的文件； \x0d\x0a5.做好文件服务器的备份工作以及灾难恢复的备份工作； \x0d\x0a发送给我的好友提醒我回答有更新 \x0d\x0a你可以把这个生意经分享给旺旺，MSN或QQ上的好友 \x0d\x0a\x0d\x0a当这个生意经的回答有更新时，您可以及时收到提醒 \x0d\x0a\x0d\x0a发送给好友\x0d\x0a\x0d\x0a生意经链接： \x0d\x0a窗体顶端\x0d\x0a\x0d\x0a发送描述： \x0d\x0a窗体底端\x0d\x0a\x0d\x0a郁闷啦!看看这个问题，你一定要帮我啊！\x0d\x0a \x0d\x0a这个东东太实用了，看完记得收藏哦！\x0d\x0a \x0d\x0a旺旺浮出提醒好友\x0d\x0a\x0d\x0a生意经的地址已经复制\x0d\x0a您可以粘帖到MSN或者邮件发给您的好友 \x0d\x0a\x0d\x0a收藏成功，回答有更新时旺旺会浮出提醒你哦！现在就去查看我的收藏 \x0d\x0a\x0d\x0a网友回答 \x0d\x0a\x0d\x0a(1)学会安装和配置文件服务器。\x0d\x0a\x0d\x0a(2)学会服务器端共享文件夹的配置和管理。\x0d\x0a\x0d\x0a(3)学会客户端访问共享文件夹的方法。\x0d\x0a\x0d\x0a(4)学会分布式文件系统的设置方法。\x0d\x0a\x0d\x0a(5)实验学时：2\x0d\x0a\x0d\x0a2实验相关理论与知识\x0d\x0a\x0d\x0a计算机网络的基本功能是在计算机间共享信息，文件共享可以说是最基本、最普遍的一种网络服务。虽然越来越多的用户购置专用文件服务器(如NAS)，但是通用操作系统提供的文件服务器功能也非常实用，完全能满足一般的文件共享需求，下面主要介绍Windows Server 2003文件服务器的配置、管理和应用。\x0d\x0a\x0d\x0a文件服务器负责共享资源的管理和传送接收，管理存储设备(硬盘、光盘、磁带)中的文件，为网络用户提供文件共享服务，也称文件共享服务器。除了文件管理功能之外，文件服务器还要提供配套的磁盘缓存、访问控制、容错等功能。部署文件服务器，主要要考虑以下3个因素。\x0d\x0a\x0d\x0a·存取速度：快速存取服务器上的文件，例如可提供磁盘缓存加速文件读取。\x0d\x0a\x0d\x0a·存储容量：要有足够的存储空间以容纳众多网络用户的文件，可使用磁盘阵列。\x0d\x0a\x0d\x0a·安全措施：实现网络用户访问控制，确保文件共享安全。\x0d\x0a\x0d\x0a文件服务器主要有两类解决方案，一类是专用文件服务器，另一类是使用PC服务器或PC计算机组建的通用文件服务器。\x0d\x0a\x0d\x0a专用文件服务器是专门设计成文件服务器的专用计算机，以前主要是运行操作系统、提供网络文件系统的大型机、小型机，现在的专用文件服务器则主要指具有文件服务器的网络存储系统，如NAS和 SAN。NAS独立于操作系统平台，可支持多种操作系统和网络文件系统，提供集中化的网络文件服务器和存储环境，比一般的文件服务器的功能更强大，可看作是专用存储服务器，可为那些访问和共享大量文件系统数据的用户提供高效、性能价格比优异的解决方案。SAN全称存储区域网络，是一种用户存储服务的特殊网络，通常由磁盘阵列、光盘库、磁带库和光纤交换机组成。NAS可作为独立的文件服务器，提供文件级的数据访问功能，更适合文件共享。而SAN提供数据块级的数据访问功能，更适合数据库和海量数据。\x0d\x0a\x0d\x0a目前一般用户使用PC服务器或PC计算机，通过网络操作系统来提供文件服务，UNIX、Linux、Novell、 Windows等操作系统都可提供文件共享服务。Windows网络操作系统，如Windows NT Server、Windows2000 Server和最新的Windows Server 2003由于操作管理简单、功能强大，在中小用户群中的普及率非常高，许多文件服务器都运行Windows网络操作系统。下面将重点以Windows Server 2003为例介绍文件服务器的配置、管理和应用。\x0d\x0a\x0d\x0a3实验环境与设备\x0d\x0a\x0d\x0aC/S模式的网络环境，包括一台Windows XP客户机和一台Windows Server 2003服务器。\x0d\x0a\x0d\x0a两种可选的物理拓扑（交叉线连接或通过集线器/交换机用直连线连接）。\x0d\x0a\x0d\x0a4实验内容与步骤\x0d\x0a\x0d\x0a4.0服务器的基本网络配置，包括IP地址为"192.168.105.XX"、网关为"192.168.105.254"等。(注："XX"代表你配置机器的主机编号，"nXX"代表你的服务器主机名，例如你坐在5号机上则"XX"代表"05"，"1XX"代表"105"，配置此机的IP地址为"192.168.105.5"、主机名为"n05"，下同)。\x0d\x0a\x0d\x0a4.1安装和配置文件服务器\x0d\x0a\x0d\x0a文件服务器提供网络上的中心位置，可供存储文件并通过网络与用户共享文件。当用户需要重要文件时，可以访问文件服务器上的文件，而不必在各自独立的计算机之间传送文件。如果网络用户需要对相同文件和可通过网络访问的应用程序的访问权限，就要将该计算机配置为文件服务器。默认情况下，在安装Windows Server 2003系统时，将自动安装"Microsoft网络的文件和打印共享"网络组件。如果没有该组件，可通过网络连接属性对话框安装。\x0d\x0a\x0d\x0a1．准备工作\x0d\x0a\x0d\x0a在部署文件服务器之前，应当做好以下准备工作。\x0d\x0a\x0d\x0a·划出专门的硬盘分区(卷)用于提供文件共享服务，而且要保证足够的存储空间，必要时使用磁盘阵列。\x0d\x0a\x0d\x0a·磁盘分区(卷)使用NTFS文件系统，因为FAT32缺乏安全性，而且不支持文件和文件夹压缩、磁盘配额、文件加密或单个文件权限等重要特性。\x0d\x0a\x0d\x0a提示：使用Windows Server 2003自带的工具即可将FAT32转换成NTFS格式。该工具名为Convert.exe，位于Windows安装目录下的System32目录中。在命令行状态运行该工具即可，如Convert E:/FS:NTFS。\x0d\x0a\x0d\x0a·确定是否要启用磁盘配额，以限制用户使用的磁盘存储空间。\x0d\x0a\x0d\x0a·确定是否要使用索引服务，以提供更快速、更便捷的搜索服务。\x0d\x0a\x0d\x0a2．配置文件服务器\x0d\x0a\x0d\x0a只要将Windows Server 2003计算机上的某个文件夹共享出来，就会自动安装文件服务器，也可通过"配置您的服务器向导"工具来安装文件服务器角色。这两种方法的差别是，第二种方法提供更多的选项，并在程序菜单中提供文件服务器管理台工具。这里介绍采用第二种方法的基本步骤。\x0d\x0a\x0d\x0a(1)启动"配置您的服务器向导"工具。默认情况下，登录Windows Server 2003时将自动启动"管理您的服务器"(也可从控制面板中选择【管理工具】→【管理您的服务器】)，单击【添加或删除角色】。另一种方法是直接从控制面板中选择【管理工具】→【管理您的服务器】→【配置您的服务器向导】。单击【下一步】按钮。\x0d\x0a\x0d\x0a(2)在【配置选项】界面中选择【自定义配置】，单击【下一步】按钮。\x0d\x0a\x0d\x0a(3)在【服务器角色】界面中，如果【文件服务器】的【已配置】状态为"否"，就单击【文件服务器】，然后单击【下一步】。\x0d\x0a\x0d\x0a注意：如果【文件服务器】的【已配置】状态为"是"，就单击【文件服务器】，再单击【下一步】按钮打开【角色删除确认】界面，并选择【删除文件服务器角色】复选框，即可删除文件服务器角色，这样该服务器上的文件和文件夹就不再共享，依赖于这些共享资源的网络用户、程序或宿主都将无法与它们连接。\x0d\x0a\x0d\x0a(4)出现【文件服务器磁盘配额】对话框中，为服务器上所有NTFS分区设置默认的磁盘配额。勾选【为此服务器的新用户设置默认磁盘空间配额】和【拒绝将磁盘空间给超过配额限制的用户】。单击【下一步】按钮。默认情况下是没有启用磁盘配额。\x0d\x0a\x0d\x0a(5)出现【文件服务器索引服务】对话框，确定是否要使用索引服务。单击【下一步】按钮。一般情况下不需索引服务，只有在用户要经常搜索该服务器上的文件内容时才启用它。\x0d\x0a\x0d\x0a(6)出现【选择总结】对话框，查看和确认已经选择的选项，单击【下一步】按钮。\x0d\x0a\x0d\x0a本例中有"设置默认磁盘配额"、"安装文件服务器管理"和"运行共享文件夹向导来添加一个新的共享文件夹或共享已有文件夹"等选项。\x0d\x0a\x0d\x0a(7)自动完成相关配置后，出现共享文件夹向导，根据提示配置共享文件夹以供其他用户共享。只有配置了共享文件夹之后，文件服务器才能建立。\x0d\x0a\x0d\x0a(8)单击【下一步】按钮，出现【文件夹路径】对话框，指定要共享的文件夹路径。可通过【浏览】在C盘目录下新建一个【FileShare】作为共享目录，此时【文件夹路径】输入框中将出现【C:FileShare】（如果C盘中已经建立过此文件夹，才可以在此输入框中直接输入）。\x0d\x0a\x0d\x0a(9)单击【下一步】按钮，出现【名称、描述和设置】对话框，指定共享名。\x0d\x0a\x0d\x0a(10)单击【下一步】按钮，出现【权限】对话框，指定共享权限为【管理员有完全访\x0d\x0a\x0d\x0a问权限；其他用户有只读访问权限】，单击【完成】按钮。这里提供了几种预置的权限，也可以自定义权限。\x0d\x0a\x0d\x0a(11)【共享成功】对话框中显示共享成功，给出新建共享文件夹的信息。如果要继续设置其他共享文件夹，则选中下面的复选框。单击【关闭】按钮，【完成】。\x0d\x0a\x0d\x0a至此文件服务器配置就完成了。接下来可执行各项文件管理任务。\x0d\x0a\x0d\x0a3．文件服务器管理工具（以下方法至少掌握一种）\x0d\x0a\x0d\x0aWindows Server 2003提供了用于文件服务器配置管理的多种工具。\x0d\x0a\x0d\x0a·文件服务器管理控制台：打开"管理您的服务器"工具，在【文件服务器】区域单击【管理此文件服务器】，打开该控制台。要使用"配置您的服务器向导"工具安装文件服务器，可从程序菜单中选择【管理工具】→【文件服务器管理】命令打开该控制台。\x0d\x0a\x0d\x0a·"共享文件夹"管理工具：也可通过"计算机管理"工具中的"共享文件夹"管理工具来执行共享文件夹的配置管理，从程序菜单中选择【管理工具】→【计算机管理】，展开【共享文件夹】节点即可。\x0d\x0a\x0d\x0a·Windows资源管理器：可直接将文件夹配置为共享文件夹。\x0d\x0a\x0d\x0a·命令行工具：如net share可显示有关本地计算机上全部共享资源的信息。

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问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。