kernel-hardening - Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130827172406.GA2664@dztty>
Date: Tue, 27 Aug 2013 18:24:06 +0100
From: Djalal Harouni <tixxdz@...ndz.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/2] procfs: restore 0400 permissions on
 /proc/*/{syscall,stack,personality}

Hi Al,

On Mon, Aug 26, 2013 at 06:20:55PM +0100, Al Viro wrote:
> On Mon, Aug 26, 2013 at 09:49:48AM -0700, Eric W. Biederman wrote:
> 
> > How does changing the permissions to S_IRUSR prevent someone from
> > opening the file before, and reading the file after a suid exec?
> > 
> > > This patch restores the old mode which was 0400
> > 
> > Which seems to add no security whatsoever and obscure the fact that
> > anyone who cares can read the file so what is the point?
> 
> Two words: "security sclerosis".  Both patches NAKed, of course.
These particular tissues "are being hardened", no cure for them

More seriously, Al your commit a9712bc12c40c172e393f85 closes the races
during read() ok, but can you please share some light why the permission
mode was changed ?

1)
The commit log states that all these files are "rw-r--r--" which was not
correct, they were "r--------" before that commit.

2)
The commit log says also:
"if you open a file before the target does suid-root exec, you'll be still
able to access it." so you do the task is tracable check at read()

But what if you open a file of a privileged target or a target that does
suid-root exec later, and pass the fd to a suid-root exec to read() from
it later, you will still pass that tracable check.

And currently a non-privileged process can get an fd on all these
/proc/*/stack files even root owned ones.

So why not restore the old behaviour and block a process from getting an
fd on /proc/*/stack files that belong to other processes?

The original thread that added the /proc/*/stack feature:
https://lkml.org/lkml/2008/11/7/109

They noted that it should be under 0400 permissions

So why remove that, or why not restore the old safe behaviour ?

Hope to get a response

Thanks Al

-- 
Djalal Harouni
http://opendz.org

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.