[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sixt735b.fsf@xmission.com>
Date: Wed, 28 Aug 2013 17:26:56 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Djalal Harouni <tixxdz@...ndz.org>
Cc: Kees Cook <keescook@...omium.org>,
Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Solar Designer <solar@...nwall.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening\@lists.openwall.com"
<kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}
I have take a moment and read this thread, and have been completely
unenlightend. People are upset but it is totally unclear why.
There is no explanation why it is ok to ignore the suid-exec case, as
the posted patches do. Which ultimately means the patches provide
little to no security benefit, and that the posted patches as written
are broken.
There is no clear explanation of what people are worried about.
References to other threads and other commits do not help.
Can someome please state what they are worried about in simple language
step by step?
I see absolutely nothing to overturn Al's analysis that these files
simply don't need protection.
The closest I saw in the thread was people were worried about ASLR being
defeated. All I see are kernel addresses and we don't have much if any
runtime or even load time randomization of where code is located in the
kernel address map on x86_64. So I don't understand the concern.
Certainly all of the clever applications and use of suid apps appear to
be jumping around crazy hoops and to achieve what I can achieve with a
simple cat of a file.
Eric
--
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/
Powered by blists - more mailing lists