diff --git a/Linux/Linux工具命令/ssh.md b/Linux/Linux工具命令/ssh.md
index 05b67993..dac1f2b3 100644
--- a/Linux/Linux工具命令/ssh.md
+++ b/Linux/Linux工具命令/ssh.md
@@ -165,3 +165,57 @@ service iptables save
 ```
 
 
+## 使用场景
+https://www.cnblogs.com/f-ck-need-u/p/10482832.html
+### 本地端口
+
+#### 问题
+如下图，假如host3和host1、host2都同互相通信，但是host1和host2之间不能通信，如何从host1连接上host2？
+对于实现ssh连接来说，实现方式很简单，从host1 ssh到host3，再ssh到host2，也就是将host3作为跳板的方式。但是如果不是ssh，而是http的80端口呢？如何让host1能访问host2的80端口？
+
+#### 转发实现
+ssh支持本地端口转发，语法格式为：
+```
+ssh -L [local_bind_addr:]local_port:remote:remote_port middle_host
+```
+以上图为例，实现方式是在host1上执行：
+```
+[root@xuexi ~]# ssh -g -L 2222:host2:80 host3
+```
+
+其中"-L"选项表示本地端口转发，其工作方式为：在本地指定一个由ssh监听的转发端口(2222)，将远程主机的端口(host2:80)映射为本地端口(2222)，当有主机连接本地映射端口(2222)时，本地ssh就将此端口的数据包转发给中间主机(host3)，然后host3再与远程主机的端口(host2:80)通信。
+
+"-g"选项，指定该选项表示允许外界主机连接本地转发端口(2222)，如果不指定"-g"，则host4将无法通过访问host1:2222达到访问host2:80的目的。甚至，host1自身也不能使用172.16.10.5:2222，而只能使用localhost:2222或127.0.0.1:2222这样的方式达到访问host2:80的目的，之所以如此，是因为本地转发端口默认绑定在回环地址上。可以使用bind_addr来改变转发端口的绑定地址，例如：
+```
+[root@xuexi ~]# ssh -L 172.16.10.5:2222:host2:80 host3
+```
+这样，host1自身就能通过访问172.16.10.5:2222的方式达到访问host2:80的目的。一般来说，使用转发端口，都建议同时使用"-g"选项，否则将只有自身能访问转发端口。
+
+#### 通信过程
+
+
+当host4发起172.16.10.5:2222的连接时(即步骤①)，数据包的目标地址和端口为"172.16.10.5:2222"。由于host1上ssh已经监听了2222端口，并且知道该端口映射自哪台主机哪个端口，所以将会把该数据包目标地址和端口替换为"172.16.10.3:80"，并将此数据包通过转发给host3。当host3收到该数据包时，发现是host1转发过来请求访问host2:80的数据包，所以host3将代为访问host2的80端口。
+
+所以，host1和host3之间的通信方式是SSH协议，这段连接是安全加密的，因此称为"安全隧道"，而host3和host2之间通信协议则是HTTP而不是ssh。
+
+#### 最佳实践
+
+最后，关于端口转发有一个需要注意的问题：ssh命令中带有要执行的命令。考虑了下面的三条在host1上执行的命令的区别。
+```
+[root@xuexi ~]# ssh -g -L 22333:host2:22 host3
+[root@xuexi ~]# ssh -g -L 22333:host2:22 host3 "ifconfig"
+[root@xuexi ~]# ssh -g -L 22333:host2:22 host3 "sleep 10"
+```
+第一条命令开启了本地端口转发，且是以登录到host3的方式开启的，所以执行完该命令后，将跳到host3主机上，当退出host3时，端口转发功能将被关闭。另外，host1上之所以要开启端口转发，目的是为了与host2进行通信，而不是跳到host3上，所以应该在ssh命令行上加上"-f"选项让ssh在本机host1上以后台方式提供端口转发功能，而不是跳到host3上来提供端口转发功能。
+
+第二条命令在开启本地转发的时候还指定了要在host3上执行"ifconfig"命令，但是ssh的工作机制是远程命令执行完毕的那一刻，ssh关闭连接，所以此命令开启的本地端口转发功能有效期只有执行ifconfig命令的一瞬间。
+
+第三条命令和第二条命令类似，只不过指定的是睡眠10秒命令，所以此命令开启的本地转发功能有效期只有10秒。
+
+结合上面的分析，开启端口转发功能时，建议让ssh以后台方式提供端口转发功能，且明确指示不要执行任何ssh命令行上的远程命令。即最佳开启方式为：
+```
+[root@xuexi ~]# ssh -f -N -g -L 22333:host2:22 host3
+```
+
+### 远程端口转发
+
diff --git a/Linux/开发篇/ssh隧道代理.md b/Linux/开发篇/ssh隧道代理.md
new file mode 100644
index 00000000..e69de29b
diff --git a/权限控制/权限控制理论.md b/权限控制/权限控制理论.md
new file mode 100644
index 00000000..fa531b70
--- /dev/null
+++ b/权限控制/权限控制理论.md
@@ -0,0 +1,156 @@
+## 1 权限控制模型
+
+这些权限模型都是为了实现有效的访问控制而发展出来的，并在不同的场景和需求下有不同的应用。具体选用哪种权限模型要根据组织的需求、安全性要求和系统架构来决定。
+
+### RBAC
+
+RBAC（Role-Based Access Control）是一种常见的权限模型，它基于角色进行访问控制。在RBAC中，将用户分配给不同的角色，每个角色具有特定的权限，用户通过分配的角色来获取相应的权限。
+
+RBAC（Role-Based Access Control）模型适用于以下场景：
+
+组织结构明确的系统：适用于拥有明确定义角色和职责的组织，例如企业内部系统或公司网络。
+
+简单的访问控制需求：适用于相对简单的访问控制需求，其中权限只基于用户的角色。
+
+### ABAC
+
+ABAC（Attribute-Based Access Control）是另一种权限模型，它基于属性进行访问控制。在ABAC中，访问决策不仅基于用户角色，还基于其他属性（如用户的属性、环境条件等）。这种模型更加灵活，可以根据更多的属性因素进行访问控制。
+
+ABAC（Attribute-Based Access Control）模型适用于以下场景：
+
+复杂的访问控制需求：适用于需要基于多种属性、策略和环境条件实现访问控制的复杂系统，例如云计算环境、大型组织或跨组织的系统。
+
+动态访问控制：适用于需要动态调整访问权限的系统，根据用户的属性和环境条件进行访问控制。
+
+基于属性的访问控制模型(ABAC: Attribute-Based Access Control)，被一些人称为是权限系统设计的未来。
+不同于常见的将用户通过某种方式关联到权限的方式，ABAC 则是通过动态计算一个或一组属性是否满足某种条件来进行授权判断（可以编写简单的逻辑）。
+用户、资源和环境都有各自的属性。这些属性可以包括用户的身份、角色、部门、资源的类型、敏感级别、时间等。
+访问控制策略通过属性的匹配和条件评估来确定是否允许访问。例如，如果用户的角色属性是 "Manager" 且资源的敏感级别属性是 "High"，则允许访问。
+
+举例子：考虑一个企业的文档管理系统，使用 Attribute-Based Access Control (ABAC) 模型来控制对文档的访问。在这个例子中，访问控制的决策基于用户的属性、文档的属性以及其他环境因素。
+
+**用户属性：**
+
+* 属性 1：用户角色（Role） - 可能的值包括 "Employee"（员工）和 "Manager"（经理）。
+* 属性 2：用户部门（Department） - 包括 "Sales"（销售部门）和 "Engineering"（工程部门）。
+
+**文档属性：**
+
+* 属性 1：文档类型（Document Type） - 包括 "Internal"（内部文档）和 "Confidential"（机密文档）。
+* 属性 2：文档部门（Document Department） - 指定文档所属的部门。
+
+**环境属性：**
+
+* 属性 1：访问时间（Access Time） - 确定用户访问文档的时间。
+
+**策略定义：**
+
+* 规则 1：如果用户角色是 "Manager" 且文档类型是 "Confidential"，允许访问。
+* 规则 2：如果文档部门是 "Sales" 且访问时间是工作时间，允许员工访问。
+
+**访问请求示例：**
+
+* 用户A是 "Manager"，想要访问一个 "Confidential" 类型的文档，由于规则 1 的匹配，允许访问。
+* 用户B是 "Employee"，想要访问一个 "Internal" 类型的文档，在工作时间内，由于规则 2 的匹配，允许访问。
+
+在这个例子中，ABAC 模型通过匹配用户、文档和环境的属性来决定访问权限。管理员可以根据组织的需求定义和更新访问规则，以实现更精细和动态的访问控制。
+
+这种权限设计侧重点， 在于**数据属性**
+
+### PBAC
+
+PBAC（Policy-Based Access Control）是一种基于策略的权限模型，它通过定义策略来管理访问控制。这些策略可以由管理员根据组织的需求进行定制，以决策具体的访问权限。PBAC模型允许更细粒度的控制，并支持动态的访问控制策略。
+
+PBAC（Policy-Based Access Control）模型适用于以下场景：
+
+灵活的访问控制需求：适用于需要根据特定策略和规则管理访问控制的系统，以满足不同用户和场景下的灵活性和可定制性要求。
+
+高度可管理的访问控制：适用于需要集中管理、审计和控制权限策略的系统，以确保访问权限的一致性和安全性。
+
+
+Policy-Based Access Control (PBAC) 是一种基于策略的访问控制模型，它的核心思想是通过定义和实施一组策略来管理对系统资源的访问。在 PBAC 中，访问控制是通过规则和条件的集合来决定的，这些规则描述了在特定条件下用户能够执行的操作。
+
+跟 ABAC 是同属于一个级别的权限控制模型， 只是侧重点不同， PBAC 更加侧重于： **重定义和实施访问控制策略。这些策略是由一组规则组成，这些规则描述了在特定条件下用户能够执行的操作。**
+
+举例子：
+
+考虑一个企业的文件管理系统，管理员使用 Policy-Based Access Control (PBAC) 来定义访问控制策略，以确保对文件的访问仅限于授权用户和特定条件下的访问。
+
+**用户和角色定义：**
+
+* 角色 1：Employee（普通员工）
+* 角色 2：Manager（经理）
+* 角色 3：Admin（管理员）
+
+**资源定义：**
+
+* 资源 1：Project Documents（项目文件夹）
+* 资源 2：Financial Reports（财务报告文件夹）
+
+**策略定义：**
+
+* 策略 1：如果用户是经理，允许访问项目文件夹。
+* 策略 2：如果用户是管理员，允许访问财务报告文件夹。
+* 策略 3：如果访问时间在工作时间内，允许访问项目文件夹和财务报告文件夹。
+* 策略 4：如果用户是普通员工，仅在工作时间内允许访问项目文件夹。
+
+这些策略和规则的组合允许管理员定义对文件的访问控制。例如，一个经理在工作时间内可以访问项目文件夹，而管理员可以在任何时间访问财务报告文件夹。这个例子展示了 PBAC 模型如何通过灵活的策略定义，实现对资源访问的细粒度控制。管理员可以根据企业需求调整和更新这些策略，以适应不同的访问控制需求。
+
+### TBAC
+
+TBAC（Task-Based Access Control）是一种基于任务的权限模型，它根据用户当前的任务或角色来授予相应的权限。用户只能在特定任务或角色下获得特定的权限，以完成特定的任务。
+
+TBAC（Task-Based Access Control）模型适用于以下场景：
+
+任务导向的系统：适用于以任务为中心的系统，其中用户的权限是基于其当前执行的任务或角色。
+
+临时权限需求：适用于需要根据特定任务或临时角色授予用户临时权限的系统，以确保权限仅在需要时才可用。
+
+需要根据具体的系统需求、环境和安全性要求来选择合适的权限模型。有时也可以结合多个模型来实现更全面的访问控制策略。
+
+
+## 2 权限模型的实现
+
+### 权限中有几个关键概念
+
+用户：授权对象
+
+用户组：授权对象的集合，方便快速进行多个用户的授权。
+
+权限：被授权的内容。可以使水平权限、垂直权限。
+
+角色（权限组）：被授权对象的集合，方便快速进行一组权限的授权。
+
+垂直权限：功能相关的权限，应用开发阶段确认的。一般会定义角色，作为一组垂直权限的集合进行统一授权。
+
+水平权限：业务数据的权限，随着业务的变化而动态变化。一般会定义租户，作为垂直权限的集合进行统一授权。
+
+#### 最佳实践
+
+1. 对于垂直权限，一般的授权逻辑是先找到用户或者用户组，添加某个角色或者角色组。对于垂直权限，习惯上首先找到需要授权的水平资源，添加某个用户或者用户组。
+2. 授权对象的本质是建立授权对象和被授权对象的关系。垂直权限和水平权限无法进行分别控制。你再某个水平资源下具有的水平权限，在另外一个水平资源下可能没有。
+3. 权限控制有两种表现：
+   1. 可见性控制：对于没有权限的资源直接不可见。
+   2. 可访问性：对于没有权限的资源可见但是无法访问。
+
+
+### 四级权限结构
+
+一般情况下只需要前两级别的鉴权即可满足要求。如果需要更细粒度的鉴权，则需要添加3、4级别的权限控制。
+
+1. 租户鉴权：也称为作用域鉴权，水平鉴权，是基本的鉴权条件，实现水平资源的数据隔离，进行可见性控制。用户加入租户（水平资源组)
+2. 接口鉴权：垂直鉴权，用户是否具有该租户下某个功能（接口)的权限。用户赋予该租户下的某个角色（垂直权限组)
+3. 数据项鉴权：用户是否能够访问和修改某个数据项，进行可访问性控制。数据添加某个用户
+4. 数据项访问鉴权：用户是否具有该数据项的查看、编辑、执行或者任何自定义功能的权限。数据项设置某个用户的访问级别。
+
+### Linux的权限控制
+
+![](https://img-blog.csdnimg.cn/img_convert/fc4177cba90b077d22aff4f3cc663a56.png)
+
+
+
+对于Linux来说，1级权限就是不同的/home/?下不同的用户目录，实现了可见性的隔离。
+
+对于Linux文件鉴权来说，用到了3、4级别的鉴权。
+
+所有者、所在组、组外用户是三种不同的用户组。授权该文件（3级水平资源)，是否具有读写执行（4级数据项读写执行权限)。因为对于Linux来说没有垂直权限。一切皆文件。所以不需要2级授权，因为2级授权就是4级授权的执行全向。