From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <kees.cook@canonical.com>
Cc: James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec
Date: Tue, 08 Feb 2011 12:17:05 -0800 [thread overview]
Message-ID: <m1ipwu5lj2.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20110208042708.GG1457@outflux.net> (Kees Cook's message of "Mon, 7 Feb 2011 20:27:08 -0800")
Kees Cook <kees.cook@canonical.com> writes:
> On Tue, Feb 08, 2011 at 02:43:15PM +1100, James Morris wrote:
>> On Mon, 7 Feb 2011, Kees Cook wrote:
>> > Sure, I know about O_CLOEXEC, but this is about protecting the
>> > just-been-execed setuid process from the attacking process that has no
>> > reason to set O_CLOEXEC.
>> >
>> > Something like this needs to be enforced on the kernel side. I.e. these
>> > file in /proc need to have O_CLOEXEC set in a way that cannot be unset.
>> >
>> > > Changing the behavior in the core kernel will break userspace.
>> >
>> > I don't think /proc/$pid/* needs to stay open across execs, does it? Or at
>> > least the non-0444 files should be handled separately.
>>
>> Actually, this seems like a more general kind of bug in proc rather than a
>> leaked fd. Each child task should only see its own /proc/[pid] data.
>
> Right, that's precisely the problem. The unprivileged process can read
> the setuid process's /proc files.
If these are things that we actually care about we should sprinkle in a
few more ptrace_may_access calls into implementations of the relevant
proc files.
Eric
next prev parent reply other threads:[~2011-02-08 20:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 23:14 [SECURITY] /proc/$pid/ leaks contents across setuid exec Kees Cook
2011-02-08 0:44 ` James Morris
2011-02-08 1:14 ` Kees Cook
2011-02-08 3:43 ` James Morris
2011-02-08 4:27 ` Kees Cook
2011-02-08 20:17 ` Eric W. Biederman [this message]
2011-02-10 2:44 ` James Morris
2011-02-10 3:41 ` Eric W. Biederman
2011-02-10 6:38 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1ipwu5lj2.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox