Merge branch 'next-general' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (ae5906ce) · Commits · 戴 / test

Documentation/admin-guide/LSM/SafeSetID.rst

0 → 100644

+107 −0

Original line number	Diff line number	Diff line
		=========
		SafeSetID
		=========
		SafeSetID is an LSM module that gates the setid family of syscalls to restrict
		UID/GID transitions from a given UID/GID to only those approved by a
		system-wide whitelist. These restrictions also prohibit the given UIDs/GIDs
		from obtaining auxiliary privileges associated with CAP_SET{U/G}ID, such as
		allowing a user to set up user namespace UID mappings.


		Background
		==========
		In absence of file capabilities, processes spawned on a Linux system that need
		to switch to a different user must be spawned with CAP_SETUID privileges.
		CAP_SETUID is granted to programs running as root or those running as a non-root
		user that have been explicitly given the CAP_SETUID runtime capability. It is
		often preferable to use Linux runtime capabilities rather than file
		capabilities, since using file capabilities to run a program with elevated
		privileges opens up possible security holes since any user with access to the
		file can exec() that program to gain the elevated privileges.

		While it is possible to implement a tree of processes by giving full
		CAP_SET{U/G}ID capabilities, this is often at odds with the goals of running a
		tree of processes under non-root user(s) in the first place. Specifically,
		since CAP_SETUID allows changing to any user on the system, including the root
		user, it is an overpowered capability for what is needed in this scenario,
		especially since programs often only call setuid() to drop privileges to a
		lesser-privileged user -- not elevate privileges. Unfortunately, there is no
		generally feasible way in Linux to restrict the potential UIDs that a user can
		switch to through setuid() beyond allowing a switch to any user on the system.
		This SafeSetID LSM seeks to provide a solution for restricting setid
		capabilities in such a way.

		The main use case for this LSM is to allow a non-root program to transition to
		other untrusted uids without full blown CAP_SETUID capabilities. The non-root
		program would still need CAP_SETUID to do any kind of transition, but the
		additional restrictions imposed by this LSM would mean it is a "safer" version
		of CAP_SETUID since the non-root program cannot take advantage of CAP_SETUID to
		do any unapproved actions (e.g. setuid to uid 0 or create/enter new user
		namespace). The higher level goal is to allow for uid-based sandboxing of system
		services without having to give out CAP_SETUID all over the place just so that
		non-root programs can drop to even-lesser-privileged uids. This is especially
		relevant when one non-root daemon on the system should be allowed to spawn other
		processes as different uids, but its undesirable to give the daemon a
		basically-root-equivalent CAP_SETUID.


		Other Approaches Considered
		===========================

		Solve this problem in userspace
		-------------------------------
		For candidate applications that would like to have restricted setid capabilities
		as implemented in this LSM, an alternative option would be to simply take away
		setid capabilities from the application completely and refactor the process
		spawning semantics in the application (e.g. by using a privileged helper program
		to do process spawning and UID/GID transitions). Unfortunately, there are a
		number of semantics around process spawning that would be affected by this, such
		as fork() calls where the program doesn???t immediately call exec() after the
		fork(), parent processes specifying custom environment variables or command line
		args for spawned child processes, or inheritance of file handles across a
		fork()/exec(). Because of this, as solution that uses a privileged helper in
		userspace would likely be less appealing to incorporate into existing projects
		that rely on certain process-spawning semantics in Linux.

		Use user namespaces
		-------------------
		Another possible approach would be to run a given process tree in its own user
		namespace and give programs in the tree setid capabilities. In this way,
		programs in the tree could change to any desired UID/GID in the context of their
		own user namespace, and only approved UIDs/GIDs could be mapped back to the
		initial system user namespace, affectively preventing privilege escalation.
		Unfortunately, it is not generally feasible to use user namespaces in isolation,
		without pairing them with other namespace types, which is not always an option.
		Linux checks for capabilities based off of the user namespace that ???owns??? some
		entity. For example, Linux has the notion that network namespaces are owned by
		the user namespace in which they were created. A consequence of this is that
		capability checks for access to a given network namespace are done by checking
		whether a task has the given capability in the context of the user namespace
		that owns the network namespace -- not necessarily the user namespace under
		which the given task runs. Therefore spawning a process in a new user namespace
		effectively prevents it from accessing the network namespace owned by the
		initial namespace. This is a deal-breaker for any application that expects to
		retain the CAP_NET_ADMIN capability for the purpose of adjusting network
		configurations. Using user namespaces in isolation causes problems regarding
		other system interactions, including use of pid namespaces and device creation.

		Use an existing LSM
		-------------------
		None of the other in-tree LSMs have the capability to gate setid transitions, or
		even employ the security_task_fix_setuid hook at all. SELinux says of that hook:
		"Since setuid only affects the current process, and since the SELinux controls
		are not based on the Linux identity attributes, SELinux does not need to control
		this operation."


		Directions for use
		==================
		This LSM hooks the setid syscalls to make sure transitions are allowed if an
		applicable restriction policy is in place. Policies are configured through
		securityfs by writing to the safesetid/add_whitelist_policy and
		safesetid/flush_whitelist_policies files at the location where securityfs is
		mounted. The format for adding a policy is '<UID>:<UID>', using literal
		numbers, such as '123:456'. To flush the policies, any write to the file is
		sufficient. Again, configuring a policy for a UID will prevent that UID from
		obtaining auxiliary setid privileges, such as allowing a user to set up user
		namespace UID mappings.

