Unix 和早期linux的权限控制

 

1、 进程对操作系统内核的操作都需要权限。内核的操作通过system call完成。

另外进程都是用户启动的，包括init process。(init procee 由 uid=0的root启动。)

 

2、 早期的linux 对于用户权限的控制较粗，只有privileged和unprivileged两种。 要么是root权限（UID=0）通吃，要么是啥权限都没有的普通用户，

不能执行系统调用。

 

3、ALL or 0 的准入管理造成了一些应用在执行内核调用时，必须要临时提权到root。（suid bit / set group id 设置为1）

比如ping要调用网络的sockets资源，就需要临时提权。这就带来了很多的风险。ping如果被攻陷，那提权执行的动作就不光是网络调用了。。。

 

4、在内核2.2引入了 capability，capablity让linux中运行的进程或者应用，可以得到root的部分权限子集，精准控制他们使用的最小权限。

既满足了需要一些root能力的需求，又降低了风险。

比如之前举得ping的例子，ping可以分配CAP_NET_RAW能力，而不需要完全提权到所有Root能力。大大降低风险。

 

注意： capability赋予的是进程对内核的系统调用的权限。 和文件的可读可写是不同概念。

程序运行的进程对文件是否可以操作，这是capability决定。但是文件让不让写操作，是和用户权限有关系。

 

可以通过 cat /proc/PID/status 查看Capability

 

 

 CAPABILITY 集合

 

1、Capability其实就是把对Root可以做的特权能力做了分类，然后分配给不同的进程，赋予进程不同的对内核操作的权限。

2、Capability 把root特权分成了38+的capability

3、不再有ALL or Nothing的情况， root依然也需要capability，只是是有所有的capability集。

4、进程Process才有capability，而不是用户User。 因为只有进程才会有需求对内核功能做调用。

capability 有5个不同的类别， 每一类都表现为一个64字节的数字，来决定是有 0 或者 更多的 capability

 

这个最重要，决定了进程可以访问内核的最终能力. 其他capability都是决定是否可以放在CapEff中

决定了那些capability能放到Effective capbility set 中。 某capability在CapPrm而不在CapEff说明，说明

这个capability临时被disable了 （类似于候选能力池）

 

表示当前进程继承自父继承的capability 。 执行exec（），影响子进程继承父进程的capability

 

只有bounding set里有的capability才有资格放入permitted 或者 inherited capability set。

通过这个限制进程可能拥有的capability

 

 

 

fork()

创新一个新的进程，该进程是调用的当前进程的副本，不修改进程内容，完全一样。我们用ps函数可以看到不同的进程号

（新进程是内容一样的副本，但PID会重新分配）

 

exec()

启动另外的进程取代当前运行的进程， 一个进程一旦调用exec类函数，它本身就"死亡"了，系统把代码段替换成新的程序的代码，

废弃原有的数据段和堆栈段，并为新程序分配新的数据段与堆栈段，唯一留下的，就是进程号，也就是说，对系统而言，

还是同一个进程，实际已经是另一个程序了。（启用了新的进程，数据都不一样了，但是PID还保留）

 

 

 

 

 Capability 和 User Namespace

 

 

 

3、 Capability和 user ns的关系是， Capability是per user ns的， user ns决定了进程作用的范围。

 

如果进程属于某个user ns 的user ，那其Capability只在改 user ns有效。 其他non-user ns必须是被相同user ns治理的，才可以follow改进程的Capability。

其他ns（包括元祖initial user ns）治理的non-user ns不在其Capability影响之内。