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: <1303397133.1708.41.camel@unknown001a4b0c2895>
Date:	Thu, 21 Apr 2011 10:45:33 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Eric Paris <eparis@...isplace.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux-mm <linux-mm@...ck.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	SystemTap <systemtap@...rces.redhat.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Roland McGrath <roland@...k.frob.com>,
	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>, sds@...ho.nsa.gov
Subject: Re: [PATCH v3 2.6.39-rc1-tip 12/26] 12: uprobes: slot allocation
 for uprobes

On Thu, 2011-04-21 at 19:41 +0530, Srikar Dronamraju wrote:
> * Eric Paris <eparis@...isplace.org> [2011-04-20 09:40:57]:

> > Now how to fix the problems you were seeing.  If you run a modern
> > system with a GUI I'm willing to bet the pop-up window told you
> > exactly how to fix your problem.  If you are not on a GUI I accept
> > it's a more difficult as you most likely don't have the setroubleshoot
> > tools installed to help you out.  I'm just guess what your problem
> > was, but I think you have two solutions either:
> 
> I am not running GUI on my testbox and mostly disable selinux unless I
> need to test if uprobes works on selinux environment.
> 
> > 
> > 1) chcon -t unconfined_execmem_t /path/to/your/binary
> > 2) setsebool -P allow_execmem 1
> > 
> > The first will cause the binary to execute in a domain with
> > permissions to execute anonymous memory, the second will allow all
> > unconfined domains to execute anonymous memory.
> 
> We arent restricted to a particular binary/binaries. We want an
> infrastructure that can trace all user-space applications. So the
> first option doesnt seem to help us.
> 
> If I understand the second option. we would want this command to be
> run on any selinux enabled machines that wants uprobes to be working.

The check which I'm guessing you ran into problems is done using the
permissions of the 'current' task.  I don't know how your code works at
all, but I would have guessed that the task allocating and adding this
magic page was either perf or systemtap or something like that.  Not the
'victim' task where the page would actually show up.  Is that true?  If
so, method1 (or 2) works.  If not, and 'current' is actually the victim,
method2 would work some of the time, but not always.

If current can be the victim (or some completely random task) we can
probably switch the credentials of the current task as we do the
allocation to the initial creds (or something like that) so the
permission will be granted.

Unrelated note: I'd prefer to see that page be READ+EXEC only once it
has been mapped into the victim task.  Obviously the portion of the code
that creates this page and sets up the instructions to run is going to
need write.  Maybe this isn't feasible.  Maybe this magic pages gets
written a lot even after it's been mapped in.  But I'd rather, if
possible, know that my victim tasks didn't have a WRITE+EXEC page
available......

-Eric

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