Documentation/admin-guide/LSM/index.rst

+11 −3

Original line number	Diff line number	Diff line
		@@ -17,9 +17,8 @@ MAC extensions, other extensions can be built using the LSM to provide
		specific changes to system operation when these tweaks are not available
		in the core functionality of Linux itself.

		Without a specific LSM built into the kernel, the default LSM will be the
		Linux capabilities system. Most LSMs choose to extend the capabilities
		system, building their checks on top of the defined capability hooks.
		The Linux capabilities modules will always be included. This may be
		followed by any number of "minor" modules and at most one "major" module.
		For more details on capabilities, see ``capabilities(7)`` in the Linux
		man-pages project.

		@@ -30,6 +29,14 @@ order in which checks are made. The capability module will always
		be first, followed by any "minor" modules (e.g. Yama) and then
		the one "major" module (e.g. SELinux) if there is one configured.

		Process attributes associated with "major" security modules should
		be accessed and maintained using the special files in ``/proc/.../attr``.
		A security module may maintain a module specific subdirectory there,
		named after the module. ``/proc/.../attr/smack`` is provided by the Smack
		security module and contains all its special files. The files directly
		in ``/proc/.../attr`` remain as legacy interfaces for modules that provide
		subdirectories.

		.. toctree::
		:maxdepth: 1

		@@ -39,3 +46,4 @@ the one "major" module (e.g. SELinux) if there is one configured.
		Smack
		tomoyo
		Yama
		SafeSetID

Documentation/admin-guide/kernel-parameters.txt

+7 −5

Original line number	Diff line number	Diff line
		@@ -2333,6 +2333,10 @@

		lsm.debug [SECURITY] Enable LSM initialization debugging output.

		lsm=lsm1,...,lsmN
		[SECURITY] Choose order of LSM initialization. This
		overrides CONFIG_LSM, and the "security=" parameter.

		machvec= [IA-64] Force the use of a particular machine-vector
		(machvec) in a generic kernel.
		Example: machvec=hpzx1_swiotlb
		@@ -4110,11 +4114,9 @@
		Note: increases power consumption, thus should only be
		enabled if running jitter sensitive (HPC/RT) workloads.

		security= [SECURITY] Choose a security module to enable at boot.
		If this boot parameter is not specified, only the first
		security module asking for security registration will be
		loaded. An invalid security module name will be treated
		as if no module has been chosen.
		security= [SECURITY] Choose a legacy "major" security module to
		enable at boot. This has been deprecated by the
		"lsm=" parameter.

		selinux= [SELINUX] Disable or enable SELinux at boot time.
		Format: { "0" \| "1" }

MAINTAINERS

+5 −6

Original line number	Diff line number	Diff line
		@@ -15557,12 +15557,11 @@ F: mm/shmem.c
		TOMOYO SECURITY MODULE
		M: Kentaro Takeda <takedakn@nttdata.co.jp>
		M: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
		L: tomoyo-dev-en@lists.sourceforge.jp (subscribers-only, for developers in English)
		L: tomoyo-users-en@lists.sourceforge.jp (subscribers-only, for users in English)
		L: tomoyo-dev@lists.sourceforge.jp (subscribers-only, for developers in Japanese)
		L: tomoyo-users@lists.sourceforge.jp (subscribers-only, for users in Japanese)
		W: http://tomoyo.sourceforge.jp/
		T: quilt http://svn.sourceforge.jp/svnroot/tomoyo/trunk/2.5.x/tomoyo-lsm/patches/
		L: tomoyo-dev-en@lists.osdn.me (subscribers-only, for developers in English)
		L: tomoyo-users-en@lists.osdn.me (subscribers-only, for users in English)
		L: tomoyo-dev@lists.osdn.me (subscribers-only, for developers in Japanese)
		L: tomoyo-users@lists.osdn.me (subscribers-only, for users in Japanese)
		W: https://tomoyo.osdn.jp/
		S: Maintained
		F: security/tomoyo/

