Linux内核进程管理子系统有什么第五十回 —— 进程主结构详解（46）

接前一篇文章：Linux内核进程管理子系统有什么第四十九回 —— 进程主结构详解（45）

本文内容参考：

Linux内核进程管理专题报告_linux rseq-CSDN博客

《趣谈Linux操作系统 核心原理篇：第三部分 进程管理》—— 刘超

《图解Linux内核 基于6.x》 —— 姜亚华 机械工业出版社

https://blog.csdn.net/NiuYoohoo/article/details/125213445

https://cloud.tencent.com/developer/article/1731464

https://zhuanlan.zhihu.com/p/24562897128

特此致谢！

进程管理核心结构 —— task_struct

8. 进程权限相关成员

进程权限相关成员包括以下几个：

	/* Process credentials: */

	/* Tracer's credentials at attach: */
	const struct cred __rcu		*ptracer_cred;
 
	/* Objective and real subjective task credentials (COW): */
	const struct cred __rcu		*real_cred;
 
	/* Effective (overridable) subjective task credentials (COW): */
	const struct cred __rcu		*cred;

这几个字段的描述如下：

上一回继续对于struct cred进行解析，本回仍然继续。为了便于理解和回顾，再次贴出struct cred的定义，在include/linux/cred.h中，如下：

​/*
 * The security context of a task
 *
 * The parts of the context break down into two categories:
 *
 *  (1) The objective context of a task.  These parts are used when some other
 *	task is attempting to affect this one.
 *
 *  (2) The subjective context.  These details are used when the task is acting
 *	upon another object, be that a file, a task, a key or whatever.
 *
 * Note that some members of this structure belong to both categories - the
 * LSM security pointer for instance.
 *
 * A task has two security pointers.  task->real_cred points to the objective
 * context that defines that task's actual details.  The objective part of this
 * context is used whenever that task is acted upon.
 *
 * task->cred points to the subjective context that defines the details of how
 * that task is going to act upon another object.  This may be overridden
 * temporarily to point to another security context, but normally points to the
 * same context as task->real_cred.
 */
struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
#ifdef CONFIG_KEYS
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key	*session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
	void		*security;	/* LSM security */
#endif
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct ucounts *ucounts;
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	/* RCU deletion */
	union {
		int non_rcu;			/* Can we skip RCU deletion? */
		struct rcu_head	rcu;		/* RCU deletion hook */
	};
} __randomize_layout;

上一回继续讲解struct cred中的以下字段：

	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */

上一回完成了对于Linux Capability的知识补强。本回在此基础上，看一下以上字段的意义和作用。

• kernel_cap_t cap_permitted和kernel_cap_t cap_effective

cap_permitted表示进程能够使用的权限。但真正起作用的是cap_effective。cap_permitted中可以包含cap_effective中没有的权限。

一个进程可以在必要的时候，放弃自己所拥有的某些权限，这样会更加安全。例如，假设某进程由于代码漏洞被攻破了，但由于权限很少，破坏者想做进一步的破坏也做不了。

• kernel_cap_t cap_inheritable和kernel_cap_t cap_ambient

cap_inheritable表示当可执行文件的扩展属性设置了inheritable位时，调用exec执行该程序，会继承调用者的inheritable集合，并将其加入到permitted集合。

但是，在非root用户下执行exec时，通常不会保留inheritable集合。而往往又是非root用户，才想要保留权限。所以，这个inheritable非常“鸡肋”。

正是基于此，cap_ambient才被加入到内核。它就是为了解决cap_inheritable的“鸡肋”窘境，即非root用户进程使用exec执行一个程序的时候，如何保留权限的问题。

其机制是：当执行exec的时候，cap_ambient会被添加到cap_permitted中，同时也被添加到cap_effective中。

• kernel_cap_t cap_bset

cap_bset，全称是capbility bounding set，是系统中所有进程允许保留的权限。

如果此集合中不存在某个权限，那么系统中的所有进程都没有该权限。即使以超级用户权限执行的进程也是一样。这样做有诸多好处。例如，系统启动以后，将加载内核模块的权限去掉，那么所有进程都不能加载内核模块了。这样，即使这台机器被攻破，也做不了太多有害的事儿。

这里也来看以下kernel_cap_t的定义，也在include/linux/capability.h中，如下：

typedef struct kernel_cap_struct {
	__u32 cap[_KERNEL_CAPABILITY_U32S];
} kernel_cap_t;

至此，struct task_struct中进程权限相关成员就讲解完了。struct task_struct中更多成员的解析请看下回。