linux-kernel - Re: [PATCH 1/9] exec: add a global execve counter

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: <20120311083915.GB4310@dztty>
Date:	Sun, 11 Mar 2012 09:39:15 +0100
From:	Djalal Harouni <tixxdz@...ndz.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Kees Cook <keescook@...omium.org>,
	Solar Designer <solar@...nwall.com>,
	WANG Cong <xiyou.wangcong@...il.com>,
	James Morris <james.l.morris@...cle.com>,
	Oleg Nesterov <oleg@...hat.com>,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Greg KH <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...e.hu>, Stephen Wilson <wilsons@...rt.ca>,
	"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH 1/9] exec: add a global execve counter

On Sat, Mar 10, 2012 at 04:12:20PM -0800, Linus Torvalds wrote:
> On Sat, Mar 10, 2012 at 3:25 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
> >
> > Given that consideration this patch introduces two counters:
> > A global atomic execve counter that will be incremented on every
> > do_execve_common() call, and an atomic exec_id member for the task_struct.
> 
> This seems horribly expensive on most 32-bit architectures, including
> very much x86-32. That atomic64_inc_return() is not cheap.  It's
> possible that it's basically an impossible operation to do atomically
> on certain platforms, causing it to use some random spinlock instead.
Yes it will use spinlocks, and before that we also hold the
current->signal->cred_guard_mutex during all the do_execve_common(), not
to mention the search_binary_handler() logic which will test binary
format... it can even call request_module()

There is the first:
exec_id = atomic64_inc_return(&exec_counter); /* increment global */

and the second one:
atomic64_set(&current->exec_id, exec_id); /* set task exec_id */

I've added this since when we track the target task we do not want to race
against it when it does its execve call or when we set the exec_id at
open time of the /proc/<pid>/* files.

I can remove this second one but in this situation we must track only
reader (current), which is an aggressive behaviour, actually it may be
safer to do so. I've made the target track change to fit the desired
behaviour of "bind files to their process image".

And when we are at it, we should only allow reading of /proc/<pid>/mem, at
least it's only info leak in case there are future changes that can affect
the current protections.

-- 
tixxdz
http://opendz.org
--
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/