fs/proc/base.c

+55 −9

Original line number	Diff line number	Diff line
		@@ -143,6 +143,10 @@ struct pid_entry {
		NOD(NAME, (S_IFREG\|(MODE)), \
		NULL, &proc_single_file_operations, \
		{ .proc_show = show } )
		#define ATTR(LSM, NAME, MODE) \
		NOD(NAME, (S_IFREG\|(MODE)), \
		NULL, &proc_pid_attr_operations, \
		{ .lsm = LSM })

		/*
		* Count the number of hardlinks for the pid_entry table, excluding the .
		@@ -2521,7 +2525,7 @@ static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
		if (!task)
		return -ESRCH;

		length = security_getprocattr(task,
		length = security_getprocattr(task, PROC_I(inode)->op.lsm,
		(char*)file->f_path.dentry->d_name.name,
		&p);
		put_task_struct(task);
		@@ -2570,7 +2574,9 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
		if (rv < 0)
		goto out_free;

		rv = security_setprocattr(file->f_path.dentry->d_name.name, page, count);
		rv = security_setprocattr(PROC_I(inode)->op.lsm,
		file->f_path.dentry->d_name.name, page,
		count);
		mutex_unlock(&current->signal->cred_guard_mutex);
		out_free:
		kfree(page);
		@@ -2584,13 +2590,53 @@ static const struct file_operations proc_pid_attr_operations = {
		.llseek = generic_file_llseek,
		};

		#define LSM_DIR_OPS(LSM) \
		static int proc_##LSM##_attr_dir_iterate(struct file *filp, \
		struct dir_context *ctx) \
		{ \
		return proc_pident_readdir(filp, ctx, \
		LSM##_attr_dir_stuff, \
		ARRAY_SIZE(LSM##_attr_dir_stuff)); \
		} \
		\
		static const struct file_operations proc_##LSM##_attr_dir_ops = { \
		.read = generic_read_dir, \
		.iterate = proc_##LSM##_attr_dir_iterate, \
		.llseek = default_llseek, \
		}; \
		\
		static struct dentry proc_##LSM##_attr_dir_lookup(struct inode dir, \
		struct dentry *dentry, unsigned int flags) \
		{ \
		return proc_pident_lookup(dir, dentry, \
		LSM##_attr_dir_stuff, \
		ARRAY_SIZE(LSM##_attr_dir_stuff)); \
		} \
		\
		static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \
		.lookup = proc_##LSM##_attr_dir_lookup, \
		.getattr = pid_getattr, \
		.setattr = proc_setattr, \
		}

		#ifdef CONFIG_SECURITY_SMACK
		static const struct pid_entry smack_attr_dir_stuff[] = {
		ATTR("smack", "current", 0666),
		};
		LSM_DIR_OPS(smack);
		#endif

		static const struct pid_entry attr_dir_stuff[] = {
		REG("current", S_IRUGO\|S_IWUGO, proc_pid_attr_operations),
		REG("prev", S_IRUGO, proc_pid_attr_operations),
		REG("exec", S_IRUGO\|S_IWUGO, proc_pid_attr_operations),
		REG("fscreate", S_IRUGO\|S_IWUGO, proc_pid_attr_operations),
		REG("keycreate", S_IRUGO\|S_IWUGO, proc_pid_attr_operations),
		REG("sockcreate", S_IRUGO\|S_IWUGO, proc_pid_attr_operations),
		ATTR(NULL, "current", 0666),
		ATTR(NULL, "prev", 0444),
		ATTR(NULL, "exec", 0666),
		ATTR(NULL, "fscreate", 0666),
		ATTR(NULL, "keycreate", 0666),
		ATTR(NULL, "sockcreate", 0666),
		#ifdef CONFIG_SECURITY_SMACK
		DIR("smack", 0555,
		proc_smack_attr_dir_inode_ops, proc_smack_attr_dir_ops),
		#endif
		};

		static int proc_attr_dir_readdir(struct file file, struct dir_context ctx)

Admin message