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: <CAGXu5jJKH6WPSMnqALOEjqGb6ZoeyYzj5vemk=2z4KPZyg=ptw@mail.gmail.com>
Date:	Thu, 26 Sep 2013 15:43:24 -0500
From:	Kees Cook <keescook@...omium.org>
To:	Djalal Harouni <tixxdz@...ndz.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>, tixxdz@...il.com
Subject: Re: [PATCH 06/12] procfs: make /proc/*/stack 0400

On Wed, Sep 25, 2013 at 3:14 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
> The /proc/*/stack contains sensitive information and currently its mode
> is 0444. Change this to 0400 so the VFS will be able to block
> unprivileged processes to get file descriptors on arbitrary privileged
> /proc/*/stack files.
>
> The /proc/*/stack is a /procfs ONE file that shares the same ->open()
> file operation with other ONE files. Doing a ptrace_may_access() check
> during open() might break userspace from accessing other ONE files
> like /proc/*/stat and /proc/*/statm.
>
> Therfore make it 0400 for now, and improve its check during ->read()
> in the next following patch.
>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Eric W. Biederman <ebiederm@...ssion.com>
> Signed-off-by: Djalal Harouni <tixxdz@...ndz.org>

While the rest of the series is being discussed, I think it would be
nice to at least get this into the tree. Fixing this reduces which
processes are exposed to ASLR leaks. The rest of the series closes the
remaining holes.

I would if it would be valuable adding a test for the identified leak
conditions to some test suite? LTP perhaps?

-Kees

-- 
Kees Cook
Chrome OS Security
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