linux-kernel - Re: [PATCH v3 2.6.39-rc1-tip 12/26] 12: uprobes: slot allocation for uprobes

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: <20110421165945.GA29472@linux.vnet.ibm.com>
Date:	Thu, 21 Apr 2011 22:29:45 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Eric Paris <eparis@...hat.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

* Eric Paris <eparis@...hat.com> [2011-04-21 10:45:33]:

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


The vma addition is done in the 'victim' context and not in the
debugger context. Victim hits the breakpoint and requests a
xol_vma for itself.

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

Okay, I will use the switching the credentials logic.

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

We dont need write permissions on this vma, READ+EXEC is good enuf.
As Roland said, userspace never writes to this vma.

-- 
Thanks and Regards
Srikar
--
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/