On Thu, Sep 29, 2016 at 01:32:56AM +0200, Jann Horn wrote:

On Wed, Sep 28, 2016 at 04:22:53PM -0700, Andy Lutomirski wrote:

quoted

On Wed, Sep 28, 2016 at 3:54 PM, Jann Horn [off-list ref] wrote:

quoted

SELinux attempts to make it possible to whitelist trustworthy sources of
code that may be mapped into memory, and Android makes use of this feature.
To prevent an attacker from bypassing this by modifying R+X memory through
/proc/$pid/mem or PTRACE_POKETEXT, it is necessary to call a security hook
in check_vma_flags().

If selinux policy allows PTRACE_POKETEXT, is it really so bad for that
to result in code execution?

Have a look at __ptrace_may_access():

	/* Don't let security modules deny introspection */
	if (same_thread_group(task, current))
		return 0;

This means thread A can attach to thread B and poke its memory, and SELinux
can't do anything about it.

I guess another perspective on this would be that it's a problem that
interfaces usable for poking user memory are subject to introspection rules
(as opposed to e.g. /proc/self/maps, where it is actually useful).

Ugh, I'm talking nonsense, ptrace() doesn't work on threads. (/proc/$pid/mem
works though). And then, ptrace-ish APIs aside, there are those weird
devices that do DMA with force=1.