linux-kernel - Re: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 23:56:55 +0300
From:	Igor Zhbanov <izh1979@...il.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, neilb@...e.de, Trond.Myklebust@...app.com,
	David Howells <dhowells@...hat.com>,
	James Morris <jmorris@...ei.org>
Subject: Re: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE 
	be added to CAP_FS_MASK?

2009/3/12 J. Bruce Fields <bfields@...ldses.org>:
>
> For nfsd at least we should be droppping anything that concerns the
> filesystem and would normally require root privileges.
>
> We need to trace up through the users of CAP_FS_SET and figure out what
> other users need.

2009/3/12 J. Bruce Fields <bfields@...ldses.org>:

> For nfsd at least we should be droppping anything that concerns the
> filesystem and would normally require root privileges.
>
> We need to trace up through the users of CAP_FS_SET and figure out what
> other users need.

CAP_FS_SET used unly in functions cap_is_fs_cap(...),
cap_drop_fs_set(...), cap_raise_fs_set(...).
And it is used as a base for CAP_NFSD_SET.

CAP_NFSD_SET is used in cap_drop_nfsd_set(...) and
cap_raise_nfsd_set(...) functions.

All above you can find in include/linux/capability.h

cap_is_fs_cap(...) is not used in mainstream kernel.

As for cap_drop_fs_set(...) and cap_raise_fs_set(...), they are used in function
cap_task_post_setuid(...) in file security/commoncap.c:
------------------------------------------------------------------------------
int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid,
			  int flags)
{
	switch (flags) {
...
	case LSM_SETID_FS:
		{
			uid_t old_fsuid = old_ruid;

			/* Copied from kernel/sys.c:setfsuid. */

			/*
			 * FIXME - is fsuser used for all CAP_FS_MASK capabilities?
			 *          if not, we might be a bit too harsh here.
			 */

			if (!issecure (SECURE_NO_SETUID_FIXUP)) {
				if (old_fsuid == 0 && current->fsuid != 0) {
					current->cap_effective =
						cap_drop_fs_set(
						    current->cap_effective);
				}
				if (old_fsuid != 0 && current->fsuid == 0) {
					current->cap_effective =
						cap_raise_fs_set(
						    current->cap_effective,
						    current->cap_permitted);
				}
			}
			break;
		}
	default:
		return -EINVAL;
	}

	return 0;
}
------------------------------------------------------------------------------

So, it raises or drops filesystem capabilities when (old_ruid !=
current->fsuid), i.e. when fsuid changes.

And cap_task_post_setuid(...) indirectly called from setfsuid(...)
syscall function in file kernel/sys.c:
------------------------------------------------------------------------------
/*
 * "setfsuid()" sets the fsuid - the uid used for filesystem checks. This
 * is used for "access()" and for the NFS daemon (letting nfsd stay at
 * whatever uid it wants to). It normally shadows "euid", except when
 * explicitly set by setfsuid() or for access..
 */
SYSCALL_DEFINE1(setfsuid, uid_t, uid)
{
	int old_fsuid;

	old_fsuid = current->fsuid;
	if (security_task_setuid(uid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS))
		return old_fsuid;

	if (uid == current->uid || uid == current->euid ||
	    uid == current->suid || uid == current->fsuid ||
	    capable(CAP_SETUID)) {
		if (uid != old_fsuid) {
			set_dumpable(current->mm, suid_dumpable);
			smp_wmb();
		}
		current->fsuid = uid;
	}

	key_fsuid_changed(current);
	proc_id_connector(current, PROC_EVENT_UID);

	/* !!! HERE !!! */
	security_task_post_setuid(old_fsuid, (uid_t)-1, (uid_t)-1, LSM_SETID_FS);

	return old_fsuid;
}
------------------------------------------------------------------------------

And here is example of using setfsuid(...) syscall. I have found it in
linux-PAM package
in pam_xauth module in file modules/pam_xauth.c. This module reads
file in home directory
of authenticating user. Look at this:
------------------------------------------------------------------------------
	euid = geteuid();
	setfsuid(pwd->pw_uid);
	fp = fopen(path, "r");
	setfsuid(euid);
------------------------------------------------------------------------------

Module runs as root, but needs to temporarily drop filesystem
capabilities, so module
will not read files that user couldn't read according to permissions.

And I think that when some process running as root decides to temporarily drop
filesystem capabilities, CAP_MKNOD and CAP_LINUX_IMMUTABLE
(and probably some selinux related capablities) must be dropped too,
as ordinary users couldn't create devices, etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/