[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120311084602.GC4310@dztty>
Date: Sun, 11 Mar 2012 09:46:02 +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 0/9] proc: protect /proc/<pid>/* files across execve
On Sat, Mar 10, 2012 at 04:01:09PM -0800, Linus Torvalds wrote:
> I would in general suggest strongly against using exec_id for anything
> that involves files. It isn't designed for that, it's designed for the
> whole "check the parent exec_id" thing for ptrace, where that whole
> "pass things around to another process" approach doesn't work.
Yes exec_id for files can seem strange, but here we are speaking about
virtual files that are related to the image of the process being run,
these files are in reality just some portion of the process memory.
Linus please check the patch:
[PATCH 9/9] proc: improve and clean up /proc/<pid>/mem protection
I have explained why the current protection is not the best solution. The
oom killer will kill other processes including getty,klogd,... even root
owned ssh.
--
tixxdz
http://opendz.org
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
