linux-kernel - Re: [PATCH 0/6] enable writing to /proc/pid/mem

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: <20110309013017.GY22723@ZenIV.linux.org.uk>
Date:	Wed, 9 Mar 2011 01:30:17 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Stephen Wilson <wilsons@...rt.ca>
Cc:	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Roland McGrath <roland@...hat.com>,
	Matt Mackall <mpm@...enic.com>,
	David Rientjes <rientjes@...gle.com>,
	Nick Piggin <npiggin@...nel.dk>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Mel Gorman <mel@....ul.ie>, Ingo Molnar <mingo@...e.hu>,
	Michel Lespinasse <walken@...gle.com>,
	Hugh Dickins <hughd@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] enable writing to /proc/pid/mem

On Tue, Mar 08, 2011 at 07:42:17PM -0500, Stephen Wilson wrote:
> For a long time /proc/pid/mem has provided a read-only interface, at least
> since 2.4.0.  However, a write capability has existed "forever" in tree via the
> function mem_write(), disabled with an #ifdef along with the comment "this is a
> security hazard".  Currently, the main problem with mem_write() is that between
> the time permissions are checked and the actual write the target task could
> exec a setuid-root binary.
> 
> This patch series enables safe writes to /proc/pid/mem.  The principle strategy
> is to get a reference to the target task's mm before the permission check, and
> to hold that reference until after the write completes.

One note: I'd rather prefer approach similar to mm_for_maps().  IOW, instead
of "check, then get mm, then check _again_ to decide if we are allowed to
use it", just turn check_mm_permissions() into a function that returns
you a safe mm or gives you NULL (or, better yet, ERR_PTR(...)).  With all
checks done within that sucker.

Then mem_read() and mem_write() wouldn't need to recheck anything again
and the same helper would be usable for other things as well.  I mean
something like this: (*WARNING* - completely untested)

        err = mutex_lock_killable(&tsk->signal->cred_guard_mutex);
	if (err)
                return ERR_PTR(err);

        mm = get_tsk_mm(tsk);
	if (!mm) {
		mm = ERR_PTR(-EPERM);	/* maybe EINVAL here? */
	} else if (mm != current->mm) {
		int match;
	        /*
		 * If current is actively ptrace'ing, and would also be
		 * permitted to freshly attach with ptrace now, permit it.
		 */
		if (!tsk_is_stopped_or_traced(tsk))
			goto Eperm;
		rcu_read_lock();
		match = (tracehook_tracer_tsk(tsk) == current);
		rcu_read_unlock();
		if (!match)
			goto Eperm;
		if (!ptrace_may_access(tsk, PTRACE_MODE_ATTACH))
			goto Eperm;
        }
        mutex_unlock(&tsk->signal->cred_guard_mutex);
	return mm;
Eperm:
        mutex_unlock(&tsk->signal->cred_guard_mutex);
	mmput(mm);
	return ERR_PTR(-EPERM);
--
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/