netdev - Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

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:	Fri, 1 Jan 2010 13:17:33 -0800
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Bryan Donlan <bdonlan@...il.com>,
	Benny Amorsen <benny+usenet@...rsen.dk>,
	Michael Stone <michael@...top.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Evgeniy Polyakov <zbr@...emap.net>,
	"C. Scott Ananian" <cscott@...ott.net>,
	James Morris <jmorris@...ei.org>,
	Bernie Innocenti <bernie@...ewiz.org>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Samir Bellabes <sam@...ack.fr>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Pavel Machek <pavel@....cz>, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

2009/12/31 Eric W. Biederman <ebiederm@...ssion.com>:
> "Andrew G. Morgan" <morgan@...nel.org> writes:
>
>> Since there is already independent support for disabling file
>> capabilities (the privilege escalation part), I see these two
>> mechanisms as separable.
>
> I guess there is something that resembles support for disabling
> privilege escalation.  The problem is that it requires privilege to
> use it.

Just to be clear, this does not prevent luser1 -> luser2 transitions
(even though it does strip root of its privilege), but here is a
concrete worked example of what support is in the current kernel.

That is, here is a program that cripples privilege in a process tree.
Other than setting it up one time, you don't need to become root (or
visit a *uid=0) to execute it, and because capabilities are not
naively inherited nothing about the privilege of the limiter
executable can leak through the execve().

Setup (see below for source code, and
http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf for
an explanation of how it all works):

luser> cc -o limiter limiter.c -lcap
luser> sudo /usr/sbin/setcap cap_setpcap=p ./limiter

Use:

luser> ./limiter /bin/bash
[feeling powerless]
luser> ...try something privileged... or look at /proc/self/status etc.
luser> exit
luser> back in parent shell

//---- cut here 8< ----- [this is limiter.c]
/* Quick demo of blocking privilege */
#include <stdio.h>
#include <sys/capability.h>
#include <sys/prctl.h>
#include <stdlib.h>

int main(int argc, char *argv[], char *envp[])
{
     if (argc < 2) {
	  fprintf(stderr, "usage: %s <execv args>\n", argv[0]);
	  exit(1);
     }
     cap_t needed = cap_from_text("cap_setpcap=ep");
     if (cap_set_proc(needed) != 0) {
	  perror("cap_set_proc failed");
	  exit(1);
     }
     int cap = 0;
     int set;
     while ((set = prctl(PR_CAPBSET_READ, cap)) >= 0) {
	  if (set && prctl(PR_CAPBSET_DROP, cap)) {
	       fprintf(stderr, "failed to drop bset capability: %s\n",
		       cap_to_name(cap));
	       exit(1);
	  }
	  cap++;
     }
     if (prctl(PR_SET_SECUREBITS, 0x2e /* magic combination */)) {
	  perror("unable lock secure-bits");
	  exit(1);
     }
     fprintf(stderr, "[feeling powerless]\n");
     execve(argv[1], argv + 1, envp);
     fprintf(stderr, "[execve(\"%s\",...) failed - try something else.]\n",
	     argv[1]);
     exit(1);
}
//---- cut here 8< -----

> I have no problem with expressing this in a fine grained manner internally
> to the kernel but the user space interface needs to be atomic so that
> we can enable this all without privilege.

I'm not clear on the need for this specific detail.

> Further I may be off but I think the implementation would be more
> challenging than what I have already posted.  That doesn't mean it
> won't be more useful long term.

[Not sure I followed this bit.]

I can see a desire to block luser -> luser transitions being a good
thing, but not because it has anything to do with privilege.

Cheers [and happy New Year!]

Andrew

>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html