linux-kernel - Re: [RFC] Implement ambient capability set.

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]

Message-ID: <alpine.DEB.2.11.1502041542260.19035@gentwo.org>
Date:	Wed, 4 Feb 2015 15:51:53 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
cc:	Andy Lutomirski <luto@...capital.net>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Aaron Jones <aaronmdjones@...il.com>, Ted Ts'o <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [RFC] Implement ambient capability set.

On Wed, 4 Feb 2015, Serge E. Hallyn wrote:

> > task_no_new_privs(current) instead of ns_capable(current_user_ns(),
>
> ....  I'm ok with that.  And iiuc it shouldn't get in the way of
> Christoph's use case.  I'd just rather not have one set of convoluted
> new rules now, and the have to relax them later bc it turns out ppl
> needed that.
>
> Christoph, would your code run ok under NNP?

There are still binaries invoked that need more priviledges. Does not
work.

> > In fact, even with your proposal of writing a tool that does this and
> > then calls a helper, that helper might try to use privilege separation
> > and open a big hole because clearing pP is no longer sufficient to
> > drop privileges.  Changing the evolution rule as above would fix this.
>
> Yeah...  "because clearing pP is no longer sufficient to drop privileges"
> is reasonably convincing.

Well I'd rather have a way to avoid writing a tool. The best would be if
you could just set some caps and that would do it.

> > <bikeshed>
> > I don't like calling these "ambient".  I'd prefer something like
> > "ambiently inheritable," although that's a bit long-winded.
> > </bikeshed>

amb_inh?

Fixup patch:

Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c
+++ linux/security/commoncap.c
@@ -351,9 +351,10 @@ static inline int bprm_caps_from_vfs_cap
 		__u32 inheritable = caps->inheritable.cap[i];

 		/*
-		 * pP' = (X & fP) | (pI & fI)
+		 * pP' = (fA & fP) | (X & fP) | (pI & fI)
 		 */
-		new->cap_permitted.cap[i] = current_cred()->cap_ambient.cap[i] |
+		new->cap_permitted.cap[i] =
+			(current_cred()->cap_ambient.cap[i] & permitted) |
 			(new->cap_bset.cap[i] & permitted) |
 			(new->cap_inheritable.cap[i] & inheritable);

@@ -453,9 +454,13 @@ static int get_file_caps(struct linux_bi
 		if (rc == -EINVAL)
 			printk(KERN_NOTICE "%s: get_vfs_caps_from_disk returned %d for %s\n",
 				__func__, rc, bprm->filename);
-		else if (rc == -ENODATA)
-			rc = 0;
-		goto out;
+		else if (rc != -ENODATA)
+			goto out;
+		rc = 0;
+		if (!cap_isclear(current_cred()->cap_ambient))
+			goto out;
+		*effective = true;
+		*has_cap = true;
 	}

 	rc = bprm_caps_from_vfs_caps(&vcaps, bprm, effective, has_cap);
@@ -941,7 +946,10 @@ int cap_task_prctl(int option, unsigned
 		if (!cap_valid(arg2))
 			return -EINVAL;

-		new =prepare_creds();
+		if (!ns_capable(current_user_ns(), arg2))
+			return -EPERM;
+
+		new = prepare_creds();
 		if (arg3 == 0)
 			cap_lower(new->cap_ambient, arg2);
 		else
--
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/